At 09:36 PM 1/12/2007, you wrote:

>Hello Firebird User's
>
>Sorry my bad bad English
>
>I have a BIG problem. It's serious problem envolving Integrity of Database.
>I Have 200 users with Firebird database. One users was related problem with
>tables and integrity.
>My strutcture have table Salles and SallesItens. Salles have ORDSALLES
>(primary key) and SallesItens have (ORDSALLESITEM = primary Key) and
>(ORDSALLES = foreign Key) and is mandatory NOT NULL. My operation in
>Software (exe) is envolved in Transaction (Commit Rollback).
>This structure and one user, 4 registers exists in SallesItens and NOT exist
>in Salles. !!!!
>The integrity is hability and functional. Both that when set ORDSALLES in
>SallesItens with Value not existent in SALLES, the integrity indicates Check
>Consistence.
>
>But, the error exist and the client is Bad :-) . The biggest problem is the
>lost of credibilite for Firebird, in my Job.
>
>Then, i must find the possible cause, urgently
>- Database was Corrupted? Why?

It is probably a logical corruption, caused by inactive constraints or constraint indexes when the ORDSALLES rows were created.

>- Energy Oscillation? It's frequelty cause?

No. "Power spikes" can cause physical damage to the hard disk which, in turn, may cause physical corruption to data affected by the damage. Usually in such cases you cannot connect to the damaged database at all. So - if you have production databases running in an environment with bad power supply, you need a good UPS to protect the disk. (UPS = Uninterruptible Power Supply).

However, there is a situation where power spikes *can* corrupt data. If a power spike takes your server down and you have your database configured with Forced Writes OFF, you will have these troubles if the waiting cached writes don't reach the disk. In your checking, run gstat -h on the database and note the Forced Writes setting in the Attributes at the end of the output. See also the last note at the bottom of this message.

>- Transaction Abort?

There is no such thing as "Transaction Abort". When your system is healthy, a client application starts the transaction and also ends it, in one of two ways: COMMIT completes the transaction, while ROLLBACK undoes all work that the transaction has performed.

>How to recover?

First, find out whether you can insert a row into SALLES having the primary key that the orphann SALLESITENS records need. If you can do that, you have solved the immediate problem.

>Thanks for Help, It's important.

It's even more important to find out why this happened. If you have a disabled constraint or constraint index, you have to fix that, or the problem will recur.

How can that kind of thing happen? Restoring with the -Recreate_database switch and allowing users to log in during the process, before the constraint indexes have been built will cause it. Don't use -Recreate_database...

Alternatively, a Restore (using either -Create_database or -Recreate_database) may have ended with an exception, after the data was loaded but before the rebuilding of constraint indexes was completed. If you are doing unattended Restores then make sure you log them.

You need to know that restores are always done with Forced Writes OFF, even when the database is configured with Forced Writes ON. So - if a Restore was interrupted by a power failure, the restored database is very likely to corrupted logically, even if there was no physical damage. The remedy for that is to perform a fresh restore and monitor it, to ensure that it completes.

./heLen