Deadlock is your friend. It is telling you that your data is being used in a
way that could lead to possible problems due to a conflict between users.

I have seen a lot of things proposed to "solve" the problem that actually
create real problems.

First of all, a well normalized database that uses surrogate keys without
cascading ref integ is a good place to start. Second, watch what your
triggers are doing. Be sure not to be maintaining any statistical
information directly. These should be done using a separate transaction
working off a rollup table fed by the triggers via inserts. Third, make sure
you are using good transaction usage patterns with the right isolation.
Commit as often as you are able and make sure that the user cannot leave a
transaction open for too long with edits in limbo.

That's it in a nutshell...

Keep in mind that cached updates are a way to "work around" the normal
integrity constraints of the server. They may cause you to never see a
deadlock exception any more but you are then taking responsibility of data
integrity in your application code. The server will not tell you any longer
that one user just trampled over another users work. This is no trivial
problem to solve and cached updates, IMO, can be a source of major problems
when a system gets loaded. Use them carefully.

Regards,
Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com

----- Original Message -----
From: "Ruslan Popov" <ruslan@...>
Newsgroups: borland.public.delphi.database.interbaseexpress
Sent: Friday, January 26, 2001 10:06 PM
Subject: Avoid deadlocks: CachedUpdates, MIDAS, other?


> Hello,
>
> Want to ask developers having many years experience in C/S development
using
> IB: what are best practices, proved by time, to aviod deadlocks (in a
> generic C/S application)?
>
> A reference to an article in Internet or magazine would be great.
>
> Thanks in advance,
> Ruslan
>
>
>
>