--- In IBObjects@yahoogroups.com, "bjorgeitteno" <bjorge@i...> wrote:

> --- In IBObjects@yahoogroups.com, Aage Johansen <aagjohan@o...>

wrote:

> > On Thu, 4 Dec 2003 16:46:49 +0000 (UTC), bjorgeitteno wrote:
> >
> > > ...
> > >> ...
> > >>> 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.
> >
> >
> >
> > Hi Bjørge!
> >
> > Can you update+commit the record from another app (e.g. IB_SQL)
> after
> > closing the first app (before closing the second)?
>
> Hi again !
> Sorry, my previous posting was abrupted, I pressed submit again,

but

> didn't see all of my reply was missing.
>
> Your question made me think, and - yes, I may update and commit in
> IB_SQL. The problem appears no matter if the update + commit is

done

> from my application or from any other. What this shows is that the
> problem is like if I started a transaction at startup, made an

update

> and upon application shutdown, when the new update takes place,

it's

> detected that another committed transaction has changed the row.
>
> I believe I'll have to do it the hard way, take a copy of the
> application, and remove stuff until I have managed to locate the
> problem.
>
> Thanks for giving me ideas !

I found the problem - a TIBOQuery creating its own Session object.
Doesn't this seem a little odd: The TIBOQuery component has a
IB_Session property - readonly. This is found by searching
it's 'owner' for a TIB_Session component. Fair enough, but one should
definately be able to specify this one manually. I create the
TIBOQuery at runtime, and had to write a workaround making it be able
to locate a TIB_Session.

Help files say nothing about this. And I don't want to hear the "use
native IBO components stuff", as this has nothing to do with not
being able to set a session object in code. One should *never* rely
entirely on component creation order - with no possibility of
overriding. Period.