Results 1 to 6 of 6
  1. #1
    Join Date
    Jan 2009
    Posts
    3

    Arrow Unanswered: Removing an OLE jpg field from Access 2003 doesn't reduce file size

    I'm posting here to see if anyone has ever stepped into this same situation before. I have come to work for a company that had been embedding OLE pictures (jpgs) into their tables... well, of course, their file sizes have grown to outrageous proportions, and my immediate task is to fix the problem.
    At this point, I have extracted the images to folders and renamed them based on a field in the table. I then went back to the table they came from, and removed the field from the table. In this case the field was Picture of type OLE. But, here's what I'm finding... the Access file (mdb in this case) has not reduced in size. I'm still seeing 1.99 GB, 2.1 GB, etc. file sizes.
    The field Picture was the ONLY field in the database tables that is an OLE type embedding pictures. The rest of the fields are text & numeric. Simple stuff. Anyone know what I need to remove from the db to fully purge it of the effects of these nasty OLE fields?
    Thanks for your help!

  2. #2
    Join Date
    Nov 2004
    Location
    out on a limb
    Posts
    13,692
    Provided Answers: 59
    did you do a compact and reapir after removing the duff data
    I'd rather be riding on the Tiger 800 or the Norton

  3. #3
    Join Date
    Jan 2009
    Posts
    3

    Smile Thank You

    Thank you for such a prompt response to my question!
    I had not ran a compact & repair on the db PRIOR to removing the OLE obj field, so my comparison file sizes may now be skewed... but I did go ahead and run the compact and repair POST removing the field as per your suggestion, and it has greatly reduced the file size to where one would expect a compacted db of this size to be. Thank you again for the suggestion.
    I'm curious though, anyone have any explanation as to why Access did not properly adjust its file size prior to running the compact & repair procedure?
    Just curious...

  4. #4
    Join Date
    Nov 2004
    Location
    out on a limb
    Posts
    13,692
    Provided Answers: 59
    like many db's JET doesn't release space unless its expressly told to. you will get the db to bloat if you keep adding or changing / editing objects in the db. deleteing a row or column or object merely overwrites the the old data with nulls or soem other methods of invalidating the data. In JET terms you need to C&R to release this space.

    its to do with performance and safety. doing the comapct and repair on a live db could have serious consequences for data reliability. you should always do a compact and repair after a backup and outside normal trading hours. the server db's are a little more forgiving, and allow backups whilst active
    I'd rather be riding on the Tiger 800 or the Norton

  5. #5
    Join Date
    Apr 2004
    Location
    Sydney Australia
    Posts
    369
    It keeps everything deleted until compact. Where it keeps I don't know

    In fact the process of deleting can make the DB bigger. Try an experiment, make a copy of your DB and then in the copy delete the tables and forms and the DB will be slightly bigger.

  6. #6
    Join Date
    Jan 2009
    Posts
    3

    Thanks again

    Thanks again for the additional coments. I guess I didn't realize that's how Access handled deletes... funny... just never really ran into that scenario before.
    Thanks again!

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •