Re: default holdability

[Satheesh Bandaram]

I don't think changing default holdability is a good idea... like Dan and Dag mentioned. Why does Derby have to change default holdability because SUR and XA can't support it? Also Derby doesn't have SQL cursors, only JDBC cursors, right? Even if default is changed, SUR and XA will still not be able to support holdability. Changing default once caused too many issues, but atleast then automatic upgrade wasn't support for applications. Satheesh Bernt M. Johnsen wrote: Hi all, Allthough I agree that backwards compatability is important, I find the current default unfortunate for several reasons: 1) As Anreas points out: The architecture seems to be designed for non-holdable cursors (in agreement with the old Cloudscape default). 2) Cursors in the SQL standard defaults to non-holdable 3) It does not fit very well with global transactions And I am not convinced that very many exsisting apps depend on resultsets being holdable without being explicit in the JDBC calls. Dag H. Wanvik wrote (2006-02-22 18:09:04): Hi, Daniel John Debrunner <[EMAIL PROTECTED]> writes: The JDBC 3.0 spec is silent on this, sections 14.1.1 and 14.1.2 describe what can be done when a ResultSet type or concurrency is not supported. However in 14.1.3 there is no comment about what can be done when a requested holdability is not supported. Also ResultSet does not have a getHoldability method to allow the application to determine if its request was honoured or not. I just can't see the value in changing the default behaviour and affecting existing applications because holdability is not supported in two cases. I agree with Dan on this one. Rather than risk breaking existing apps, for SUR, we should just document this for now; hopefully we can find a solution for holdable SUR also, along the lines Mike outlined (by invalidating open result sets when inline compress happens), so the restriction can be lifted. Thanks, Dag I seem to remember that most users assumed Cloudscape in the past supported holdable results sets and expected it to be the default. They were suprised when it didn't. Dan. -- Dag H. Wanvik Sun Microsystems, Database Technology Group (DBTG) Haakon VII gt. 7b, N-7485 Trondheim, Norway Tel: x43496/+47 73842196, Fax: +47 73842101