Creating a Database to Store .pdf Files

[Bill6868]

Using Access 2007 I’d like to create a database that would store lots of .pdf files. A one-to-many relationship: an employee’s profile would have many records associated with it and each of these records would contain one .pdf file embedded in the form in a Bound Object Frame.

I can do this, but my question is one of file space. For instance, I also have a database that contains 3,200 records and over 1,700 .jpg photos which are embedded in an attachment data type field on the form. Access automatically compresses the .jpg file nicely, and as huge as this database is, it has grown to only to 98MB. Sweet!

Storing .pdf files in a database…is this practical? I don’t see why not, but will Access auto compress the .pdf file in a Bound Object Frame as it does the .jpg in an attachment field? My data type for the .pdf file would be an OLE Object.

Any cautionary suggestions before I attempt to do this? I’m not talking of thousands of .pdf files but I’m thinking of about 300-400 files, all of them between 1 and 4 pages long. I guess I could first compress the .pdf file in Adobe Acrobat, but do I need to do this?

Thanks to everyone at Tek-tips for all the knowledge I have gained over the years. In fact I have a database just to keep track of everything I’ve learned on Tek-tips. Much appreciated.

Bill6868

 

[Andrzejek]

Just a suggestion here…
Have you considered keeping your PDF files somewhere on the (shared) Server and keep just the path (with the file name) to the file(s) in your Access table?


Have fun.

---- Andy

 

[MajP]

Easy test
Create a blank db with an ole field and an attachment field
Total size: 366K
1. Add 3 (1 meg) pdfs using an OLE object
Total size: 17,5352K
2. Add 3 (1 meg) pdfs using attachment field
total: 20,268K

PDF are not very compressible, so if you use an attachment field the size of the db will increase basically with the size of the PDF.

If you use an OLE field the db will increase far more about 6 times the size of the file based on this demo.

So if the size of your files pluse the size of the db (without the files) will equal or exceed 2 gigs then do as suggested.

 

[strongm]

>Access automatically compresses the .jpg file

It does?

 

[MajP]

http://office.microsoft.com/en-us/a...the-records-in-your-database-HA001213852.aspx

Not sure if that is a rhetorical question. But jpgs are not. Some file types are compressed in attachements other are not. It is already compressed. Although not listed I think PDFs are already compressed so no additional gain, as stated.

[tt]
FILE EXTENSION	COMPRESSED?	REASON
.jpg, .jpeg	No	Already compressed
.gif	No	Already compressed
.png	No	Already compressed
.tif, .tiff	Yes	 
.exif	Yes	 
.bmp	Yes	 
.emf	Yes	 
.wmf	Yes	 
.ico	Yes	 
.zip	No	Already compressed
.cab	No	Already compressed
.docx	No	Already compressed (Metro file)
.xlsx	No	Already compressed (Metro file)
.xlsb	No	Already compressed (Metro file)
.pptx	No	Already compressed (Metro file)
[/tt]

Attachments also store data more efficiently. Earlier versions of Access used a technology called Object Linking and Embedding (OLE) to store images and documents. By default, OLE created a bitmap equivalent of the image or document. Those bitmap files could become quite large — as much as 10 times larger than the original file. When you viewed an image or a document from your database, OLE showed you the bitmap image, not the original file. By using attachments, you open documents and other non-image files in their parent programs, so from within Access, you can search and edit those files.

In addition, OLE requires programs called OLE servers to function. For example, if you store JPEG image files in an Access database, every computer that runs that database requires another program that is registered as an OLE server for JPEG images. In contrast, Office Access 2007 stores the attached files in their native formats with no supporting images, and you do not need to install additional software in order to view the images from within your database.

 

[strongm]

>Not sure if that is a rhetorical question

Rhetorical, no. Pointed, yes.