Saturday, April 03, 2010

Access: Runtime version and Trusted Locations

So I was working on this project and bumped into the following situation. Client needed a Runtime version of an Access app. No problem we downloaded the Developer Extensions (which can be found here: http://www.microsoft.com/downloads/details.aspx?FamilyId=D96A8358-ECE4-4BEE-A844-F81856DCEB67&displaylang=en ) and installed that. After that we downloaded the Access Runtime engine (which can be found here: http://www.microsoft.com/downloads/details.aspx?familyid=D9AE78D9-9DC6-4B38-9FA6-2C745A175AED&displaylang=en ) and went ahead and packaged the accdb. This all went fine.

Installation on the client pc
After installation on the client pc we bumped into some various issues which i think can be important to know for when you are confronted with this situation. The installation on the client pc using the setup from the packaged file went fine. We started the app and the very first message we saw was a security message. This message isn't al together clear but after investigation it a bit further i knew this had something to do with the trusted location settings. Ofcourse... during development we had set the trusted location to point x and that gave no issues. But when distributing you will run into this issue because you can't set anything anymore once you've created a runtime. So how to go about this situation. We thought of a couple of options we could do:

  • Add the trusted location to the original accdb settings when packaging... no that would not make a difference because it's a user based situation. Besides we wouldn't know where the installation would take place;
  • Try to figure out how access treats Trusted locations and try to modify those settings.
Registry settings (be careful!!)
We chose the latter one and took the plunge into the registry. Now remember that messing with the registry can mess up your computer, so unless you know what you are doing leave it alone and let someone who knows what he's doing help you with making the necessary adjustments.

Every trusted location you add to the Trusted Locations in the Trustcenter Settings from within Access is written to the registry. When adding the runtime engine to a certain client pc a set of keys will be created. By adjusting those settings you can set a specific path as an additional trusted location.

Keys
These are the keys you have to add to the trusted locations. As stated earlier, if you are not familiar with the registry don't touch it and ask for help from someone who knows this stuff!

The Key you have to add is the following:
[HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Access\Security\Trusted Locations\Location1
AllowSubFolders (REG_DWORD) = 1
Path (REG_SZ) "c:\thepathtoyourdatabasefolder"

Explanation
The first line you see is the treestructure you have to follow to get to the designated registry key
The second line is the key you have to add to the settings the 1 indicates that the subfolders should be also allowed as trusted.
The third line is the line where you add the path (don't forget the double quotes here..) to the trusted location to be added. This example set's it to c:\blablabla but this can be antoher driveletter altogether..

Now every loaction added from within Access will create an addition location number. It might be that you alreade have Location1, Location2 etc. In that case you have to add another Location(x) to make sure you don't alter anything existing

Next step
After adding the registry key we started the application again and the security warning disappeared. Yep this worked. Next we were confronted with an additional warning - error 2950. As usual this can mean a lot. In our specific case we are trying to run code when the app starts (initialize routine which checks the linked tables). At that point we were presented with the dialog that all macro's are halted and there you are knowing not wat to do. What causes this.

Diving into the registry again. Setting the sandbox option to something different? That's one of the suggestion we could do but in my opinion that wouldn't make a change here because i didn't want to work in sandbox mode.

Finding the solution to this problem
I didn't find a solution yest for this problem but we are working on it. I'm going to eliminate the variables to see what might cause this issue. Meanwhile i've posted a question on the Technet Access forum (which you can find here: http://social.technet.microsoft.com/Forums/en-US/access/threads ) so other developers can think with me on this one. I'll keep you posted on this one.

Conclusion...
In the early days the enable macro options was one of the features you had to worry about. Now you have a lot of other issues you have to consider when distributing the app. Keeps you sharp ;-)

3 comments:

  1. I would like to know what genius sells a product that requires the user to dig into the regestry just to get it to launch?

    ReplyDelete
  2. Anonymous3:49 PM

    Excellent workaround. Kudos!!

    ReplyDelete
  3. I figured out that you can just use a self- singed certificate (digital certificate for VBA tool) and you're home free.

    ReplyDelete