in Access 2003 - Trust access to Visual Basic Project greyed out how do i enable it?

I'm not positive but it may be the same setup as Excel. Here are my notes for the same option in Excel:

Excel provides an option in the registry to allow programmatic access to VBA projects. The option is set on the Trusted Publishers tab of the Security dialog (Tools->Macros->Security). The option is stored in one of two places:

   HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\X.0\Excel\Security\AccessVBOM
   HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\X.0\Excel\Security\AccessVBOM

The registry key value of the option is 0 (don't allow access) or 1 (allow access). The key in the Local Machine hive has precedence and, if present, disables the option check box. If both keys are missing then the value of the option is off (don't allow access).

Kevin

Re: Access I had no such entries in either location.
Re:Excel I had the security Entry in:
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\X.0\Excel\Security\AccessVBOM

I created the exact same entry under Access\Security\AccessVBOM with the DWord Hexadecimal 1 (just like the setting for Excel) and still am not able to check the box.
I have attahced 4 jpgs, 1 Excel Registry Security, 1 Access Registry Security, 1 Excel  Macro Security and 1) Access Macro Security
Excel-reg.JPG
Access-reg.JPG
Excel-macro-security.JPG
Access-macro-security.JPG

I've done some more research and I believe that that option is not used in Access. What you are probably looking at is a generic dialog used by all Office products and, for Access, that option is just disabled. The fact that I can't find the option at all in Access 2007 supports that theory. It makes sense when you consider that Access databases are not tossed around like Word and Excel documents. For fun I tried to figure out where Word stores that setting and I got absolutely nowhere.

So the next question is: why does your programmer need to access that setting? Is there something the programmer is trying to do that is blocked?

Kevin

I am waiting for a response from him but it is in Word 2003 as well as 2007 and Excel 2003 and 2007.
I do not see it in Access 2007

Also, the option is available in Access 2000 and he is able to check it or uncheck.  

from the programmer:
    I found the cause of the problem I am having in  Access 2003 which is 'not being able to save any code changes to Visual Basic'. I use two commands in my code ('kill' and 'shell') and have since the beginning of time. Access 2003 has labeled these commands as 'dangerous' and will not allow them unless the option box 'Trust access to Visual Basic Project' is checked. I found an alternative to 'kill' that works just fine to remove temporary files. The 'shell' command enables Access to execute applications written in VB6 such as the Bulletin and Recap reports. Here are basically the steps I need to do to check this box.

More:

I have code in my Access 2003 application that executes a VB6 application. To do this I am using the 'shell' method:
 
    stAppName = "C:\Program Files\IssueBullPreview\IssueBullPreview.exe "
    Call Shell(stAppName, 1)
    When I make any change to the Access application, even inserting a space anywhere, the 'save' command errs out and I get a message to 'send this to Microsoft'. In researching the problem, I find that Access 2003 has labeled the 'shell' technique as 'dangerous'. However I am led to believe that many programmers are using 'shell' to execute external programs with no problem.
    This technique has been an integral part of the extract process since day 1. there is no problem using the application. Everything processes just fine. I just cannot do any maintenance on it. My workaround is to download the application and do the maint on Access 2000 and then upload the database when finished.
     I 'commented out' all the shell statements (as a test) and I was able to change anything I wanted and it 'saved' just fine in Access 2003.

Send this alternative solution for Shell to your programmer:

Option Explicit

Public Const SW_SHOWNORMAL = 1
Public Const SW_SHOWMINNOACTIVE = 7

Private Declare Function ShellExecute Lib "shell32.dll" Alias _
   "ShellExecuteA" (ByVal hwnd As Long, ByVal lpOperation As String, _
   ByVal lpFile As String, ByVal lpParameters As String, ByVal _
   lpDirectory As String, ByVal nShowCmd As Long) As Long
   
Public Function LaunchApplicationHidden( _
      ByVal PathName As String _
   ) As Long
   
' Launch the requested application with it's main window hidden.
   
   LaunchApplicationHidden = ShellExecute(0&, vbNullString, PathName, vbNullString, vbNullString, SW_SHOWMINNOACTIVE)
   
End Function

Public Function OpenDocument( _
      ByVal PathName As String, _
      Optional ByVal Parameters As Variant _
   ) As Long

' Open the requested document.

   If IsMissing(Parameters) Then
      OpenDocument = ShellExecute(0&, vbNullString, PathName, vbNullString, vbNullString, SW_SHOWNORMAL)
   Else
      OpenDocument = ShellExecute(0&, vbNullString, PathName, CStr(Parameters), vbNullString, SW_SHOWNORMAL)
   End If
   
End Function

Kevin

thanks Zorvek..I am waiting to hear back from him

Thanks for the info. I haven't been able to successfully implement it to date, but will continue to investigate it. It looks like putting this code in a module instead of a form may be the key. Another factor has arisen and that has to do with 'trusted publishers'. Do we have current digital signatures for Microsoft and Symantec?
---Any idea how I find out if we have current digital signatures for MS and Symantec?

Thanks for all the help!