Re: JDBC 2.0 - CONCUR_UPDATABLE

Jim,
This operation is supported by default by the Oracle Database... The thing one has to watch out for is the definition of one's transaction. For example, if I'm 'working' on one record in one table I must ensure that this record DOES NOT have integrity constants enforced by other tables, because if it does the record is locking in the local table and the foreign table.
One can always use the select for update command from your app as well...

For the JDBC drivers, check http://otn.oracle.com but I believe the latest drivers has FULL JDBC 2.0 support as mandated by J2EE 1.3...

Hope this helps....

--
Cheers,
Matt

"In a world without walls or fences, who needs Windows or Gates?"

"Jim Smith" <jsmith_at_cmhcsys.com> wrote in message
news:_d%s7.40$qN3.119394_at_news.uswest.net...


> I need to have a CONCUR_UPDATABLE result set (preferably

> TYPE_SCROLL_SENSITIVE).  I'm finding conflicting information about whether

> or not this type of dynamic result set is even supported by the ORACLE

> server let alone implemented by a JDBC driver, and that if I can do it I

can


> only reference a single table in my statement...

>

> SAMPLE PROBLEM:

> We need to select multiple rows at a time, but don't want to lock the

entire


> set of rows in the result set, yet need to ensure data integrity with

> multiple users concurrently accessing the database:

>

> Ex: User 1 executes a query that returns 30 rows.  I do NOT want all of

> these rows locked, I simply want to lock the single active record that

user


> 1 is viewing.  User 2 should be able to execute a query that returns the

> same results and be able to scroll through her result set unhindered

(until


> she tries to activate the same row that User 1 has active).

>

> -Is this type of operation even supported by ORACLE?

> -Can I do this via JDBC and if so can someone recommend a driver?

>

> Any answers on these issues would be appreciated.  Any reference materials

> or sites containing an in depth discussion of these issues would be

welcome


> as well.

>

> Thanks!

>

>

>

>