End of file reached. Error 38 in SQL. Passes verification checks

Posted on

Question :

Having issues restoring a database in SSMS, error 38.

The databases are transferred up to google via their Drive API.

Download it on my side and has error.

If I transfer it through teamviewer from client PC I still get the same error.

Only happening on two clients the rest are fine.

I have tried backing up with FORMAT options and WITH CHECKSUM. Both succeed and backup is taking when verifying.

I have ran restore fileheaders only and get proper data except the physicalname path has a lowercase ‘c’ for the drive on the problem databases.

I have read this could be a corrupt database but I don’t understand how the checksum and verify sql functions pass if so. Any insight would really help.

This is the backup command used in C#

"BACKUP DATABASE " + database + " TO DISK = '" 
+ database + "_" + dateTime.ToString("yyyy_MM_dd_HH") + 
"_CloudBackup.bak' WITH NAME = 'database', INIT, CHECKSUM"

EDIT: Running dbcc check on the database produced no errors. I have tried updated the physical name of the .mdf and .ldf it does not work still. Taking a backup from SSMS produces a valid backup file. It has something to do with the services I wrote.

EDIT 2: I am restoring through SSMS GUI. I have also tried RESTORE DATABASE db_name FROM 'backup_path'

Commands

RESTORE VERIFYONLY FROM DISK = 'backup_path'

On both computers, mine and the server PC yields “The backup set on file 1 is valid.”

RESTORE FILELISTONLY FROM DISK = 'backup_path'

Have only test on my PC. Returns paths to mdf and ldf, no errors.

Both PCs have sql server 2012 (SP1)

Answer :

I removed all compression all together (zipping the .bak via ZipArchive library in .NET) and pass it up to google and it works fine now. Something must be going wrong in the compression. Thank you for the lead into looking at compression =)

Originally left in a comment by user Austen Swanson (the OP).

So rather than the database being corrupt, the backup was getting corrupted in the process of trying to compress (or decompress) it using third-party compression.

Leave a Reply

Your email address will not be published. Required fields are marked *