IN THE SPOTLIGHT: MDE to MDB Conversion Service
(also supports: ACCDE to ACCDB, ADE to ADP, etc)
IN THE SPOTLIGHT: vbWatchdog
VBA error handling just got easier...
" vbWatchdog is off the chart. It solves a long standing problem of how to consolidate error handling into one global location and avoid repetitious code within applications. "
- Joe Anderson,
Microsoft Access MVP
Meet Shady, the vbWatchdog mascot watching over your VBA code →
(courtesy of Crystal Long, Microsoft Access MVP)
IN THE SPOTLIGHT: vbMAPI
An Outlook / MAPI code library for VBA, .NET and C# projects
Get emails out to your customers reliably, and without hassle, every single time.
Use vbMAPI alongside Microsoft Outlook to add professional emailing capabilities to your projects.
By default, this is completely true – but the clue is in the previous article:
“If Access was to read and write to the file in full 4096 byte pages, then we could theoretically use any block cipher encryption such as the much stronger AES algorithm. Unfortunately this is not the case, by default. When Record-level locking is switched on, Access writes to each record individually. In other words, when you change values in a record within a table, the whole 4096 byte page is not re-written to disk – only the single record data is written out.”
If we completely disable Record-level locking, this forces Access to write to the file in full 4096 byte pages, which in turn is then compatible with any block encryption algorithm.
A further problem is that if you don’t turn off Record-level locking when opening a file encrypted with a block cipher, then when you open the file, Access starts writing to the database and turns it into toast. So we have to be extra careful…
To work around this issue, we decided to make Access require a COM Add-in that serves two purposes.
1. To ensure record-level locking is always OFF when opening a file encrypted in this manner
2. To ensure that Access without the COM Add-in can’t even open the file (to prevent corrupting the file). In this case, Access will just keep returning ‘Incorrect password’
The Encryption Manager from Part 1 (free):
The Access COM Add-in EncryptionEnchancer (free):
PLEASE NOTE: THE SOLUTION BEING DISCUSSED IS NO LONGER BEING MADE AVAILABLE.
THIS ARTICLE WILL REMAIN AVAILABLE FOR A LITTLE WHILE FOR THOSE THAT HAVE ALREADY DOWNLOADED THE ASSOCIATED FILES.
As mentioned in Part 1, the Encryption Manager can be used to change the encryption provider / algorithm / key length used to encrypt any Access database file. You need Option 1 in the Encryption Manager for this.
Once your file is loaded into the Encryption Manager you will see what encryption your file is currently encoded with (probably RC4-40). Next, to see all the block-ciphers (that require our COM Add-in) you should click the ‘EnhancedEncryption Mode’ option:
You can now select, for example, the Microsoft Enhanced RSA and AES Cryptographic Provider with the AES 256 algorithm – this is considerably stronger than RC4-128 encryption. You can also change the hashing algorithm used if you wanted (which can be upped to SHA-256 or more on Vista machines). It would be advisable to choose a hashing algorithm with the same size as the encryption key size you've chosen (or greater).
Once you’ve picked your block cipher, click the ‘Re-encrypt file with these settings’ button at the bottom right of the screen and follow the instructions given to finish the process.
Now, when you first try to open the file in Access 2007, you will find that it won’t accept your password. That’s because you need to install the Add-in.
For installing, copy the file named ‘EverythingAccess_EncryptionEnhancer.dll’ to your Windows\System32 folder.
Next, open the Install.reg file that is also contained in the ZIP file. An Uninstall.reg file is also provided if you decide to remove the COM Add-in later.
Once you’ve received this message, the Add-in is now installed and will be running when you next open Access.
To confirm installation went OK, open Access and try to open your AES-256 encrypted file. You should now find that the file opens as expected.
Files encrypted with block ciphers in this way currently cause the Compact and Repair routine to fail. For now you should ‘Decode’ the file, compact and repair and then re-apply the encryption.
Have your say - comment on this article.
What did you think of 'Changing the encryption type in Access Part 2'?
|David W. Fenton says...|
07 March 2010
Is it possible to have an explanation of why the supplementary files were withdrawn?
|Wayne Phillips says...|
07 March 2010
The file was withdrawn due to some users experiencing issues on 64 bit machines. It was deemed that the DLL was not fully WOW64 compatible, and given the popularity of Windows 7 x64 of late, this was now becoming quite an issue.
We haven't completely given up on this project but first we plan on evaluating the Access 2010 Release Candidate in the coming weeks to determine the exact changes that have been made to the encryption model (apparently there are some improvements) before deciding whether to proceed with upgrading the DLL, or to abandon it.
17 March 2010
Good news. Access 2010 does exactly what the EncryptionEnhancer DLL did for A2007.
If you enable the newer encryption on your file in Access 2010, the engine then enforces page-level locking (so record level locking is no longer allowed). This then allows any block encryption algorithm to be used - exactly the same as what my EncryptionEnhancer DLL did.
Pretty cool. I wonder where the Access team got the idea from? :)
Anyway, that pretty much makes my DLL redundant for newer versions, so I don't feel that there's a need for me to fix the A2007 version for WOW64 support.
Have your say...