SQL0502N -- open cursor -- jdbc type 2 driver

[robert]

don't find any mention on either udb/APARS or 390/APARS.

since upgrading 390 to 7.1.1 over the weekend, the following now
happens, when run from udb to 390:

....
Statement stmt = conn.createStatement();
ResultSet rs;

<do stuff>

rs.close();
stmt.close();
stmt = conn.createStatement();

now we get the 0502N.

worked OK with both 7/8 UDB and 6 390. from what i can find,
the cursor is either on the ResultSet or the Statement; and
the error is bogus (shouldn't be happening).

is this a known issue not yet in APARS??

thanks,
robert

[Ed Lang]

maybe ....

rs.close()
stmt.close()
conn.commit()
stmt = conn.createStatement()

will work. (I believe the cursor behind the result set needs a commit
or rollback to close it, and that only after the rs.close() because of
"with hold".)

Regards,
Ed Lang

robert wrote:

don't find any mention on either udb/APARS or 390/APARS.

since upgrading 390 to 7.1.1 over the weekend, the following now
happens, when run from udb to 390:

...
Statement stmt = conn.createStatement();
ResultSet rs;

<do stuff>

rs.close();
stmt.close();
stmt = conn.createStatement();

now we get the 0502N.

worked OK with both 7/8 UDB and 6 390. from what i can find,
the cursor is either on the ResultSet or the Statement; and
the error is bogus (shouldn't be happening).

is this a known issue not yet in APARS??

thanks,
robert

[robert]

Ed Lang <el*@softpro.de> wrote in message news:<vk***********@lucy.ux.softpro.de>...

maybe ....

rs.close()
stmt.close()
conn.commit()
stmt = conn.createStatement()

will work. (I believe the cursor behind the result set needs a commit
or rollback to close it, and that only after the rs.close() because of
"with hold".)

Regards,
Ed Lang

robert wrote:

don't find any mention on either udb/APARS or 390/APARS.

since upgrading 390 to 7.1.1 over the weekend, the following now
happens, when run from udb to 390:

...
Statement stmt = conn.createStatement();
ResultSet rs;

<do stuff>

rs.close();
stmt.close();
stmt = conn.createStatement();

now we get the 0502N.

worked OK with both 7/8 UDB and 6 390. from what i can find,
the cursor is either on the ResultSet or the Statement; and
the error is bogus (shouldn't be happening).

is this a known issue not yet in APARS??

thanks,
robert

turns out to be an (unadmitted) bug in UDB. need 8.1.6. just trying
to access one of these databases from AQT throws the message. i can
see the databases from DB2 Command Center, but that's so lame, i gave
up on it years ago. of course, no one here has tried 8.1.6, so that
might be just as broken.

thanks,
robert

[robert]

gn*****@rcn.com (robert) wrote in message news:<da**************************@posting.google. com>...

Ed Lang <el*@softpro.de> wrote in message news:<vk***********@lucy.ux.softpro.de>...

maybe ....

rs.close()
stmt.close()
conn.commit()
stmt = conn.createStatement()

will work. (I believe the cursor behind the result set needs a commit
or rollback to close it, and that only after the rs.close() because of
"with hold".)

Regards,
Ed Lang

robert wrote:

don't find any mention on either udb/APARS or 390/APARS.

since upgrading 390 to 7.1.1 over the weekend, the following now
happens, when run from udb to 390:

...
Statement stmt = conn.createStatement();
ResultSet rs;

<do stuff>

rs.close();
stmt.close();
stmt = conn.createStatement();

now we get the 0502N.

worked OK with both 7/8 UDB and 6 390. from what i can find,
the cursor is either on the ResultSet or the Statement; and
the error is bogus (shouldn't be happening).

is this a known issue not yet in APARS??

thanks,
robert

turns out to be an (unadmitted) bug in UDB. need 8.1.6. just trying
to access one of these databases from AQT throws the message. i can
see the databases from DB2 Command Center, but that's so lame, i gave
up on it years ago. of course, no one here has tried 8.1.6, so that
might be just as broken.

thanks,
robert

well, setting ODBC CURSORHOLD off does allow access. why the behaviour
changed in V8, IDK. whether this will screw up inserts and updates,
i haven't tested. select works OK.