jConnect works fine, but it seems to go against the grain of what Sybase
has tought us before... .
Cursors are inefficient, they said, and now cursors everywhere! Or is this
the same word for something else?
I was so happy with the functional interface and this looks like EMBEDDED
SQL? Are long lists of questionmarks
object oriented? To my defence: I have never used ODBC.
Now, my question: Do JDBC 'cursors' map to Sybase server side cursors? This
would imply having to switch to a different transaction handling mindset
and this worries me, as I use client defined transaction heavily in my
Ulrich Becker, email@example.com
Subject: dblib C programmer is confused, should I really switch to JDBC?
X-Newsreader: Microsoft Internet News 4.70.1155
Date: Thu, 17 Apr 1997 07:53:26 -0400
Xref: forums-1-dub sybase.public.jdbcconnect:976
Article PK: 252730
Date: Thu, 17 Apr 1997 15:11:46 -0700
From: David Clegg <firstname.lastname@example.org>
X-Mailer: Mozilla 2.01 (X11; I; Linux 1.2.13 i586)
To: Ulrich Becker <email@example.com>
Subject: Re: dblib C programmer is confused, should I really switch to JDBC?
Content-Type: text/plain; charset=us-ascii
Xref: forums-1-dub sybase.public.jdbcconnect:968
Article PK: 252720
The jConnect product only uses cursors if you do:
on your statement before you do the executeQuery().
And even in this case, we only use "language" cursors, not the
"TDS-based" cursors you get via the ct_cursor() calls or
the E/SQL DECLARE CURSOR statements.
We are looking at adding TDS-based cursor support in some future
release, but are working with Sun to update the JDBC standard
for interfacing with cursors. As the standard stands now, the
JDBC driver would have to do some really wacky things to make it