Subject | Duplicate entries ... |
---|---|
Author | Lester Caine |
Post date | 2011-08-05T13:17:24Z |
I had a bit of trouble on a site yesterday which I'm not sure I understand ...
The raw data is basically two tables, one with an entry using a generator value
key, and the second 'detail table' has a primary key of the same generator value
+ a transact_no. The detail table is populated by a trigger on the master table,
when one field changes, the current state is stored in detail, and the master
entries updated. The trigger is just using a MAX+1 for the transact_no, and has
the primary key unique index, but in theory a user will be take several seconds
between each action on an individual ticket, and the times confirm that.
The problem yesterday was that I ended up with two sets of 2,3,4 with time
between each indicating that they SHOULD have been different transactions. I
corrected things easily enough via Flamerobin, just copying the 6 problem
records as inserts, which I fixed the numbers on, then I deleted the rows and
added back the corrected ones.
The question ... would this have had to have been several stuck transactions
that had not commited? I had to gfix, backup, restore without indexes enabled,
fix duplicates then re-enable indexes to get the database live again. But it's
the first time I've seen this problem in 14 years of interbase/firebird data -
some 30 million master records across dozens of sites. Obviously I'm wondering
if I have a hole I a missing ;)
--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
The raw data is basically two tables, one with an entry using a generator value
key, and the second 'detail table' has a primary key of the same generator value
+ a transact_no. The detail table is populated by a trigger on the master table,
when one field changes, the current state is stored in detail, and the master
entries updated. The trigger is just using a MAX+1 for the transact_no, and has
the primary key unique index, but in theory a user will be take several seconds
between each action on an individual ticket, and the times confirm that.
The problem yesterday was that I ended up with two sets of 2,3,4 with time
between each indicating that they SHOULD have been different transactions. I
corrected things easily enough via Flamerobin, just copying the 6 problem
records as inserts, which I fixed the numbers on, then I deleted the rows and
added back the corrected ones.
The question ... would this have had to have been several stuck transactions
that had not commited? I had to gfix, backup, restore without indexes enabled,
fix duplicates then re-enable indexes to get the database live again. But it's
the first time I've seen this problem in 14 years of interbase/firebird data -
some 30 million master records across dozens of sites. Obviously I'm wondering
if I have a hole I a missing ;)
--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php