Microsoft Access: Zipping Data Base file -I have used Zipping on many occasions to enable Emailing of a Data Base

  • rogerbell / 204 / Wed, 24 Jun 2009 01:56:00 GMT / Comments (7)
  • I have used Zipping on many occasions to enable Emailing of a Data Base. I have noticed that a new Data Base file I have designed when zipped reduces only marginaly in size, by only a few k's. The file is approx. 8Megs.
    Can any one tell me how this can be corrected. I have used Compact & Repair prior to Zipping .Thanks for any help

  • Keywords:

    zipping, data, base, file, -i, used, occasions, enable, emailing, microsoft, access

  • http://database.itags.org/ms-access-database/207244/«« Last Thread - Next Thread »»
    1. Hi Roger,

      If you are developing with the Access 2002-2003 file format, you may want to
      convert to the Access 2000 file format, unless you have functionality that is
      only supported in the later file format.

      Try decompiling your VBA code and then perform a compact and repair. You can
      use the following *if* you only have one version of Access installed on your
      PC: Click on Start > Run, and enter the following command:

      msaccess /decompile

      The next database you open will have it's code decompiled. If you have
      multiple versions of Access, then I recommend creating a shortcut for each
      version that includes the undocumented /decompile switch. To read more about
      this option, check out Michael Kaplan's page:

      http://www.trigeminal.com/usenet/usenet004.asp?1033

      Sometimes creating a brand new database will help reduce the size. Here is
      my boilerplate advice on the subject for correcting minor corruption; the
      same technique often times reduces the file size:

      Create a brand new database and immediately disable the NameAutocorrupt
      feature (see: http://allenbrowne.com/bug-03.html for reasons why you want to
      do this). Then import all objects from the suspect database into the new
      database, one group at a time. In other words, import all tables (but not
      linked tables), then import all queries, then all forms, etc. While Access
      will allow you to import all objects in one operation, the experts at FMS,
      Inc. (a Microsoft Partner), have stated that it is best to import objects one
      group at a time (Reference:

      http://www.fmsinc.com/ubb/Forum12/HTML/000285.html).

      Recreate any linked tables from scratch. Access can cache a lot of
      information about linked tables, which may no longer be valid, so it's always
      best to recreate the linked tables from scratch. When importing local tables,
      make sure to check the option to import relationships, menus and toolbars,
      and import/export specs. If any of the local tables in the source DB are
      hidden, you'll need to first unhide them. You will need to set the checked
      references to match the source database, along with any startup options set
      under Tools > Startup. Going through this process often times solves
      corruption problems, because you get a new set of the hidden system tables
      (the tables whose names start with "MSYS"). These system tables are updated
      appropriately as you import objects.

      This may sound like a lot of work, but it really isn't. Creating a new
      container DB, disabling NameAutocorrect, importing all objects one group at a
      time, re-establishing any linked tables, setting startup options, and setting
      references to match the source DB is usually a fairly quick procedure. When
      you are in the Visual Basic Editor, in order to check that the references
      match the source DB, you should do a Debug > Compile ProjectName as well.

      If none of the above helps, then your database is likely about as small as
      it will be with the current set of objects and data.

      Tom Wickerath
      Microsoft Access MVP

      http://www.access.qbuilt.com/html/expert_contributors.html
      http://www.access.qbuilt.com/html/search.html
      __________________________________________

      "Roger Bell" wrote:

      > I have used Zipping on many occasions to enable Emailing of a Data Base. I
      > have noticed that a new Data Base file I have designed when zipped reduces
      > only marginaly in size, by only a few k's. The file is approx. 8Megs.
      > Can any one tell me how this can be corrected. I have used Compact & Repair
      > prior to Zipping
      > Thanks for any help
      >

      tomwickerath | Wed, 04 Jun 2008 01:05:00 GMT |

    2. Thanks for that Tom.
      Useing Access 2003. Tried what you suggested, but made no difference.
      Have since used "Tools-Security-Encode/Decode Data Base" which alllowed the
      zipping correctly. Will there be any implications to the Data Base as a
      result of using this feature? Naturally, I have the original copy prior to
      Encoding/Decoding
      Many Thanks

      "Tom Wickerath" wrote:
      [vbcol=seagreen]
      > Hi Roger,
      > If you are developing with the Access 2002-2003 file format, you may want to
      > convert to the Access 2000 file format, unless you have functionality that is
      > only supported in the later file format.
      > Try decompiling your VBA code and then perform a compact and repair. You can
      > use the following *if* you only have one version of Access installed on your
      > PC: Click on Start > Run, and enter the following command:
      > msaccess /decompile
      > The next database you open will have it's code decompiled. If you have
      > multiple versions of Access, then I recommend creating a shortcut for each
      > version that includes the undocumented /decompile switch. To read more about
      > this option, check out Michael Kaplan's page:
      > http://www.trigeminal.com/usenet/usenet004.asp?1033
      >
      > Sometimes creating a brand new database will help reduce the size. Here is
      > my boilerplate advice on the subject for correcting minor corruption; the
      > same technique often times reduces the file size:
      > Create a brand new database and immediately disable the NameAutocorrupt
      > feature (see: http://allenbrowne.com/bug-03.html for reasons why you want to
      > do this). Then import all objects from the suspect database into the new
      > database, one group at a time. In other words, import all tables (but not
      > linked tables), then import all queries, then all forms, etc. While Access
      > will allow you to import all objects in one operation, the experts at FMS,
      > Inc. (a Microsoft Partner), have stated that it is best to import objects one
      > group at a time (Reference:
      > http://www.fmsinc.com/ubb/Forum12/HTML/000285.html).
      > Recreate any linked tables from scratch. Access can cache a lot of
      > information about linked tables, which may no longer be valid, so it's always
      > best to recreate the linked tables from scratch. When importing local tables,
      > make sure to check the option to import relationships, menus and toolbars,
      > and import/export specs. If any of the local tables in the source DB are
      > hidden, you'll need to first unhide them. You will need to set the checked
      > references to match the source database, along with any startup options set
      > under Tools > Startup. Going through this process often times solves
      > corruption problems, because you get a new set of the hidden system tables
      > (the tables whose names start with "MSYS"). These system tables are updated
      > appropriately as you import objects.
      > This may sound like a lot of work, but it really isn't. Creating a new
      > container DB, disabling NameAutocorrect, importing all objects one group at a
      > time, re-establishing any linked tables, setting startup options, and setting
      > references to match the source DB is usually a fairly quick procedure. When
      > you are in the Visual Basic Editor, in order to check that the references
      > match the source DB, you should do a Debug > Compile ProjectName as well.
      > If none of the above helps, then your database is likely about as small as
      > it will be with the current set of objects and data.
      >
      > Tom Wickerath
      > Microsoft Access MVP
      > http://www.access.qbuilt.com/html/expert_contributors.html
      > http://www.access.qbuilt.com/html/search.html
      > __________________________________________
      > "Roger Bell" wrote:

      rogerbell | Wed, 04 Jun 2008 01:06:00 GMT |

    3. Hi Roger,

      > Have since used "Tools-Security-Encode/Decode Data Base"...


      Did you mean Tools > Security > Encrypt/Decrypt Database...?

      If so, and if you had previously encrypted your database, then I'm not sure
      if a zipping utility could compress that. If you then decrypted it, WinZip,
      or any other similar utility certainly should be able to pack that file, at
      least to some extent.

      Encryption helps to prevent snooping eyes from attempting to look at data by
      opening the .mdb file with a hex (or text) editor. There is a slight
      performance hit for encrypting your data, because this encrypt/decrypt
      process must go on constantly in the background.

      Tom Wickerath
      Microsoft Access MVP

      http://www.access.qbuilt.com/html/expert_contributors.html
      http://www.access.qbuilt.com/html/search.html
      __________________________________________

      "Roger Bell" wrote:

      > Thanks for that Tom.
      > Useing Access 2003. Tried what you suggested, but made no difference.
      > Have since used "Tools-Security-Encode/Decode Data Base" which alllowed the
      > zipping correctly. Will there be any implications to the Data Base as a
      > result of using this feature? Naturally, I have the original copy prior to
      > Encoding/Decoding
      > Many Thanks

      tomwickerath | Wed, 04 Jun 2008 01:07:00 GMT |

    4. Thanks again Tom
      The version I am using is Access 2003, part of Office Professional and under
      the Tools Menu-Security, the last option is "Encode/Decode Data Base".
      I am not sure what this actually does and would be grateful for any
      enlightenment.
      There is not an option here for Encrypt/Decrypt. Perhaps they mean the same
      thing!
      Thanks again

      "Tom Wickerath" wrote:
      [vbcol=seagreen]
      > Hi Roger,
      >
      > Did you mean Tools > Security > Encrypt/Decrypt Database...?
      > If so, and if you had previously encrypted your database, then I'm not sure
      > if a zipping utility could compress that. If you then decrypted it, WinZip,
      > or any other similar utility certainly should be able to pack that file, at
      > least to some extent.
      > Encryption helps to prevent snooping eyes from attempting to look at data by
      > opening the .mdb file with a hex (or text) editor. There is a slight
      > performance hit for encrypting your data, because this encrypt/decrypt
      > process must go on constantly in the background.
      >
      > Tom Wickerath
      > Microsoft Access MVP
      > http://www.access.qbuilt.com/html/expert_contributors.html
      > http://www.access.qbuilt.com/html/search.html
      > __________________________________________
      > "Roger Bell" wrote:

      rogerbell | Wed, 04 Jun 2008 01:08:00 GMT |

    5. Hi Roger,

      Arrrggghhh (as Charlie Brown would scream, as Lucy jerks the football away).
      I now see the "Encode/Decode Data Base" option that you mention. I had
      Access 2002 open previously. I guess someone at Microsoft felt there was
      value to changing the terminology between versions. Yes, Encode/Decode and
      Encrypt/Decrypt mean the same thing.

      Tom Wickerath
      Microsoft Access MVP

      http://www.access.qbuilt.com/html/expert_contributors.html
      http://www.access.qbuilt.com/html/search.html
      __________________________________________

      "Roger Bell" wrote:

      > Thanks again Tom
      > The version I am using is Access 2003, part of Office Professional and under
      > the Tools Menu-Security, the last option is "Encode/Decode Data Base".
      > I am not sure what this actually does and would be grateful for any
      > enlightenment.
      > There is not an option here for Encrypt/Decrypt. Perhaps they mean the same
      > thing!
      > Thanks again

      tomwickerath | Wed, 04 Jun 2008 01:09:00 GMT |

    6. PS. As an experiment, try making two throw-away copies of your database.
      Encrypt, er encode, one of them. Then open them using WordPad, and arrange in
      a side-by-side view. You will see that in the original (unencrypted) version,
      that there are certain data values that you can read, simply by scanning the
      file. You won't be able to read the same area of the encrypted file.

      Tom Wickerath
      Microsoft Access MVP

      http://www.access.qbuilt.com/html/expert_contributors.html
      http://www.access.qbuilt.com/html/search.html
      __________________________________________

      "Tom Wickerath" wrote:
      [vbcol=seagreen]
      > Hi Roger,
      > Arrrggghhh (as Charlie Brown would scream, as Lucy jerks the football away).
      > I now see the "Encode/Decode Data Base" option that you mention. I had
      > Access 2002 open previously. I guess someone at Microsoft felt there was
      > value to changing the terminology between versions. Yes, Encode/Decode and
      > Encrypt/Decrypt mean the same thing.
      >
      > Tom Wickerath
      > Microsoft Access MVP
      > http://www.access.qbuilt.com/html/expert_contributors.html
      > http://www.access.qbuilt.com/html/search.html
      > __________________________________________
      > "Roger Bell" wrote:

      tomwickerath | Wed, 04 Jun 2008 01:10:00 GMT |

    7. Because you are encrypting the database, you will only get a minor amount of
      compression when zipping. Zip programs rely on patterns to delete characters
      to compress the file. Encrypting a database destroys any discernable
      patterns.

      You might try using WinZip 9.0 or later which can encrypt the file after
      zipping, instead of before. Winzip uses AES encryption (both 128 and 256
      bit) which is virtually uncrackable.
      Arvin Meyer, MCP, MVP
      http://www.datastrat.com
      http://www.mvps.org/access
      http://www.accessmvp.com

      "Roger Bell" <RogerBell...discussions.microsoft.com> wrote in message
      news:C48751E4-E258-42EB-B36B-3BBFF2339BB5...microsoft.com...
      >I have used Zipping on many occasions to enable Emailing of a Data Base. I
      > have noticed that a new Data Base file I have designed when zipped reduces
      > only marginaly in size, by only a few k's. The file is approx. 8Megs.
      > Can any one tell me how this can be corrected. I have used Compact &
      > Repair
      > prior to Zipping
      > Thanks for any help
      >


      arvinmeyermvp | Wed, 04 Jun 2008 01:11:00 GMT |