I have the above error when I try to do the following code.

System setup :

IB 6.01

On a DataModule I have two sets of  TIBQuery with their own TIBUpdateSQL,
and their own TIBTransactions.

The TIBQuery's have cached updates = True.

Imagine if you will a table that I am accessing records from , when I am
using a record I want to mark that it is in use.

So LogQuery is the TIBQuery I access these records from , and SetLockedQuery
is the Query I use to mark that record in use.

I have the following even handlers :

LogQuery Before Edit : // I call a procedure to lock the specific record,
this then fires the following event :

  with ADataset as TIBQuery do begin
    if not Transaction.InTransaction then
      Transaction.StartTransaction;
    Try
      if UpdatesPending then ApplyUpdates;
      Transaction.Commit;
    Except on e:Exception do begin
      Transaction.Rollback;
      end;
    end;
  end;

This fires and all seems fine. It is when I then come to save my changes to
the logQuery record :

LogQueryAfterPost :

  if not DBLogTrans.InTransaction then
    DBLogTrans.StartTransaction;
  Try
    if LogQuery.UpdatesPending then LogQuery.ApplyUpdates;
    if LogActInsQuery.UpdatesPending then LogActInsQuery.ApplyUpdates;
    DBLogTrans.Commit;
  Except on e:Exception do begin
    DBLogTrans.Rollback;
    end;
  end;
  RefreshTrackingScreen;

The ( if LogQuery.UpdatesPending then LogQuery.ApplyUpdates;) line when
running causes the Deadlock error.. I am confused,, if I do not do any of
the locking this code works fine..

Any Ideas what to look for please ????

Martin

        Two things:

1)  If you "lock" a record by doing a meaningless update and hold the
transaction open, then you'll get a deadlock if you try to update the
record from another transaction, even if it's in the same program.
That's the whole point of the lock!

2)  Record locking tends to become a bottleneck in a multiuser
environment, and I recommend that you don't do it.  Instead, handle
deadlocks intelligently on the infrequent occasions when they occur.

        -Craig

--
 Craig Stuntz (TeamB) Vertex Systems Corp. Columbus, OH
We're hiring: http://www.vertexsoftware.com/careerops.htm#sd
     Delphi/InterBase WebLog: http://delphi.weblogs.com