--- In IBObjects@yahoogroups.com, Helen Borrie <helebor@t...> wrote:

> At 03:34 PM 4/12/2003 +0000, you wrote:
> >Hi, all !
> >
> >I have this huge problem with a rewritten application. I'll try to
> >explain
> >what's happening and what's done inside the application:
> >
> >1. Logging on to server
> >2. Checking table USER_SETTINGS to check it's a valid user, and if
> >found
> >valid:
> > 2.b) Load user settings.
> > 2.c) Write Logindata (machine, 'Now') to this record in an

UPDATE

> >statement.
> >3. Close transaction
>
> Do you actually COMMIT the transaction?

Yes. Sorry for mis-writing. I do a Commit;

> >4. Open TIBODataSet in a grid (only first XXX rows are shown. A
> >ReadOnly
> >dataset.
> >5. (User uses application)
> >6. When application is closing, LoginData is written, now with NULL
> >for all
> >values written upon startup.
> >
> >The error:
> >When I start 2 instances of this application with the same user

name,

> >I get
> >the "deadlock" error when closing app nr. 2. No matter if it was
> >started
> >first or last. I am fairly sure all writings to table

USER_SETTINGS is

> >committed immediately.
>
> How do you verify that the commit occurs? Are you *really* calling

Close

> on the transaction instead of a hard commit?

No. I call a Commit;. and I've been able to track execution into the
xxx.IMP file. I do not call 'Close'. An explicitly started
transaction.

> >I know the problem is within writing the last table, because the

error

> >doesn't appear if I write to another record here.
> >
> >Questions:
> >- How can this happen ?
> >- Is there a way I can *not* have the Commit; actually _commit_

when

> >called
> >explicitly ?
>
> If you call Commit and another transaction has work pending on the

same

> row. Note *transaction*, not *user*. A single user can get lock

conflicts

> when attempting to update the same row from two different

transactions.

Yes, I'd expect that. But - the problem only occurs when 2 or more
instances are started. This normally won't happen, bu I can't live
with this "error", as it indicates problems that could appear under
other circumstances.

> Helen

Thanks, BTW !