I have images stored in my database in a FILESTREAM and I am trying to find out what the best solution is to get that image back out into a web browser.
If I was managing the files on the file system myself, the quickest way would just be:
Response.TransmitFile(pathToFile);
This does not load the file into memory before transmitting it back to the client (to my understanding) and as such is nice and speedy.
I'm currently using Linq to SQL to get the FILESTREAM. This provides the FILESTREAM as a Binary object.
So far have this quite ugly way of doing it:
Response.WriteBinary(fileStreamBinary.ToArray());
Am I going to be better off not bothering with the Linq to SQL and doing things more directly?
I'm beginning to wonder why I bothered with FILESTREAM in the first place and didn't just stick to managing the files myself. I'm sure there was a reason for it without using the word "bandwagon"!
This does not load the file into memory before transmitting it back to the client (to my understanding) and as such is nice and speedy.
Correct, but remember to set Response.BufferOutput
to false, the default value is true.
Am I going to be better off not bothering with the Linq to SQL and doing things more directly?
If you don't want to load the entire binary content into memory first then yes. Here's an example for streaming binary data from a database (along with enabling resumable download functionality).
I'm beginning to wonder why I bothered with FILESTREAM in the first place and didn't just stick to managing the files myself
The primary benefit is data integrity with transactional support and inclusion in database backups so you don't have to worry about disparity between database backup and file system backup. The downside has always been performance, which is what this whole filestream feature is trying to overcome. Although if they're less than 1mb on average according to this document it's actually faster stored in the database than in the file system.
In Sql Server 2012 there's a new feature coming called FileTables that builds on FileStream support. Basically it acts like a database view of a filesystem directory in that files added to that directory are automatically added to the database FileTable (is a fixed schema table, which contains a Filestream binary column for the file, that you can link to from other tables). This would then allow you to retrieve a path to the file that you can feed to your Response.TransmitFile(...)
function, yet still benefit from sql Filestream support.
What about that ?
byte[] buffer = new byte[bufferSize];
int nBytes;
while((nBytes = fileStreamBinary.Read(buffer, 0, bufferSize) != 0)
{
Response.OutputStream.Write(buffer, 0, nBytes);
}
That way you never load the whole stream into memory
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With