Working with SQL Server BLOB Data in .NET

Share on TwitterShare on TumblrSubmit to StumbleUponSave on DeliciousDigg This


Binary Large Objects (BLOBs) are pieces of data that have -usually- exceptionally large size (such as pictures or audio tracks). These values stored in SQL Server in an imagecolumn.

Sometimes the term BLOB is also applied to large character data values, such as those stored in text or ntext columns.

Also you can store BLOB data in a binary column, but it doesn’t take larger than 8000 bytes. And image columns are more flexible.

Working with BLOB data is a bit strange because:

  1. You don’t know how much size will be the retrieved data.
  2. The data may be very large so we need to retrieve it in chunks.

Our example is fairly simple. This example stores files in a database (FileStore) and retrieves it by name. The example relies on a database that contains one table, MyFiles. And the table itself contains two columns one for filename (PK) and the other is an imagecolumn for the file itself.

Storing BLOB Data

Storing BLOB data in a database is easiest part:

In order to run this code, you must add using statements to Sql.Data.SqlClient and System.IO.

static void StoreFile(string filename)


    SqlConnection connection = new SqlConnection(“Server=(local) ; Initial Catalog = FileStore ; Integrated Security = SSPI”);

    SqlCommand command = new SqlCommand(“INSERT INTO MyFiles VALUES (@Filename, @Data)”, connection);

    command.Parameters.AddWithValue(“@Filename”, Path.GetFileName(filename));

    command.Parameters.AddWithValue(“@Data”, File.ReadAllBytes(filename));




Code explanation:

First, we created a connection to the SQL Server database. And then, we created the SqlCommand object that will hold the T-SQL Insert statement. After that, we filled the command parameters with required values. Finally, we executed the command.

Well, for avoiding SQL-Injection attacks, it’s recommended that you use parameters instead of hard-coding the argument. Moreover, you can’t represent binary values as strings. Frankly, it’s recommended using stored procedures instead of coding the commands.

It’s highly recommended that you dispose disposable objects like SqlConnection and SqlCommand. Try encapsulating it in a using statement.

Retrieving BLOB data

Retrieving BLOB data is a bit complex than storing it. The following method demonstrates this:

static byte[] RetrieveFile(string filename)


    SqlConnection connection = new SqlConnection(“Server=(local) ; Initial Catalog = FileStore ; Integrated Security = SSPI”);

    SqlCommand command = new SqlCommand(“SELECT * FROM MyFiles WHERE Filename=@Filename”, connection);

    command.Parameters.AddWithValue(“@Filename”, filename); connection.Open();

    SqlDataReader reader = command.ExecuteReader(System.Data.CommandBehavior.SequentialAccess);


    MemoryStream memory = new MemoryStream();

    long startIndex = 0;

    const int ChunkSize = 256;

    while (true)


        byte[] buffer = new byte[ChunkSize];

        long retrievedBytes = reader.GetBytes(1, startIndex, buffer, 0, ChunkSize);

        memory.Write(buffer, 0, (int)retrievedBytes);

        startIndex += retrievedBytes;

        if (retrievedBytes != ChunkSize)            




    byte[] data = memory.ToArray();


    return data;


Code explanation:

After connecting to the database and writing our query, we executed the query by calling ExecuteReader() method of the command object to get read-only forward-only pointer to the retrieved rows.

By default, SqlDataReader reads entire rows -that can be gigabytes of data.- By specifying CommandBehavior.SequentialAccess, it reads the data sequentially in a given chunk size by calling the GetBytes() -or GetChars for BLOB textual data- method.

Calling Read() of the SqlDataReader objects advances the pointer to the next row which is the first single row -if found- in our example.

The GetBytes() method takes five arguments:

  1. The column index.
  2. The index of which to start reading.
  3. The buffer object that will keep current retrieved data.
  4. Index in buffer of which to begin writing t.
  5. The length (chunk size) of the data to retrieve.