Determine Scanned Image Page size from Access
-
I have scanned images stored in SQL Server 2000. I am running a series of queries against the database via Ms Access 2K.
1- File sizes of scanned images. I have managed to determine this by using the FIleLen() method against the address of the image. Works perfectly
2 - I need help to determine the page size of the scanned image. Im sure this data is contained within the file, I just need a method that can extract it via MS Access or SQL Server???
Can anyone help???
-
The most consistant advice I've seen re images is to keep them out of SQL Server altogether...just use references to the physical files stored on a LAN/SAN.
Measuring the page size is a function of the software used to generate each specific image...ie tiff, jpeg, etc. Contact your imaging software supplier for an update on their API's.
-
Thanks for the reply Andrew,
I have no control over the location of the images. This has been setup by our corporate supplier.
The images are stored as .tiffs. What do you mean by "Contact your imaging supplier......???.....API????"
-
Well, you can look up the specs on the tiff format and try to locate which parts of the file contain what you're looking for. I looked at this briefly and it looks like the tiff format is pretty complex. Here is a link to a website that talks about the file format for tiff's, hope it helps.
-
"The most consistant advice I've seen re images is to keep them out of SQL Server altogether...just use references to the physical files stored on a LAN/SAN."
IMO, this advice only works for a limited set of storage needs. FOr example, managing a folder hierarchy and update security for thousands (or more) files could be a disaster waiting to happen. Furthermore, what if the images, documents, spreadsheets etc need to be tracked for auditing purposes? Storage inside SQL Server makes this much easier and safer. In my hands, I don't see significant delays when pulling image files one at a time, or a few at a time. You can always put the image records on their own disk set (file group) to enhance the speed, etc.
On the other hand, a file system approach would probably work quite well if the image/files were always read only, or if you don't care to track changes, or if you need to pull 100s of images at one time.
Thus, its not one size fits all, IMO.
(Just thought I would add this because of all the negative hype about storing images in a table.)
-
IMO - the whole point of an image, is as a locked-copy of a document at a point in time, any modifications, should be stored seperately as overlays.
I don't work with images directly myself....but I do defer to those who's advice on a lot of SQL issues I trust to the nth degree, and their advice is consistently "keep them out of SQL", and their written arguements are well made, and don't seem to have holes.
My position was to prompt the original poster, to think of his problem as not a SQL Server one, but as an image manipulation one and to consider removing SQL Server from the roadblock on the road to his solution.
-
Thanks guys for all your replies.
I think I will have to search for help with manipulating images and remove Sql Server from the arguement.
ANyway: I hear all this talk about images in Sql dont go together like birds of the same feather......but I run an MSDE database with 4000 records each with link records to OLE rtf MW Word documents. DO these count as "images". If they do then my database runs perfectly, without a hitch thus far.
Can you point me to an article that with arguements against images in Sql Server.
Many thanks in advance.
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply