Hi,
Ok sorry. I thought possibly it would be relatively easy to debug if you
could see it happening.
I can certainly create the test as a standalone stored procedure, and then
I suppose I should have a go at removing bits to try and reduce it.
In terms of h2 code is there a reason that the
On 2013-09-30 14:16, Mike Goodwin wrote:
In terms of h2 code is there a reason that the parameter references
need to be copied in the manner that they are? In my simplistic
understanding for a given stored procedure there will always be a
fixed number of parameters, so in an ideal world a
Hi,
Unfortunately, it's quite hard to analyze the problem with this test case.
The test case doesn't include source code, and the statement is very large
(500 lines or so). Would it be possible to simplify the test case to just a
few lines of SQL statement, and to a simple, standalone test case
I replied off the list with a link to download a test case.
- mike
On Tue, Sep 24, 2013 at 6:29 PM, Thomas Mueller
thomas.tom.muel...@gmail.com wrote:
Hi,
There were a few issues about parameter indexes in combination with views
or subqueries in the past, it's possible that there are
Hi,
There were a few issues about parameter indexes in combination with views
or subqueries in the past, it's possible that there are remaining issues.
I can provide a standalone, albeit complicated test case for this issue.
That would be great! I wouldn't want to change the code without
Hi,
I have found what I believe to be an issue with parameter handling in a
complex query. It seems it is possible for the incorrect parameter to be
returned as a value when evaluating the query (in my case a timestamp
parameter was evaluating to a long - using the value of a separate
parameter
