i just do not see how you can achieve this, if you only have run time. If you have a FULL version of Access, and just want to simulate a run-time environment, then that's different - but if code in a database can run stuff undetected, it would surely undermine everything that MS was trying to do. So I just do not think that you can avoid the messages from a wholly runtime version of access.
I did not realize that you only have runtime available to you. I agree with Dave that you can't do this only in Runtime. Maybe it is possible but ultimately if you are making any changes at all to the front end you need the full version of access.
OMG ... I had a look again at my own link and there they already have code for Office 2016 I must be soooooooooo behind, just recently having switched to 2010!
It was a big step backwards when Microsoft deprecated the ability to Digitally Sign the code in Access 2007.
With a digital signature, the database can be run from anywhere without any risk. Group Policies can be used to distribute the signature and the user never sees a warning. You can also prevent the user choosing to run unsigned code.
It is the main reason I still distribute mde files instead of accde even though I design in A2010. And the fact that there is nothing added in the new format of any real consequence.
I am using the following command line to open access and run a query (via Autoexec). Everything is working really well, except for the fact that I get prompted with a Security question regarding the Macro.
What switch can I add that will make this question disappear. The reason is that this query will run unattended throughout the day.
"C:\Program Files (x86)\Microsoft Office\Office15\msaccess.exe" /runtime "\\parsbs2011\pardb\PAR RFID DB.accdb"
I wanted to suggest that all of the solutions here are incorrect. I believe what happened is that the installation of Access runtime on a PC with Office already installed has changed the registry entries.
My fix was simply to run the Office 2016 repair tool in the control panel.
it is not my area of expertise, but the LocationX is just a name, you can call it what you like. Since Location2 is already created, trying to add it again will create an error
In case its of any use to you, I've exported the registry entries for trusted locations with Access 14.0 on my PC.
If you look at this list, it shows a list of all folders where any databases are trusted.
What you will also notice is there is no entry for the location of the Access runtime itself.
That's not relevant here - AFAIK that's true even if using the runtime version
I've attached this as a registry file (.reg) - zipped so I could upload it here.
Open it in Notepad to edit it for your own purposes
Some comments on the above:
1. Add an entry for each trusted folder. The location number doesn't matter as long as its unique
2. Modify the path as required for your setup - notice the double backslashes
3. If you want to trust subfolders, use dword:00000001
If not, use dword:00000000
4. Add a user friendly description (optional) and modify the date if you wish.
When I'm deploying databases to clients I create registry scripts similar to the above but with additional entries for Office 12/15/16 (2007/2013/2016)