Hi Volker, the daily validation is done on a backup without any user connections. For the last check i used the following statement on real database ( in iSQL)

validate table [Table] with express check;

first time there was an error on an FK, the i rebuild it and validate the table again with validate statement, express check in iSQL. There was no error concerning the FK, but a new one. Now at the PK, rebuild and update statistics show no positive effect. same error. So i will wait for validation tonight, when no user is connected.

What version and build are you running? ...perhaps an EBF might help.

First, stop everything and check the RAM. Do that before any transient RAM errors get made permanent when the resulting corrupt data is written to disk. RAM errors can manifest themselves as ANY kind of data-related symptom.

Second, check the disk(s).

Then, try creating a second table and associated keys and indexes. Copy the data. Drop the original table. Use ALTER to rename the copy table. Try this on the backup copy to see if it makes dbvalid work.

Hi Breck, everytime when dbvalid shows an error and i load the backup into a networkserver (dbsrv) the database need a auto-log-recovery. When recovery is completed, i repair corrupted index, check the complete database with dbvalid.

Next Backup is valid, no errors, no autorecovery.

is it possible thats the same problem you described with RAM oder corrupted disk

Glad you fixed it, but there should not be a need to repair indices "everytime when dbvalid shows an error", i.e. dbvalid should not report an error unless something really unexpected has happened...

Does sound like a somewhat corrupt system IMHO.