Army <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] wrote:
>
> Odd. Do you have data in your table that is different from the data
> created in lang/inbetween.sql?
No, it should be the same. But I DON'T see this on a clean trunk, only
when running with the patch from DERBY-827 which enables re-using lang
result sets. Without that patch the result sets are thrown away and
created again for each execution, so then storing the probe values in
the constructor will work just fine. Sorry for not pointing this out
earlier.
> I ran all of the DDL statements for
> "bt1" as copied from that test, then ran the statements you showed in
> your example. But it looks like I'm seeing different behavior
Unless you have applied Dan's 827 patch you should :)
> wrote MultiProbeTableScanResultSet. As I'm sure you noticed, there is
> the following comment in the openCore() method of that class:
>
> if (needSort)
> {
> /* RESOLVE: For some reason sorting the probeValues array
> * directly leads to incorrect parameter value assignment when
> * executing a prepared statement multiple times. Need to figure
> * out why (maybe related to DERBY-827?). In the meantime, if
> * we're going to sort the values we use clones. This is not
> * ideal, but it works for now.
> */
>
> Maybe this is irrelevant, but since you're becoming more familiar with
> re-execution of prepared statements, maybe you have some insight here?
> ;)
Yes I saw that comment. But no I have no good explanation :(
>> My take is that the probe values must somehow be obatined from the
>> activation whenever openCore() gets called. How difficult would it be
>> to do that?
>
> If that might solve the problem you're seeing (which I am not
> currently able to reproduce) then I think the approach would be to
> generate the array of probe values as a "saved object", which can then
> be retrieved from the activation just like any other saved object. My
> perhaps slightly uninformed guess is that this shouldn't be too
> difficult--maybe a day or two of coding?
But you would need to change the code generation to create such saved
objects, right?
> And of course, such an effort would be much more valuable if it solved
> the cloning the "workaround" that is mentioned in the above RESOLVE
> comment, as well...
>
> It'd be great if you could post an sql script that demonstrates the
> problem you show in its entirety, as I'm unable to reproduce it on my
> own.
Sure. I'll post a repro script (which is basically just inbetween.sql
with a lot of stuff snipped) together with an updated DERBY-827 patch
which includes Dan's original changes and some smaller fixups which I
have added along the way, (the fixup patch currently there is a bit
outdated).
> Thank you for bringing this up!
Thank you for the feedback :)
--
dt
