I verified the .bak file did indeed come from a Microsoft SQL Server. It is not encrypted. It is doubtful that it was created from Microsoft SQL Server 2012 because the old system was several years old. The import was attempted using a temporary install onto a Vista machine with SQL Server 2008 R2.

The goal is to get the data into either a different database (for example, using ODBC), or into a plain data type (.csv, .sql, .xml, etc) that we can create an import program for.

Do you suggest a different method other than TSQL for performing this import?

Do you have an alternate explanation for the error message? I am not inclined to guess whether I should try again on a newer or older SQL Server Version because every re-install takes a significant amount time, which is a limited resource.

I am not directly able to access the server it came from.
–
George BaileyJul 25 '12 at 21:41

Does this also mean that you might not have been given the full set of .BAK files that make up the backup set?
–
Chris McKeownJul 25 '12 at 21:44

It is possible, but I expect that if there is more than one bak file, they would have sent them all. I will attempt to determine, just wanted to get input here, in case I am missing something. So far it just appears to be either a version mismatch, or actually a corrupt file, or lack of files. I don't yet know if I should try using an older or newer version and attempt the import again.
–
George BaileyJul 25 '12 at 21:49