Hi Helen,
Thanks for the reply, i understand that its always my fault, my wife
and kids tell me that every day, so that aint news, nut the reason i
asked the question was that the since upgrading our IBO components
we are now using a transaction on each form that is set to
ticommited, and this generally works VERY well for us regarding
lockups and apparent hangs. its just that our forms that are opened
by the users, that tend to open a record for edit, then go on
holiday, this i know is my fault because i use to time the user
screen, then after 1 hour of doing nothing i would drop the program
and log the user off.....boy did that get their attention..well
after 10 seconds of dialog from the big boss that "Feature" was
removed. So i still have users half editing forms and going to
meetings, etc.. this means that the record id locked and id prefer
to cancel any changes, do a rollback so other users can get running.
but half the time i find it impossible to find out exactly who in
the building is locking a record. Sorry just the bad way a put the
question.

Colin ;-)

--- In firebird-support@yahoogroups.com, Helen Borrie <helebor@...>
wrote:

>
> At 10:12 PM 7/03/2006, you wrote:
> >Every now and then our Delphi 7 app, running against a FB 1.5.x

server

> >decides to throw a lock conflict at the users, up till now the
> >solution has been for all the users to log out one by one untill

the

> >lock is released and then they can all carry on again, bit of a

pain

> >when 70 users plus are logged in.
>
> I'm trying to digest this.
>
>
> >Is there a way of asking the server what lock conflicts are

active and

> >which connections caused them?
>
> A lock conflict is the *designed* behaviour whenever one

transaction

> tries to post a change to a row that conflicts with another user's
> change to that row.
>
> >would make my life very easy then to tell the locking connection

to

> >save / abort.
>
> A lock conflict is "personal" to the transaction that encounters
> it. Your user application should be written to catch the

exception

> that the engine returns to the application, and provide a handler

for it.

>
> It's not the "locking connection" that should "save/abort", it's

the

> one that gets the exception that should take some action. What

that

> action should be depends on three things, first: what you as the
> application developer want to allow; second: how you as the
> application developer have configured the transaction; third:

what

> you as the application developer have provided to handle the
> particular locking conflict that occurs (there are several

different kinds!)

>
> Shutting down the system is one way to resolve lock conflicts,

just

> as burning the house down is one way to avoid cleaning the windows.
>
> ./heLen
>