I'm storing a Word document in a SQL Server 2005 database in a varbinary(max) column. Is there a way to open this document from a VB.NET Windows Forms application without serialising to a file first (i.e. directly from the byte array I've read from the database)?
Depends on what's reading it. If it's Word, you'll probably have to serialize to a file, but if it's a function or library that can take an IO.Stream then you could wrap a new MemoryStream around the byte array and pass that.
Not really. You need to treat it like an e-mail attachment, where the file is generally copied to a temp folder that is cleaned out periodically.
Related
To be honest, I don't have any idea how filestream works. It's my first time using and experimenting on it.
So, I was able to store data in a filestream column, but I have no idea how to retrieve it or how it should look after retrieving it.
Is it possible to just click a button and then the file in the filestream column will just open? For example, I stored a ms document file in the database, then the file will open in microsoft word or i stored a pdf, then the file will open in a pdf reader. Is it possible?
Im sorry if this is a dumb question. hehe. Thank you.
FILESTREAM from the developers point-of-view looks no different than a normal varbinary(max) column. This means you will be storing binary large objects (BLOBs). SQL Server will then store those BLOBs as files on the file system, rather than storing them directly in the database.
You can treat it exactly as a varbinary column on the .NET side. Take whatever data you want to store, turn it into a byte array, and save it to the DB.
When you retrieve it, it will again be in a byte array. You will need to do something with it in order for it to be usefull (write it to a file locally, process it and display it, etc.)
Side note, you can also access the FILESTREAM BLOBs using Win32 APIs if you enable it. See this link for more info.
If I create a FileTable in SQL server 2012, and then was to drop a 4G file onto the NT filesystem (that was in the filestream), would that entire 4G file be read into the table's filestream column?
Is SQL in fact making a COPY of my 4G file? Or does the filestream column represent a pointer to my 4G file, which it begins to read on a query?
Im just trying to figure out if I added 100G of data to my file system, would that add 100G of data size to my DB.
Can someone help explain how this works? And even better point me to some docs with more detail than the MS/MSDN 'how-to' stuff?
The file table stream is stored separately in individual files using the SQL Server FILESTREAM feature, not in the normal SQL Server data files. These files are managed internally by SQL Server.
You can consider the file_stream column similarly to a pointer to the file. The file stream is still part of the database, though, and will be backed up along with the rest of the database.
No, your 4 Gb file will be stored only once, as a file on disk. Sure, there will be some small amount of metadata stored in the database, but that's all.
MDSN link.
I have an application where I'm about to save an XSD- or XML-file to DB. I use a SQL Server 2008 R2 (or later) with Entity Framework. I have a form where the user will upload a XSD or XML file. The contents of this file should be stored in DB.
I will never have to look at the specific contents of the XML/XSD once it's stored in the DB, but it will be downloaded later on.
As I see it, I have two approaches:
Approach A.
Upload file.
Read contents of file.
Save contents of file as XML.
Approach B.
Upload file.
Save file as BLOB.
What's the better option here, or is there a (better) third option as well?
Approach C.
Save XSD file to shared access storage
Store the path in SQL server
I will never have to look at the specific contents of the XML/XSD
So why put it in the DB at all?
it will be downloaded later on
Much easier to retrieve it from a file share than a DB.
We have an application that stores Word and PDF documents in a share on a server. I'm looking into the possibility of storing these as BLOBs in the associated Microsoft SQL database instead, which seems like it's probably a good idea.
Separately, an idea which I'm investigating is the possibility of allowing users to easily view all of the documents in the share associated with a case (let's imagine they're grouped into folders by case) as one continuous stream on a tablet, as if they were all one big PDF file.
I think I've worked out how to do the latter, running a web service to convert the Word documents to PDFs and then concatenate them and the extant PDFs. But that's if we continue to store the documents as files in an NTFS share. What if we stored the documents as BLOBs in MSSQL instead?
Is there a way to concatenate BLOB data so that for every, say, 10 BLOB records (which might represent Word or PDF files), I could create an 11th record which was a concatenation of the other 10 as one giant PDF?
SQL Server Blobs are not an effective way of storing files. SQL 2008 bought about a better mechanism for this called FILESTREAM ( http://technet.microsoft.com/en-us/library/gg471497.aspx) which can store the files directly on the file system but managed by SQL.
As for the files you would not be able to simply concatenate the PDF files to form one continuous file but there are several libraries that you could use to do this, potentially on the fly. This would remove the need to store the concatenated document as well.
I am using Access 2007 (VBA - adp) front end with a SQL Server 2005 Backend. I have a report that I want to save a copy as a PDF as a binary file in the SQL Server.
Report Opened
Report Closed - Closed Event Triggered
Report Saved as PDF and uploaded into SQL Server table as Binary File
Is this possible and how would I achieve this?
There are different opinions if it's a good idea to store binary files in database tables or not. Some say it's ok, some prefer to save the files in the file system and only store the location of the file in the DB.
I'm one of those who say it's ok - we have a >440 GB SQL Server 2005 database in which we store PDF files and images. It runs perfectly well and we don't have any problems with it (for example with speed...that's usually one main argument of the "file system" people).
If you don't know how to save the files in the database, google "GetChunk" and "AppendChunk" and you will find examples like this one.
Concerning database design:
It's best if you make two tables: one only with an ID and the blob field (where the PDF files are stored in) and one with the ID and additional fields for filtering.
If you do it this way, all the searching and filtering will happen on the small table, and only when you know the ID of the file you want to load, you hit the big table exactly one time and load the file.
We do it like this and like I said before - the database contains nearly 450 GB of files, and we have no speed problems at all.
The easiest way to do this is to save the report out to disk as a PDF (if you don't know how to do that, I recommend this thread on the MSDN forums). After that, you'll need to use ADO to import the file using OLE embedding into a binary type of field. I'm rusty on that, so I can't give specifics, but Google searching has been iffy so far.
I'd recommend against storing PDF files in Access databases -- Jet has a strict limit to database size, and PDFs can fill up that limit if you're not careful. A better bet is to use OLE linking to the file, and retrieving it from disk each time the user asks for it.
The last bit of advice is to use an ObjectFrame to show the PDF on disk, which MSDN covers very well here.