com.sybase.jdbc2.jdbc.SybSQLException: #groupingTempTable not found. Specify owner.objectname or use sp_help to check whether the object exists (sp_help may produce lots of output).
After looking at it sideways and tracing through method calls and trying to find where it's using two different connections (and failing to find that incorrect coding, but I'm still looking)... I came to the theory that something about the connection itself was somehow.... not stable. That somehow, my connection was 'loosing' track of its temp tables. That is: that somehow, I have a "pointer to a pool-managed connection object" that is very stable in the production version, but is unreliable in my dev version.
I then began to think about "what changed in DBCP?" and that's why I listed the versions above.
Except.. that seems like madness, and a sure recipe for calamitous bug reports against DBCP. How could using temp tables ever work, if the pool kept swapping connections on you?
Anyways... I thought I'd throw that out there, in case anyone else has experienced something similar, or has other theories.
 I've looked and looked, but maybe that just means I haven't looked long enough/hard enough yet. But... I'm reasonably certain the code does *not* use two connections. Otherwise, for the years this app has been in production, every single time the improperly coded method (the one that obtains a connection, creates a temp table, returns that connection, then gets a new connection, and expects the temp table to be there) is being used, wouldn't it need to be lucky every time, that on subsequent calls to "getConnection()" that the pool returned "the right" connection every time? The error I'm seeing *every* time in dev, would have to occur at least *some* of the time in production, wouldn't you think? So while possible, it's unlikely to be improper application coding (and plus, I still can't find the improper dual connections yet).