Sybase NNTP forums - End Of Life (EOL)

The NNTP forums from Sybase - forums.sybase.com - are now closed.

All new questions should be directed to the appropriate forum at the SAP Community Network (SCN).

Individual products have links to the respective forums on SCN, or you can go to SCN and search for your product in the search box (upper right corner) to find your specific developer center.

Cursors: dynamic scroll or insensitive?

4 posts in JDBC Connect (product renamed to JConnect) Last posting was on 1997-08-26 23:28:03.0Z
Randall Parker Posted on 1997-08-16 21:00:34.0Z
Message-ID: <33F614F2.3360@west.net>
Date: Sat, 16 Aug 1997 17:00:34 -0400
From: Randall Parker <rgparker@west.net>
Reply-To: rgparker_nospam@west.net
X-Mailer: Mozilla 2.02E (OS/2; I)
MIME-Version: 1.0
Subject: Cursors: dynamic scroll or insensitive?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Newsgroups: sybase.public.jdbcconnect
Lines: 24
Path: forums-1-dub!forums-master.sybase.com!forums.powersoft.com
Xref: forums-1-dub sybase.public.jdbcconnect:370
Article PK: 252122

SQL Anywhere (and MS SQL Server, don't know about Sybase) supports a
number of options on DECLARE CURSOR.

I'm wondering about DYNAMIC SCROLL and INSENSITIVE.

I'm wondering
A) what options does jdbcConnect use as a default for DECLARE CURSOR?

B) Are there different circumstances (eg different isolation levels)
that cause the JDBC driver to declare cursors with different options?

C) Has Sun stated in some sort of implementation guidelines that are
likely to make it so that different JDBC drivers written for the same
database (or for different database) will all choose the same ways of
doing DECLARE CURSOR?

D) Does jdbcConnect look at whether there is an ORDER BY or anything
else about the SELECT statement and use that information to declare the
cursor differently on SQL Anywhere, Sybase SQL Server, Oracle, or ODBC?
(or any of the RDBMS's that jdbcConnect supports).


--


Lance Andersen Posted on 1997-08-18 12:55:27.0Z
Message-ID: <33F8463F.662F@sybase.com>
Date: Mon, 18 Aug 1997 08:55:27 -0400
From: Lance Andersen <lancea@sybase.com>
X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 5.5.1 sun4m)
MIME-Version: 1.0
To: rgparker_nospam@west.net
Subject: Re: Cursors: dynamic scroll or insensitive?
References: <33F614F2.3360@west.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Newsgroups: sybase.public.jdbcconnect
Lines: 51
Path: forums-1-dub!forums-master.sybase.com!forums.powersoft.com
Xref: forums-1-dub sybase.public.jdbcconnect:368
Article PK: 252120

Currently, we cannot use cursors within SQL Anywhere and
this will change in the future.

The current javasoft spec for cursor management is very very light.

We are putting together a proposal which we will be presenting to
javasoft in the near future with the hopes of getting the
current standard amended.

The current version of jConnect complies with the javasoft spec
in regards to Cursors.

Currently we use language based cursors.

Oracle does not support DECLARE CURSOR FOR in their PL/sql only in
their
embedded sql. So currently jConnect cannot use cursors on Oracle.

Randall Parker wrote:
>
> SQL Anywhere (and MS SQL Server, don't know about Sybase) supports a
> number of options on DECLARE CURSOR.
>
> I'm wondering about DYNAMIC SCROLL and INSENSITIVE.
>
> I'm wondering
> A) what options does jdbcConnect use as a default for DECLARE CURSOR?
>
> B) Are there different circumstances (eg different isolation levels)
> that cause the JDBC driver to declare cursors with different options?
>
> C) Has Sun stated in some sort of implementation guidelines that are
> likely to make it so that different JDBC drivers written for the same
> database (or for different database) will all choose the same ways of
> doing DECLARE CURSOR?
>
> D) Does jdbcConnect look at whether there is an ORDER BY or anything
> else about the SELECT statement and use that information to declare the
> cursor differently on SQL Anywhere, Sybase SQL Server, Oracle, or ODBC?
> (or any of the RDBMS's that jdbcConnect supports).
>
> --

--
===============================================================================
Lance J. Andersen Email: lancea@sybase.com
Sybase Technical Support Phone:(617) 564-6336
77 South Bedford Street Fax: (617) 564-6148
Burlington, MA 01803

The Dark Knight Returns!!! Let's Go Penguins!!!
===============================================================================


David Clegg Posted on 1997-08-19 17:24:30.0Z
Message-ID: <33F9D6CE.141BC45D@sybase.com>
Date: Tue, 19 Aug 1997 10:24:30 -0700
From: David Clegg <davec@sybase.com>
X-Mailer: Mozilla 3.01 (X11; I; Linux 1.2.13 i586)
MIME-Version: 1.0
To: Lance Andersen <lancea@sybase.com>
CC: rgparker_nospam@west.net
Subject: Re: Cursors: dynamic scroll or insensitive?
References: <33F614F2.3360@west.net> <33F8463F.662F@sybase.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Newsgroups: sybase.public.jdbcconnect
Lines: 110
Path: forums-1-dub!forums-master.sybase.com!forums.powersoft.com
Xref: forums-1-dub sybase.public.jdbcconnect:365
Article PK: 252117


>
> Currently, we cannot use cursors within SQL Anywhere and
> this will change in the future.

Sorry to say, we probably won't have cursors working well directly
from JConnect to SA until sometime Q1 '98. There are a number of
issues to work out between jConnect, the OSG, and SQLAnywhere before
this can all work correctly - no simple hack to fix things. The
JDBCTransaction classes from PowerJ might be your best solution in
the near term.


> The current javasoft spec for cursor management is very very light.
>
> We are putting together a proposal which we will be presenting to
> javasoft in the near future with the hopes of getting the
> current standard amended.
We have contacted JavaSoft on this issue - Hope to see something in the
JDK 1.2 timeframe, but... concensus building is a slow process.

>
> Oracle does not support DECLARE CURSOR FOR in their PL/sql only in
> their
> embedded sql. So currently jConnect cannot use cursors on Oracle.

Interestingly, Oracle decided not to implement Cursors at all in their
JDBC drivers. They actually recommend that you use their ROWID feature
and searched update/delete to acheive similar functionality -- not a
very RDBMS-portable way to write JDBC applications...

>
> Randall Parker wrote:
> >
> > SQL Anywhere (and MS SQL Server, don't know about Sybase) supports a
> > number of options on DECLARE CURSOR.
> >
> > I'm wondering about DYNAMIC SCROLL and INSENSITIVE.
> >
> > I'm wondering
> > A) what options does jdbcConnect use as a default for DECLARE CURSOR?

The default is FOR UPDATE - we leave it to the server to decide what
columns are really updatable. If you just shove the keywords above
into the SELECT statement you are associating the cursor with, it
should work:
Connection.prepareStatement("Select * from t1 READONLY");
or
Connection.prepareStatement("Select * from t1 FOR UPDATE OF c1");

> >
> > B) Are there different circumstances (eg different isolation levels)
> > that cause the JDBC driver to declare cursors with different options?
No.

> >
> > C) Has Sun stated in some sort of implementation guidelines that are
> > likely to make it so that different JDBC drivers written for the same
> > database (or for different database) will all choose the same ways of
> > doing DECLARE CURSOR?

I think that the main reason that the Cursor-related part of the JDBC
specification is so sparse is that they are indeed very concerned about
making it possible for JDBC drivers to work the same across vendors.
There are no implementation guidelines except for comments inside the
java.sql.* source files - nothing on this topic.

> >
> > D) Does jdbcConnect look at whether there is an ORDER BY or anything
> > else about the SELECT statement and use that information to declare the
> > cursor differently on SQL Anywhere, Sybase SQL Server, Oracle, or ODBC?
> > (or any of the RDBMS's that jdbcConnect supports).

Nope.
As Lance mentioned, JDBC uses language-based cursors at this point.
Our TDS protocol has support for a different type of cursor which
can be more efficient than language based cursors. If we shift over
to using the protocol-based cursors, the Server can send back
specific information about the cursor after it has been declared,
including whether it is scrollable, readonly, has some or all
columns updatable, etc.

Our first implementation based on Language cursors was intended to
keep things simple (and the jConnect bytecode size as small as possible
to keep download-times down), and to interoperate with as many
different RDBMS backends as possible. In retrospect, this "simple"
approach was probably too simple - SQLAnywhere doesn't support
Language-based cursors (The cursors it supports are protocol based
but a different protocol that S/A ESQL and ODBC native drivers use,
not TDS), and we have not adequately explored how TDS-based protocol
cursors work through OSG. And languaged based cursors to Oracle RDBMS
via the directConnect gateways don't work because Oracle doesn't
support the ANSI '92 standard DECLARE CURSOR syntax - we may eventually
be able to put in a hack to fix this, or again we can investigate how
well the directConnect gateways handle protocol cursors.

That was a whole lot more than you wanted to know, huh?

dave


Randall Parker Posted on 1997-08-26 23:28:03.0Z
Message-ID: <34036682.46B9@west.net>
Date: Tue, 26 Aug 1997 19:28:03 -0400
From: Randall Parker <rgparker@west.net>
Reply-To: rgparker_whoa_there_nellie_nospam@west.net
Organization: Some secret world-wide conspiracy Ltd
X-Mailer: Mozilla 2.02E (OS/2; I)
MIME-Version: 1.0
Subject: Re: Cursors: dynamic scroll or insensitive?
References: <33F614F2.3360@west.net> <33F8463F.662F@sybase.com> <33F9D6CE.141BC45D@sybase.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Newsgroups: sybase.public.jdbcconnect
Lines: 10
Path: forums-1-dub!forums-master.sybase.com!forums.powersoft.com
Xref: forums-1-dub sybase.public.jdbcconnect:345
Article PK: 252097

<<That was a whole lot more than you wanted to know, huh?>>

I love this level of detail. Much appreciated.

BTW, you guys give first class support here. I feel more secure
recommending your various tools just because I know there are first
class support people and talented regular users hanging out here
discussing the nuances and problems.


--