Create an unreadable encrypted data when imported to a blank database

[Tiprof]

Sorry Doc but your second paragraph is incorrect.

Signing an ACCDB file will prevent anyone changing code or creating/editing action queries from an untrusted location. Doing either of those will invalidate the certificate and prevent any code running.
Using an ACCDE file will of couse prevent anyone viewing or changing code, but it won't prevent changes to data.

Neither does code signing require all tables to be placed in the BE. There are good reasons for doing that but those aren't related to the use of a certificate.

Using disconnected ADO recordsets instead of linked tables will make it much more difficult for anyone to anyone to steal data but there is no such thing as 100% secure whether the data is in Access or e.g. SQL Server

if I may ask, what is “disconnected ADO recordsets”. And how can that help my situation?

 

[The_Doc_Man]

Colin, I didn't have the ability to use that Access feature while I was in the Navy environment. Remember I said it was a newer feature than I had available. I retired in 2016 and the linked article suggests it will be in the newest version of Access in 2022.

I had to use an external signature method for my .ACCDE files and that WOULD NOT work for cases where there was a local table in the .ACCDE file. ("Would not work" meaning "frequently invalidated".) If the new signing feature is selective to the code area, then it should work like a champ.

But the overall .ACCDE file could not be signed to any positive effect if there was a local, active table in the FE file. Passive FE tables (ones that provide translations) were not a problem. But active tables in an FE file blocked the effectiveness of the signing system we used.

Hope that clarifies my comment.

 

[isladogs]

Doc
Sorry but no it doesn't.

Code signing has been available in Access since at least Access 2003 . . . but until now ONLY for MDB/MDE files
The new feature makes it available for ACCDB/ACCDE files

Signing a project has ALWAYS required a code signing certificate purchased from a reputable organisation such as Verisign or Sectigo.
The new feature does not change that, Nor does it change how it works with FE or BE files.
It does allow code to run equally fast from untrusted and trusted locations.
It also provides additional security for developers in that any changes to code or action queries will invalidate the digital signature and block code running

So I don't understand what you are referring to when you talk about :

• an 'external signature method'
• 'the overall .ACCDE file could not be signed to any positive effect'
• 'provide translations'

I have just uploaded a YouTube video explaining how the new feature works

 

[isladogs]

if I may ask, what is “disconnected ADO recordsets”. And how can that help my situation?

My article / example app mentioned in post #5 discusses disconnected (AKA in-memory) ADO recordsets.

Encrypted Split No Strings

This example app shows how an Access database can be made reasonably secure against hackers whilst still allowing full functionality to authorised users.

www.isladogs.co.uk

Its a complicated subject and you will need to do a lot of research to understand it fully

 

[The_Doc_Man]

Colin, I'll have to chalk it up to bad luck, then, or a design that was worse than I thought it was. The code involved belonged to the Navy so I could not take it with me. Therefore I can't look at it now to figure out what went wrong and after six years can't remember enough specifics. The code method we used worked because I was careful to keep all data out of the FE files. I remember that much at least.