X   Site Message
(Message will auto close in 2 seconds)

Welcome to UtterAccess! Please ( Login   or   Register )

Custom Search
   Reply to this topicStart new topic
> Encryption Anomaly, Access 2010    
post May 18 2017, 09:32 AM

Posts: 48
Joined: 24-July 14

Hi, I have an anomaly that I don't know whether I should be concerned or should just ignore it.

I have a split database both front and back ends encrypted.

When I roll out changes to the system I remove the encryption from the front end, create an .accde and then re-encrypt.
The client settings on all components are set up with Default Record Locking set to 'No Locks' and Encryption Method set to 'Use Default'.

I have rolled out changes to the system 15 times in the last two years without any problems; the last time in January this year.

Yesterday I completed another roll out but when I tried to re-encrypt the front-end I received a warning message:

Encrypting with a block cipher is incompatible with row level locking. Row level locking will be ignored.

I completed the roll-out and currently have had no issues raised by the users.


1. Does this mean the system is applying page locking or will the no locks setting still prevail?
2. Why would this message be produced now and not during any of the previous roll-outs?
3. Can I safely ignore this?
4. Google and forum searches offer little advice that I can find, setting Encryption Method to 'Use Legacy' seems favourite. However I am loathe to change anything until I understand why this change has occurred.

I am in a locked down environment with no control over installations etc on my pc. Current version of Access (2010) is 14.0.7181.5000 (32 bit)

IT section have recently cleared out my user profile and I lost all my Trust Centre settings which I have reinstated.

Please advise.
Go to the top of the page
post May 18 2017, 10:17 AM

Access Wiki and Forums Moderator
Posts: 70,262
Joined: 19-June 07
From: SunnySandyEggo


I am no expert on Access security but the way I understand how encryption works in 2010 is a chunk of data (4096 bytes?) is encrypted as a block. Since more than one record could be inside the block, row-level locking is not possible because when you edit a record, Access has to decrypt the entire block.

Just my 2 cents...

Just my 2 cents... "And if I claim to be a wise man, it surely means that I don't know" - Kansas
Microsoft Access MVP | Access Website | Access Blog | Email
Go to the top of the page
post May 18 2017, 11:03 AM

UtterAccess VIP
Posts: 1,635
Joined: 25-June 04
From: Northern Virginia

A little more info on this (some of the details are lost in my gray matter, but the gist is here)
It COULD be because in 2007, the default encryption was a 40-bit cipher, streaming encryption, which WOULD support row-level locking.
However, the default in 2010 and beyond is a 128-bit block encryption which, as DBG says, has to be done block-by-block.
I THOUGHT you used to be able to specify "encrypt with weaker encryption" when you encrypted it (2010 and beyond),
which would enable the 40-bit encryption which works better for shared databases, but is less secure.


Go to the top of the page
post May 19 2017, 03:49 AM

Posts: 48
Joined: 24-July 14

Thanks for the info.
I had hoped to use an optimistic approach to record locking and not employ any.
I hadn't realised that encrypting the database would interfere with this. Encryption/password purely to prevent unauthorised access.
I gather there are two levels of encryption Legacy and Default which can be set on the Options/Client settings.
What really concerns me is why this message was produced this time around and never in the past.
I cannot think of anything I have altered within the Access environment and was wondering what factors might influence this inside or outside of Access.

Go to the top of the page
post May 19 2017, 06:51 AM

UtterAccess VIP
Posts: 1,635
Joined: 25-June 04
From: Northern Virginia

Pure speculation here, but maybe they have tweaked Access to, by default, automatically use the higher level of encryption, even if, in the past you were using the lower one.
Therefore, this time, they did the 128-bit and just warned you that it will have an impact potentially on multi-user applications.
Go to the top of the page

Custom Search
RSSSearch   Top   Lo-Fi    25th July 2017 - 01:39 AM