Subject | Unique Constraints being violated in Firebird |
---|---|
Author | robertgilland |
Post date | 2006-07-04T00:39:02Z |
Firebird unique constraints are being violated when forced writes are
turned off.
The following is the restoration log:
gbak: activating and creating deferred index RDB$PRIMARY50
gbak: activating and creating deferred index RDB$PRIMARY49
gbak:cannot commit index RDB$PRIMARY49
gbak: ERROR:attempt to store duplicate value (visible to active
transactions) in unique index "RDB$PRIMARY49"
gbak: ERROR:action cancelled by trigger (3) to preserve data integrity
gbak: ERROR: Cannot deactivate index used by a PRIMARY/UNIQUE
constraint
gbak:Exiting before completion due to errors
We have close to 400 customers with Firebird installed.
Below are the examples of this issue we have found;
#1;
Database = Firebrid 1.51, Superserver
OS = Windows 2000pro
UPS = NO
#2;
Database = Firebird RC1, Classic
OS = Windows 2003 server
UPS = YES
#3;
Database = Firebird RC2, Superserver
OS = Windows 2003 server
UPS = YES
#4;
Database = Firebird RC2, Classic
OS = Windows 2000 server
UPS = YES
I am 99% sure that all these database have had force writes off. We
are yet to find an example with force writes on.
Does anybody know the cause of this problem and how to prevent it?
Could this be a firebird bug? If so we do have the the GDB from
example #1 and a GBK from example #4.
Regards,
Robert
turned off.
The following is the restoration log:
gbak: activating and creating deferred index RDB$PRIMARY50
gbak: activating and creating deferred index RDB$PRIMARY49
gbak:cannot commit index RDB$PRIMARY49
gbak: ERROR:attempt to store duplicate value (visible to active
transactions) in unique index "RDB$PRIMARY49"
gbak: ERROR:action cancelled by trigger (3) to preserve data integrity
gbak: ERROR: Cannot deactivate index used by a PRIMARY/UNIQUE
constraint
gbak:Exiting before completion due to errors
We have close to 400 customers with Firebird installed.
Below are the examples of this issue we have found;
#1;
Database = Firebrid 1.51, Superserver
OS = Windows 2000pro
UPS = NO
#2;
Database = Firebird RC1, Classic
OS = Windows 2003 server
UPS = YES
#3;
Database = Firebird RC2, Superserver
OS = Windows 2003 server
UPS = YES
#4;
Database = Firebird RC2, Classic
OS = Windows 2000 server
UPS = YES
I am 99% sure that all these database have had force writes off. We
are yet to find an example with force writes on.
Does anybody know the cause of this problem and how to prevent it?
Could this be a firebird bug? If so we do have the the GDB from
example #1 and a GBK from example #4.
Regards,
Robert