How do I convert a SQL Server backup file into . BAK for . CSV?

Asked

Viewed 1,421 times

1

The file was generated from SQL Server. I would like to convert it into a visual file, type . CSV, it is possible?

  • Dude, I don’t know the purpose of this, but you can export your table data to a TXT file using one of MSSQL’s own resources: tasks + generate scripts. Another way to do this is to create a tool that reads your table and writes the data to a file in TXT. Note the amount of records in the tables. If applicable, separate the files by date!

2 answers

1

Dude, this type of conversion does not scroll, because sql bak file are actually native SQL statements like table creation, Inserts, etc..

  • would have to install SQL Server and view it anyway?

  • That’s right, install SQL, restore the base, then you can view.

  • 1

    @Ivanteles Who knows how to add in your answer this idea of restoring the base. It is better than "[...]does not roll"

0

Understanding the file . BAK

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

To understand what a database is, I recommend reading of this reply by Maniero.

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 scheme, as are the databases that speak SQL, there is a whole study to keep your data normalized. You wouldn’t need to follow these normalizations, but Codd demonstrated that normal forms facilitate the maintenance of structures.

To know how to manipulate data, a database needs to know information about this data: the metadata of 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.

Beyond 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 several interesting things, such as keeping the system coherent or updating the bank with new information when another one arrives.

We also have user-defined database manipulation procedures. And also functions, which process data into other data.

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

After all this, we have the views. Initially, the views are already pre-selected data through a query. To make the situation interesting, views allow all the traditional DML, such as selection, insertion, update and deletion. Due to this ability to have data changed, views may have triggers as well as tables. If not enough triggers, sometimes consulting a view ends up being expensive, so you can create an index for it! In this case, the view becomes materialized in the database: the information is no longer simply rescued from the original tables, but from data written in the file that was obtained through these original tables.

Extracting the data

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

Also, don’t forget: possibly all the information in the file might be compressed, in a pattern you’ll need to search to see what it is. Also, to avoid some unwanted behaviors, often the large database in the file stretches abandoned on purpose, does not come within the scope of this reply to talk in detail about that strategy in storage.

But you have someone who already does all this work for you. It’s SQL Server itself. If you want to minimize your work, do as Ivan Teles suggested en his reply and restore the base. If you want to have a slightly bigger job (lying, it would be much major), you can try to go after some official Microsoft documentation explaining how it lunch the data inside the . BAK, which I do not believe is an easy and simple information to find.

Browser other questions tagged

You are not signed in. Login or sign up in order to post.