SQL Server Error 5242, 5243 (RecBase)

Hi Friends,

SQL Server 2005 users very frequently confronted with various types of assertion failures and one of such error is SQL Server Error 5242, shown as following;

Msg 5242, Level 22, State 1, Line 1

An inconsistency was detected during an internal operation in database ‘YourCorruptDatabase'(ID:10) on page (1:35293). Please contact technical support. Reference number 4.

SQL engine has logical checks in place to detect consistency problems for a row within database pages. Before SQL Server 2005 this would have resulted in fatal error that results a stack dump with an expression containing a word RecBase which is name of a class used to read elements of rows in a page logically.

SQL Server 2005 introduced two errors Msg 5242 and Msg 5243 that report all row consistency errors detected while reading a row part of standard SELECT, UPDATE etc. and you observe similar message as mentioned above in ERRORLOG. Error message says to contact technical support but before you do so, it is recommended to run DBCC CHECKDB and find out if it points to any damaged rows and database corruption and if not, you may take a call to contact technical support team.

Similar to Msg 5242, you may observe Msg 5243 in ERRORLOG. These two errors relate to the case that the offset of the variable length column offset array exceeded the value of offset for the last field of the record. You may run into these errors when running CHECKDB as part of maintenance plans or manually. The DBCC CHECKDB generally examines all the allocated pages in your SQL database and if it comes across a corrupt database page when trying to read this page, it might fail.


If you have enabled torn-page detection or page checksums for your database, you may not come across any of these errors instead you may get another error 824 by the buffer pool at the time of page read. These error codes indicate that you have corruption in structure of record. If you observe any of these errors on log, better not to ignore them and analyze if there is anything wrong with I/O subsystems. It is always recommended to preserve stack-dump and ERRORLOG in case you decide to contact technical support.

There are different repairing tools that are available in market which may help you to recover damaged data but you will have to consider the way they function, limitations (if any) and find out if they match your requirement.



Kanchan Bhattacharyya

Like us on FaceBook Follow us on Twitter | Join the fastest growing SQL Server group on FaceBook

Follow me on TwitterFollow me on FaceBook


About Kanchan Bhattacharyya

Kanchan is an astute IT professional, a seasoned SQL Database Administrator with 13+ years of industry experience. A calculated risk taker with deep technical knowledge and has gained proficiency in database consulting and solutions across different environments. Kanchan holds MBA degree in IT and an International Executive MBA in Project Management. He is very passionate about SQL Server and holds MCSE (Data Platform), MCSA – SQL 2012, MCITP – SQL 2008 certifications. Currently he is focusing on cloud and latest releases of SQL Server. When not working, Kanchan likes to spend his time reading on new technical developments specifically on SQL Server and other related technologies.

View all posts by Kanchan Bhattacharyya →

Leave a Reply

Your email address will not be published.