At 05:29 PM 05-01-01 -0700, you wrote:

>Thank you for the very long and detailed response. I'll make comments inline
>on things I don't understand...
>
> > Doing it this way you are losing the benefit of the fact that generators
> > are outside transaction control. Once a number has been generated, the
> > transaction that took it has it, no further ado. That number won't be
> > generated again.
>
>Actually I don't want that. Here is the model I'm using in a typical data
>entry screen:
>
>1. The existing data is loaded via a select or defaults are given for a new
> record. There is no locking done. There is a unique object id for each
> record and also a numeric version.
>
>2. The user makes their changes to the data in the screen.
>
>3. The user submits the update. At this point it does an SQL update command
> to effect the changes (or an insert to create a new record with an initial
> version of zero). The update where clause includes "version = ?" which is
> used to check if the version being updated is the same as the original
> one.
> Also the update increases the version number.
>
>4. Right after the update a commit is done. The whole thing should always
> be very quick to reduce lock conflicts if another user is editing the same
> data.
>
>5. If the update failed then it is one of two things. Either another user
> has changed the record in-between the initial select and the update or
> another user has deleted the record. This is noticed by the update giving
> back a count of zero for the number of rows effected. The user is then
> informed of the conflict and they can redo the changes.
>
>I personally find this works very well. It is rare for my users to ever edit
>the same data at the same time so this way I'm not holding locks. For the
>insert case, the first thing it does is get an id from the id_table in the
>way I've mentioned. This is what is causing the deadlock errors but I still
>don't understand why...

Well, at least we understand why you don't understand.
After you have filled yourself in on the difference between the default
transaction (gds_trans) which interbase starts for you if it doesn't get
any other instructions...and...an explicit (named) transaction, which you
create using SET TRANSACTION, I'm sure you will find a transaction setting
that suits what you need to do.

You can set up the default transaction with the parameters you want and
actually it's recommended.

I guess you have the Embedded SQL Guide there...?

>I'm not sure what SNAPSHOT isolation is. Remember I'm using the low level
>API of isc_* calls. I didn't see anything about SNAPSHOT in the API manual.

Hmmm....are pp. 59 - 72 missing from your API guide?

H.
All for Open and Open for All
InterBase Developer Initiative · http://www.interbase2000.org
_______________________________________________________