Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
AskSQLTeam
Ask SQLTeam Question
0 Posts |
 Posted - 2002-05-20 : 08:31:22
|
| Cogito writes "I have started to look at upgrading my SQL6.5 database to SQL2000 and encountered checksum errors on some of the tables upgraded. I have done quite a few more test upgrades, on a small database, and managed to get rid of a checksum error on a table by deleteing, record by record between upgrades, all bar one record. The data in the pre and post upgrade table is all there, having checked all the tables indicated with the error.Has any done a SQL6.5 to SQL2000 upgrade and encountered this problem and is this signify a problem with the Data or TableGreatly appreciate any assistance. Getting very fustrated." |
|
|
Kevin Snow
Posting Yak Master
149 Posts |
Posted - 2002-05-20 : 12:57:56
|
| Both SQL Server 6.5 and 7.0 calculate the checksum by taking each byte of data in a field and adding its byte value to come up with a single number that represents that field. This value is calculated for each column and row of an entire table to come up with a single value on a per-table basis.During the transfer of data, if these numbers match on both sides, any corruption is highly unlikely. However, there is no guarantee because checksums, by their nature, are guaranteed only to catch single-bit errors.You say you are able to eliminate the checksum errors by deleting all but one record from the table. If it doesn't matter WHICH single record is left behind, then this implies that the upgrade wizard is having a problem with table structure. Run your own checksum routine based on the description above. It is possible that the error reported is really a conversion that is being misreported. Getting the same cheksum from your own routine off the pre and post upgraded tables would help verify that.Isolating the offending columns/data types is your next step. Check the tables with error to see whether they are using a common datatype not used in the successful tables. You may nulling columns by datatype to see if that also eliminate the checksum errors.Lastly, Are you using replication? There are conversions from TIMESTAMP to Unique Identifiers that may fail the check (Although the wizard is supposed to be smart enough not to count these).If non of these pan out, post the results and I'll try to come up with some more suggestions. |
 |
|
|
cogito
Starting Member
3 Posts |
Posted - 2002-06-12 : 05:31:36
|
| I have found that the best route to upgrade from SQL6.5 to SQL2000 is upgrade to SQL 7 first, no checksum errors were reported and the do a forced restore to SQL2000. |
|
|
|
|
|
|
|
|
SQL 6.5 to SQL2000 Checksum Errors