Error: Table CRCs do not match.

[bi76957]

Over the weekend we tried to do a binary dump and load on a 26G Progress 9.1E database, and go from a single storage area to multiple storage areas. No errors were encountered during the dump or recreating of the database, but when it came time to load, 7 tables, all of which were less than 300MB and on different storage areas, failed to load. They gave the error message: Table CRCs do not match.
Cannot load data into this table. (6713).

I then tried to restore the database on our reporting server and do an ASCII dump and load of those 7 tables, but then I encountered some data errors when I tried to load it. It gave one of the two the following error messages:

ERROR READING LINE #4352 (Offset=1365999): ** Invalid date input. (85)
ERROR READING LINE #4353 (Offset=1366284): ** The month of a date must be from 1 to 12. (80)

So with that said, can anyone tell me why those 7 tables might have failed? Also, why the data would be an incorrect format being loaded back into the database if it was in the correct format before?

Thanks for your help,
Chris

 

[Casper]

How do you create your database?
Do you dump data AND defintions from the same db?

Did you already had a look at KB P23557: http://tinyurl.com/y6laes

Regards,

Casper.

 

[bi76957]

To create the database:

prodel database-name
prostrct create database-name...

Since we were moving to multiple storage areas instead of the single one, I dumped the data definitions and added the new names of the storage areas into the *.df file. I did see the KB article you mentioned, but I used the same client to do everything.

Thanks,
Chris

 

[Casper]

So, you're sure you only changed the names of the area's in the df file and not the position of the fields?

Casper

 

[bi76957]

Correct, those were not changed.

 

[Casper]

Could you connect to both (new and old) databases and query:

FOR EACH old._file NO-LOCK WHERE old._file._file-number > 0,
    FIRST new._file NO-LOCK WHERE new._file._file-name =
          old._file._file-name AND
          new._file._crc <> old._file._crc:
     DISPLAY old._file._file-name
                 old._file._crc
                 new._file._crc.
END.

All the tables coming out of this query have different crc value (and should be the tables on which you got these errors ).

HTH,

Casper

 

[Casper]

One more thing: Are there any tables in your database who where created with SQL client?

If so then you have to recreate them as well with SQL client.
_file crc is depandent on _File-Name and _DB-lang

For 4GL clients _DB-lang = 0, for SQL89 _DB-lang = 1 and for SQL92 clients _DB-lang = 2....

Could this be your issue?

Maybe check for _DB-lang as well in the query I just gave you....

Regards,

Casper.

 

[Casper]

Hmm, I should have thought about this earlier.... but,

A df file only holds the fields etc of the database where the df was dumped from. Fields which are also used in calculating crc values are not dumped. (Fields like _field._field.rpos for example).
If a field was deleted from the source database there could be a gap in _field._field-rpos.

Look at KB 20245 for more info: http://tinyurl.com/tzh2e

So, if you happen to have any deleted fields then the field will be reordered after dump load. To create exactly the same database as the database you had , you have to recreate the database the same way the source database was made. So each change in that database should be made in the same sequence to the new database, otherwise the database crc's will never match.

Regards,

Casper.

 

[methyl]

If you have multiple ".df" files and you don't know what order to apply them you can get an idea of the database creation order from the Index Number.

[FONT=r_ansi]output to /tmp/indexordertest2.lst .
FOR EACH _Index:
FIND _File OF _Index.
DISPLAY _File-name _Idx-num _Index-name.
END.

cat indexordertest2.lst | sort -n +1 | pg

It is so important that you do create the database schema in exactly the same order. In addition to getting the CRCs to agree, the indexes must have exactly the same index number.
[/FONT]

 

[methyl]

The date format mismatch is probably caused by a mismatch of database startup parameters for the old and new databases. When we had this problem, we had dumped the database tables in multi-user with a custom ".pf" but loaded the tables in single-user with the default /opt/dlc/startup.pf ... which had the wrong date format!
The last few lines of an ascii table dump contain the critical parameters for Number Format, Date Format and Codepage.

 

[cferriol]

Are you sure you have the same -d parameter for the old one and the new one?