Inserting Images in Access

[sheusz]

Hi all,

After finally resolving some corruption issues in one of my databases (thanks again Ramou and AceMan) I have a general question or three. I have a table where one of the fields is an OLEObject datafield that stores a CAD drawing image.

When the table was first developed it was envisaged that this would be a good way for users to be able to click on a button on a form and have the user see a picture of the component. It worked OK for a while but then I think that is what may have caused the corruption in the table.

My question/s is/are

1. Is this a likely cause for the corruption?
2. Is an OLE Object a desirable item in a table?
3. What is the best way to store an image in a table bearing in mind that the table needs to be transortable, so references to files locations need to be avoided, but still not blowing out the database size?

Any comments gratefully received.

 

[Remou]

Unless you have Access 2007, you should either store only the path or a BLOB.

http://support.microsoft.com/kb/148463

http://support.microsoft.com/kb/103257

 

[TheAceMan1]

How are ya sheusz . . .

To answer your questions:

[blue]Is this a likely cause for the corruption?[/blue]

If the header of a graphics file is corrupted, its possible (access can't tell what type of file it is to know how to filter and display). How you resolved your corruption issue will support this or not. However I believe it to be unlikely a graphics file is at fault, more so the size of the db since your using OLE.

[blue]Is an OLE Object a desirable item in a table?[/blue]

Pretaining to graphics, [blue]NO![/blue] As you've already found out, the Db blows up in size in a big way. However be aware: [blue]using OLE is a forced issue when it comes to Continuous Forms![/blue] Single Forms can receive their files thru a standard text field, loaded with the path to the graphic.

[blue]What is the best way to store an image in a table bearing in mind that the table needs to be transortable, so references to files locations need to be avoided, [purple]but still not blowing out the database size?[/purple][/blue]

You ask what would be desirable for all of us. For portability you need OLE, but as you've already experienced, Db size very soon becomes an issue! All service providers dictate a maximum size attachment you can send. I'm sure you've already exceeded yours! [blue]Remou[/blue] has already stated the easiest way to circumvent this, but it goes against portability. However its the best way to go! I've actually had to force a Child Care organization that has offices across the United States, to use [blue]Instant Messaging[/blue] to directly download graphics to a field in a table that stores paths. Reason: I do not have the time to find out and correct what a Db blown file size, will or will not do. I've been thru this headache once, and will see to it, it never happens again! I'm sure I got some gray hairs from it! Man O Man . . . it was a total mind job . . . let alone my reputation was at stake!

So, in summation, you have a decision to make. Go with [blue]Remou's[/blue] suggestion, or prepare yourself to deal with an overblown Db thru OLE!

BTW: I found that users enjoyed downloading the graphics. Made them feel very smart! There comes a time, in enough applications, [blue]where the user truly has to do something![/blue]

[blue]Your Thoughts? . . .[/blue]

See Ya! . . . . . .

Be sure to see thread181-473997
Also faq181-2886

 

[sheusz]

Hi AceMan and Remou,

I've decided to go with Remou's suggestion and make the users use their brains a bit like AceMan points out. BTW since fixing the corruption I've been able to compact the database from 87Mb to 3.5Mb!

Thanks again for your advice and comments.