Why does database size grows too quickly when linking to jpgs? 2

[brettatexplace]

I have a one field table that is an OLE object and links to (not embeded) a jpg picture (about 36K) but when I look at the size of the database, it growes over 1 Meg for each picture I add. Is this normal, and what's using up the other 970K of space?

I need to add about a thousand pictures but don't want to use up a gig of space when I know the directory of photos is only 36 Meg.

Thanks.

 

[wilyba]

Make sure you that you embedded it correctly. Could be because you have it unbound or vice versa.

 

[Isadore]

I'm not sure what the ultimate argument for images is. Seems it would be better to store the images in a folder and only have the path names in the dbase tables, then, when you want to view the pic, just sent the Image.Picture = "Path..."

Alternatively, what about storing jpeg directly in an OLE field in the table? What are the arguments for storing a jpeg directly in a table versus storing only the file path.

I've seen a "growth" problem before but it realted to bitmaps, and large jpegs..never seen a 37K do anything like you described. I too am getting ready to bring in several hundred jpegs and not sure if I want to "stuff" then in an OLE field in a table, or just keep the file paths in the table.

Any experts on this?

 

[watever]

hi all, me facing the same problem here. if i insert the jpg as link then it'll only show a package icon instead of the real picture. so i wander if "when you want to view the pic, just sent the Image.Picture = "Path..."", can i make the picture viewable in access form in this way?

i even tried to insert the jpg file as embeded object, same thing happen a 40kb+ file grow to 1.5MB. now what i do is making the pictured as embeded, cause that's the only way i know how to show the picture in a form. dun wanna end up having a more than few hundred MB size of database application.

 

[DougP]

What you need to do is leave the images on the hard drive and just link to them. I pefer to use the Image control.
On your form in the On_Current event add this code

'load Image
Me!Image11.Picture = Application.CurrentProject.Path & "\Photos\" & Me![ID] & ".jpg"

Now the images are easiset to load if they are named the unique Id's number.
So your image name is something like 288288.jpg which is the ID number of the record.



DougP, MCP

 

[watever]

"Hi there,
I ended up contacting Microsoft technical support who said that it is a timing error within Windows 95, and the only way round it was to move slowly from screen to screen. Not a very satisfactory solution, next to useless in fact. I'm using the DBPIX control from

http://www.ammara.com

instead and it works fine.

All the best
Fiona"

quote from Fiona msg, learning how to use this DBPIX now, think it's cool

 

[welshone]

Doug, excellent tip.

 

[Francescina]

The image control is the much better solution, if you use the Graphics for Access (

http://www.unsoftwareag.com)

wizard then you can even store your jpgs inside the tables without bloating your MDBs!

 

[JimHorton]

bretta,
In my opinion, Isadore's solution would be preferable, since the DougP solution requires a hardcoded path, and the jpegs are then forced to be on one machine, one path (and CurrentProject is not a method of the Application Object, least not in Access 97).

With image paths stored in a central db, the CommonDialog ocx can be utilized to quickly load paths of many jpegs in one shot, not needing to worry about naming a jpeg with a cryptic 'ID', and the paths can be all over the network. When paths need to change or files are moved, using FileSystem or commondialog you can update those paths in the db.
--Jim