db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fernanda Pizzorno <Fernanda.Pizzo...@Sun.COM>
Subject Subject: Detectability of updates in DRDA
Date Fri, 03 Mar 2006 15:38:53 GMT
I am going to start working on detectability for scrollable insensitive 
update result sets on the client driver and I was wondering if someone 
could answer to the following question posted by Dag:

DERBY-775: Network client: Add support for scrollable, updatable, 
insensitive result sets


b) Detectability

In the spec, we required that we be able to detect deletes and updates
to the rows in the result set:

     deletesAreDetected(TYPE_SCROLL_INSENSITIVE) -> true
     updatesAreDetected(TYPE_SCROLL_INSENSITIVE) -> true

(Since inserts are not visible, they can not be detectable, either).
DRDA supports detection of holes in the following manner (quote,
P. 656):

   "To present a static size and static ordering for the result table, the
   relational database may return a hole to the application that fetches
   an updated or deleted row in the result table. A hole in the result
   table occurs when there is a difference between the result table and
   the underlying base table. No data can be fetched from a hole, and the
   hole is manifested in the QRYDTA as a row consisting of a non-null
   SQLCARD and a null data group.

   When the current value of a row no longer satisfies the
   select-statement or statement-name, that row is visible in the cursor
   as an update hole , where the SQLCARD has a warning SQLSTATE of 02502.

   When a row of the result table is deleted from the underlying base
   table, the row is visible in the cursor as a delete hole , where the
   SQLCARD has a warning SQLSTATE of 02502."

For deletes, the "delete hole" is exactly what we need to support

For updates, is is not exactly what we want, since we do not intend to
requalify a row after it has been updated (thereby possibly making it
an "update hole"). On the other hand, when we update a row and let it
remain in the result table, DRDA offers no means of conveying that the
row has been changed in the sense of JDBC ResultSet#rowUpdated(), as
far as I can tell.

*Question 2*: Is there some way we can detect the latter without
violating the protocol? One could imagine signalling this using
another warning SQLSTATE. Would this be an acceptable tweaking of the


Thanks in advance.


View raw message