|
|
|
Old Hand
      
Group: General Forum Members
Last Login: Wednesday, May 15, 2013 1:33 PM
Points: 304,
Visits: 167
|
|
Is it possible to read a backup file directly and determine the version of the server that created it? I've been Googling for it for a while but haven't been able to find anything. I did find a utility (SQL BAK) that can do it but I need to include this capability in my app. Anyone know how to read a backup file?
|
|
|
|
|
SSC-Dedicated
           
Group: General Forum Members
Last Login: Today @ 10:47 AM
Points: 37,729,
Visits: 29,990
|
|
No need to read the backup file manually.
RESTORE HEADERONLY FROM DISK = <path to backup file> Among the columns are SoftwareVersionMajor, SoftwareVersionMinor and SoftwareVersionBuild that tell you the version and service pack of the server that the backup was taken from.
Gail Shaw Microsoft Certified Master: SQL Server 2008, MVP SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
We walk in the dark places no others will enter We stand on the bridge and no one may pass
|
|
|
|
|
Old Hand
      
Group: General Forum Members
Last Login: Wednesday, May 15, 2013 1:33 PM
Points: 304,
Visits: 167
|
|
GilaMonster (3/6/2013) No need to read the backup file manually. Yes there is. The system they are installing on may not yet have SQL Server installed on it. I will need to know what version of SQL the backup came from in order to validate what I will let them install.
|
|
|
|
|
SSC-Dedicated
           
Group: General Forum Members
Last Login: Today @ 10:47 AM
Points: 37,729,
Visits: 29,990
|
|
Copy the backup to a machine that has SQL server (or to a machine that a SQL server instance can see across the network) and run a restore headeronly. Even a SQL express instance on a laptop is good enough.
Gail Shaw Microsoft Certified Master: SQL Server 2008, MVP SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
We walk in the dark places no others will enter We stand on the bridge and no one may pass
|
|
|
|
|
Old Hand
      
Group: General Forum Members
Last Login: Wednesday, May 15, 2013 1:33 PM
Points: 304,
Visits: 167
|
|
OK, so one of my coworkers opened a backup file from a 2005 server and a 2008 in a HEX editor server and found where there was a difference in the header of the file and it turns out that at position 3756 (0x0EAC) there is a two byte value that when converted to an integer is the internal database version. Here's some C# code to get it:
FileStream f = new FileStream("C:\\SQLData\\MyBackupFile.bak", FileMode.Open); byte[] b = new byte[2]; f.Seek(3756, SeekOrigin.Begin); b[0] = (byte)f.ReadByte(); b[1] = (byte)f.ReadByte(); Int16 dbVersion = BitConverter.ToInt16(b, 0); f.Close();
|
|
|
|
|
SSChampion
        
Group: General Forum Members
Last Login: Today @ 10:37 AM
Points: 11,640,
Visits: 27,723
|
|
tried your code, and it doesn't work on all situations;
it found SQL2005 as version 611 just fine, but only that for me.
For others(i have all on my dev machine), it returned: zero for a SQL2008 database with version 655, zero for 2008R2 database with version 661 zero for 2012 database with version 706
i didn't have a 2000 database backup to test with.
Lowell
--There is no spoon, and there's no default ORDER BY in sql server either. Actually, Common Sense is so rare, it should be considered a Superpower. --my son
|
|
|
|
|
Old Hand
      
Group: General Forum Members
Last Login: Wednesday, May 15, 2013 1:33 PM
Points: 304,
Visits: 167
|
|
there might be something in the header that might be causing that to shift position. In my case the database name being backed up was always the same. So, a different database name might shift where that value it located. I'll do a little more checking.
FYI, I had tested it on a SQL 2008 R2 backup file and 2005 backup
|
|
|
|
|
Old Hand
      
Group: General Forum Members
Last Login: Wednesday, May 15, 2013 1:33 PM
Points: 304,
Visits: 167
|
|
I tested this against various database backups from SQL 2000, 2005, and 2008 and it worked as advertised. There were backups taken from different servers and with different database names. It would not make much sense that this header info has changed from version to version since that would just involve more coding to determine the version when restoring a backup. Not sure why it would return such erroneous results for you.
|
|
|
|
|
Old Hand
      
Group: General Forum Members
Last Login: Wednesday, May 15, 2013 1:33 PM
Points: 304,
Visits: 167
|
|
Also, if you would like to use this in PowerShell just execute the following to create a new object type
Add-Type -TypeDefinition @" using System; using System.IO; public class GetSQLBackup { public static int getDbVersion(string backupFilePath) { FileStream f = new FileStream(backupFilePath, FileMode.Open); byte[] b = new byte[2]; f.Seek(3756, SeekOrigin.Begin); b[0] = (byte)f.ReadByte(); b[1] = (byte)f.ReadByte(); Int16 dbVersion = BitConverter.ToInt16(b, 0); f.Close(); return dbVersion; } }
"@
After executing this you can call it like this:
[GetSQLBackup]::getDbVersion("C:\\SQLBackups\\YourBackupFile.bak")
|
|
|
|
|
SSC Eights!
      
Group: General Forum Members
Last Login: Friday, May 17, 2013 12:37 PM
Points: 941,
Visits: 1,041
|
|
Gail's approach would be the recommend way, instead of you trying to reverse engineer it. SQL Express doesn't cost anything and you can quickly find out, instead of putting all this effort in for reverse engineering. IMHO.
---
Mohit K. Gupta, MCITP: Database Administrator (2005), My Blog, Twitter: @SQLCAN. Microsoft FTE - SQL Server PFE
* Some time its the search that counts, not the finding... * I didn't think so, but if I was wrong, I was wrong. I'd rather do something, and make a mistake than be frightened and be doing nothing. 
How to ask for help .. Read Best Practices here.
|
|
|
|