Daniel, any chance of posting a complete repro, so I can recreate the problem to debug? I am also baffled by the stack trace and your description of your program. Though your stack trace is useful, it would be lot more useful to generate it with actual line numbers of the code. I can do this and also investigate the problem if I can get a complete reproduction posted.


Daniel Skiles wrote:
The interesting thing about this is that the stack overflow is in 
UnionResultSet.openCore, yet what you describe here has nothing to do 
with unions. There's nothing in the language code that I know of that 
would introduce a UnionResultSet into any of these statements.

I suspect the real problem is with one of the INSERT statements. 
Cloudscape allows the VALUES clause on an INSERT to have more than 
one row. When you do this it represents it internally as an insert of 
a multi-way union of rows with constants in them. If your code put 
together an INSERT/VALUES with 100,000 rows, Cloudscape would 
represent it as 100,000 nested UnionResultSets. This could easily 
cause a stack overflow of the type you're seeing.

Now, what I've described here doesn't match what you've described for 
your code, but is it possible your code doesn't do exactly what you 
think it does?

I suppose the potential stack overflow from a huge VALUES clause 
could be considered a bug, although I don't know how important it 
would be to fix it. The most obvious fix would be to introduce a 
ValuesResultSet that iterates over a set of constant rows and a 
corresponding ValuesNode, and to change the parser so it generates a 
ValuesNode instead of a set of UnionNodes.

--My entire utility is less than 300 lines long.  Each query that I
showed you I took directly out of the code.  The exception also pops up
in the select query and not the inserts.  Is it possible to connect to
an embedded database using ij and look at it?  I'd like to see if
anything is actually in there.  If so, what kind of connection string
should I use?

Thanks for your time.