Hi Ed, For SCROLL_SENSITIVE resultsets, we will need to first decide how we want to handle deleted rows, ie, should we keep the deleted holes in the resultset (similar to FORWARD_ONLY resultsets), or should we simply remove the rows from the resultset since it is a sensitive resultset. If we do decide to keep the deleted holes, then we will need to remember where they are in the resultset because it will be possible to move to any row within a scrollable resultset.With FORWARD_ONLY resultset, I had to worry only about the current row's delete status since there is no way to go backwards into the resultset to run into other deleted holes.
Other than that, I think the basic framework of updatable FORWARD_ONLY resultset should work for future updatable SCROLL_SENSITIVE resultset. I am more than half way done with "update" using updatable resultset JDBC apis. Hope to send something for that in next 2 weeks or so. I haven't researched much into "insert" using updatable resultset JDBC apis to give a fair estimate on it at this point. Mamta Edward Rayl wrote: > Mamta, > > >Derby currently supports FORWARD_ONLY and SCROLL_INSENSITIVE > >resultsets in read only mode. There is no support for SCROLL_SENSITIVE > >resultsets. In addition, SQL standards do not support updatable > >SCROLL_INSENSITIVE cursors. > > > >Based on these facts, this patch will support updatable resultsets for > >only ResultSet.TYPE_FORWARD_ONLY. > > > > > Presuming support for SCROLL_SENSITIVE resultsets might come in the > future, how easy would it be to update your implementation? > > What is your best guess for completion of full updatable resultset support? > > Ed
