SQL Server Performance Forum – Threads Archive
urgentDear All, greetings. I’m inserting the pictures into the database. I’m cutting the pictures from the Scanned sheet. I’m taking coordinates on the sheets and cutting and saving into the database. Sometimes, it may happened that The cutted region would not contain any pictures(empty). How would I identify that empty pictures, though its occupying some space.
Im assuming you are storing the image data in a TEXT or IMAGE field ? Since images are binary data, and dependant on the file format encoding, you cannot tell just by looking at the raw bytes whether a picture is blank or not. I would say that whatever process is inserting the images, should check to see if they are blank, and if so then do not insert it.
Also, just because SQL provides the ability to store images in the database, does not mean it is always a good idea to do so. It can have performance implications, and can often be difficult to work with depending on the client technology accessing it.
Here is a link that might help you decide about storing images in database.
True, I agree with chappy. In our case, we were able to survive by storing the images as physical file on the server. So the overhead was saved. But in this case, the concurrency was not a problem. So if u want to have ACID properties for images, store them in database. Gaurav
Although it is not entirely impossible for you to use T-SQL to check if the piece of data you are saving into SQL Server contains an image or not, the preparatory work may not be worth it. 1. Based on whatever image format you are using, you will have to determine through testing what a ‘blank’ image is. The byte sequence or pattern might give you an indication. Check the byte pattern within the image field in your table. 2. It should not be difficult to compare any incoming data with your template (sequence of bytes). This will be slow and the there is no guarantee of 100% accuracy. As Chappy said, the client is the best place to check for ‘blanks’ and will be much faster. Nathan H.O.