May be you start the updating program twice at the same time?
You may try to disable the update-triggers of the problem table on a
test database.
You may need to correct/fix some of them.
If this doesn't help, try to update partially - just to understand if
the number of records affects.
Something like this:
FOR SELECT FIRST 300 PART_ID FROM PARTS WHERE INMRP <> 0
INTO :ID
DO UPDATE PARTS SET INMRP = 0 where PART_ID=:ID;
FOR SELECT FIRST 300 SKIP 300 PART_ID FROM PARTS WHERE INMRP <> 0
INTO :ID
DO UPDATE PARTS SET INMRP = 0 where PART_ID=:ID;
....
You should avoid such mass updates.
Ivan

--- In firebird-support@yahoogroups.com, "dr_john_mp" <dr.john@...> wrote:
>
> We have a program that regularly generates an error when executing the
> update SQL below when running overnight and its the only active
> program/connection (Linux classic server LI-V2.0.1.12855 Firebird 2.0)
> but always works in the day when there are multiple users accessing
> the same data.
>
> The only obvious difference is that overnight it has to clear >6000
> records (out of 36000) whereas during the day the number is usually
< 1000
>
> SQL = 'UPDATE PARTS SET INMRP = 0 where INMRP <> 0 '
> INMRP is defined as INTEGER DEFAULT 0 NOT NULL
>
> Error message = 'deadlock
> update conflicts with concurrent update'
>
> The program closes all its SQL's and transactions prior to executing
> this one. I trap the failure and then step through each records with
> INMRP<>0 and clear them individually - which always works.
>
> Question - is this actually a deadlock, or simply the server timing
> out the SQL because of the number of records being updated ??
>