Man, this type of conversion does not roll, because the sql BAK file is actually native SQL statements like creating tables, inserts, etc.

Understanding the .BAK File

The .BAK file is a system restore point file. It allows you to restore everything in your database.

To understand what a database is, I recommend reading this Bigown answer .

Database Management Systems

The famous DBMS. They allow you to work with the database evenly. If it were not for them, you would have a proprietary structure in a file, often with specialized ability.

They allow you to put generalized information in them. In a relational schema, such as banks that speak SQL, there is an entire study to leave your data normalized . You would not need to follow these normalizations, but Codd has shown that normal shapes make it easier to maintain structures.

To know how to manipulate the data, a bank needs to know information about this data: the metadata of the tables and columns. So, for effective and real reading of data whose structures are not defined a priori, it is necessary to know how to find these metadata to know how to read the data.

In addition to the structure

SQL Server allows you to do many things besides simply storing data in arbitrary structures. There are also limitations / constraints. They can be of multiple types, such as uniqueness in the table, foreign key of another, not null, values in a limited set.

In addition to these restrictions, we also have triggers. Triggers serve for several interesting things, such as keeping the system consistent or updating the database with new information when another one arrives.

We also have procedures for user-defined bank manipulation. And also functions, which process data in other data.

In addition, to allow a more efficient reading of the database, there are indexes, which are data about the data more or less informing how they are arranged in the physical file in order to search efficiently.

After all this, we have views . At first, the views are already pre-selected data through a query. To make the situation interesting, views allow for all traditional DML, such as selection, insertion, update, and deletion. Because of this ability to have data changed, views can have triggers as well as tables. If triggers were not enough, sometimes looking at a view turns out to be expensive, then you can create an index for it! In this case, the view becomes materialized in the database: the information is no longer simply retrieved from the original tables, but rather from data written to the file that was retrieved through these original tables.

Extracting the data

You want to extract the data, do not you? To do this, you must first remove everything that is not given metadata from the file, as well as possibly the data from materialized views, to read only what matters. After you do this separation, you will need to understand how to read the metadata from the table, then start retrieving each row individually. Also do not forget that integer data is stored in binary mode, so I do not store 123456 in 7 characters, but in 4 bytes (if it is integer type). You will need to remember to read the binary to produce the CSV text

Also, do not forget: possibly all the information in the file may be compressed, in a pattern that you will need to search to see what it is. And also, to avoid some unwanted behaviors, often the database wide in the file snippets purposely abandoned, it is not within the scope of this response to talk in detail about this strategy in the storage.

But you have someone who already does this whole job for you. It is SQL Server itself. If you want to minimize your work, do as Ivan Teles suggested en your answer and restore the base. If you want to get a slightly bigger job (lying, it would be much bigger), you can try to go after some official MicroSoft documentation explaining how she lunges the data within .BAK, which I do not believe be an information easy and simple to find.