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.