Shreyas Kaushik wrote:
> I did some debugging as to why this happens. I think the way
> DRDAConnThread handles calls to relative could be problematic ( still
> need to dig more though).
> As I had put several breakpoints in my debugger, one interesting thing
> I found in Network Server is that a call to relative() method in the
> resultset does not go through
> the realtive implementation in EmbedResultSet, whereas in Embedded
> mode it goes through this method.
>
> The Network server uses other methods to achieve this I think, I'm
> trying to still figure the exact code path. Any specific reason why it
> happens this way?
>
> ~ Shreyas
>
> Satheesh Bandaram wrote:
>
>> I will take a look. I submitted the patch for Shreyas and made sure
>> the test passes on embedded driver, but didn't check Network
>> framework. Will do so now..
>>
>> Satheesh
>>
>> Daniel John Debrunner wrote:
>>
>>> I'm seeing jdbcapi/testRelative failing when running with the IBM DB2
>>> universal client and network server. This would seem to be related to
>>> Derby-186. Is anyone looking at this to see if it's a test issue, IBM
>>> DB2 driver issue or a Derby issue?
>>>
>>> http://issues.apache.org/jira/browse/DERBY-186
>>>
>>> Dan.
>>>
>>>
>>> *** Start: testRelative jdk1.4.2_06 DerbyNet derbynetmats:jdbcapi
>>> 2005-04-07 11:45:44 ***
>>> 6 del
>>> < isFirst=false isLast=false isAfterLast=true
>>> 7 del
>>> < FAIL -- unexpected exception
>>> 8 del
>>> < SQLSTATE(24000): SQL Exception: Invalid cursor state - no current
>>> row.
>>> 9 del
>>> < SQL Exception: Invalid cursor state - no current row.
>>> 9 add
>>>
>>>
>>>> isFirst=false isLast=false isAfterLast=false
>>>> Value=work1
>>>>
>>>
>>> Test Failed.
>>> *** End: testRelative jdk1.4.2_06 DerbyNet derbynetmats:jdbcapi
>>> 2005-04-07 11:46:01 ***
>>>
>>>
>>>
>>>
>>>
>
>
Hi Shreyas,
After all my talk about debugging steps, this one is a little tough for
you to debug right now because you don't have the client source. At
the moment the network server tests run with the IBM DB2 Universal
JDBC Driver. You can set the connection attribute
traceFile=<filename> to get a protocol trace but I don't know if that is
going to help you too much here.
Since this is a new test, I will go ahead and disable the test in
network server mode for now. I think that is appropriate because it is
a new test and I
1) don't know if the problem was preexisting or new.
2) don't know if the problem is Network Server or The IBM driver.
3) can't give you enough information to debug it effectively.
If it were a preexisting test that broke that would be indicative of a
Network Server regression and I wouldn't feel comfortable taking the
same action.
Would you mind filing a Jira entry for the jdbcapi/testRelative.java
failure? In addition to describing the problem, please cut and paste
what you already found from this mail. That information will be very
helpful. Also include a repro, which in this case will be easy.
1) Comment out jdbcapi/testRelative.java in
functionTests/suites/derbynetmats.exclude.
2) run the test
java -Dframework=DerbyNet
org.apache.derbyTesting.functionTests.harness.RunTest
jdbcapi/testRelative.java
Since I have access to the IBM Driver source, I will take an initial look at it
and try to figure out where the problem lies. Based on the info you gave us
here, I don't tend to think it is related to your change directly. Thanks for
researching it thus far.
Just an FYI about adding tests.
Tests in the following suites are run by derbynetmats (see
functionTests/suites/derbynetmats.properties).
suites=derbynetmats jdbcapi jdbc20 multi
If you add a new test to one of these suites or to derbynetmats.runall,
it will be included in network server testing .
Tests listed in functionTests/suites/DerbyNet.exclude are excluded from
network server testing even if they are in one of those suites.
Thanks
Kathey
