A row on page %Id was accessed that has an illegal length of %d in database '%.*s'.
This error occurs when an attempt is made to access a row on a page and the actual length of the row is greater than expected. The error indicates that there is a structural problem on the database page accessed during a read or write operation, and it involves a specific row from that page.
This structural problem can occur as a result of the following:
If the problem occurred after a load, check the sysusages system table and make sure that the database you created has the same fragments and segmaps in sysusages as the database that generated that dump. If not, drop the database, re-create it with correct fragments and segmaps, and then reload the database.
If the error is not associated with a database load operation, run DBCC CHECKDB and DBCC NEWALLOC to determine the full extent of the structural problems in the database. Examine the output from these commands; if the DBCC statements reveal other structural problems in the database, resolve those first.
If there are no other errors, examine the page referenced in the error message to determine which table is damaged. (For more information about associating a page with an object, see Chapter 24, "Additional Problem Solving Techniques.") If the page is associated with an index, it is sometimes possible to resolve the problem by dropping the index and re-creating it. If the page is a data page and a clean current backup is available, recover the database from that backup.
If no backup is available, try to select the table into another table or bulk copy the data out of the table, drop the table, re-create it, and then select the data back in.
If this error occurred during recovery, the syslogs table is corrupted. The database will be marked as suspect. Recover it from a clean backup. If the page was found to be associated with syslogs, use:
DUMP TRAN with no_log
Although this may resolve the problem, be sure to also run DBCC CHECKDB and DBCC NEWALLOC. Review the output; if there are no structural problems, immediately dump the database.
If you suspect a hardware problem, run available hardware diagnostics and disable write caching if it is enabled on the controller. Contact your hardware vendor for problems reported in the diagnostics and for persistent read/write problems. Verify with the vendor that the hardware-specific HAL layer components are current and at the recommended levels.