none
PtrSafe error RRS feed

  • Question

  • We installed new PC's with windows 10 Pro and then downloaded Office 2016 Pro desktop software and installed. We already had 1 Win 10 PC with Office 2016 Pro and all was fine with our Access db. When we opened the application we have been using for years on the new PC it went into code display and gave "Compile error: The code in this project must be updated for use on 64-bit systems. Please review and update Declare statements and then mark them with the PtrSafe attribute."

    Is there an easy way to eliminate this error?  It would make sense if all Windows 10 PC's gave the error but only the new ones are giving the error.  How can I fix this?

    Tuesday, September 24, 2019 8:51 PM

Answers


  • Is there an easy way to eliminate this error?  It would make sense if all Windows 10 PC's gave the error but only the new ones are giving the error.  How can I fix this?

    Assuming that the database is split into front and back ends, with a copy of the front end installed on each machine, which is the recommended set-up in a multi-user environment, then it is usually not difficult to update the copies of the front end installed on the machines using 64 bit Access.  In the VBA editor undertake a global  find and replace, replacing 'Declare Function' with 'Declare PtrSafe Function'.

    Ken Sheridan, Stafford, England

    • Marked as answer by David Chase89 Wednesday, September 25, 2019 2:28 PM
    Tuesday, September 24, 2019 10:51 PM

All replies

  • If you've "been using for years" then it was most probably a 32-bit version of Office/Access and by default Office 2016/2019 install the 64-bit version.

    So, first check both PCs and check the bitness of Office, if it is as I suspect, uninstall the 64-bit version and then reinstall the 32-bit version and everything should fall back into place.

    The other option would be to use Conditional Compilation Directives to make your database compliant with both 32 and 64-bit.  This also assumes you aren't distributing compiled version in which case things get more complicated.  The following may be informative on the subject http://www.devhut.net/2017/04/13/access-x32-vs-x64-compatibility/


    Daniel Pineault, 2010-2019 Microsoft MVP
    Professional Support: http://www.cardaconsultants.com
    MS Access Tips and Code Samples: http://www.devhut.net



    Tuesday, September 24, 2019 8:59 PM
  • We did not get an option for 32-bit when it was downloaded and installed. Is there an option to go back to 32-bit?
    Tuesday, September 24, 2019 9:25 PM

  • Is there an easy way to eliminate this error?  It would make sense if all Windows 10 PC's gave the error but only the new ones are giving the error.  How can I fix this?

    Assuming that the database is split into front and back ends, with a copy of the front end installed on each machine, which is the recommended set-up in a multi-user environment, then it is usually not difficult to update the copies of the front end installed on the machines using 64 bit Access.  In the VBA editor undertake a global  find and replace, replacing 'Declare Function' with 'Declare PtrSafe Function'.

    Ken Sheridan, Stafford, England

    • Marked as answer by David Chase89 Wednesday, September 25, 2019 2:28 PM
    Tuesday, September 24, 2019 10:51 PM
  • Ken can you elaborate on 'Declare PtrSafe Function': when/why this is needed...    This is new to me.  thanks in advance for your time.....
    Friday, September 27, 2019 2:55 PM
  • Ken can you elaborate on 'Declare PtrSafe Function': when/why this is needed...    This is new to me.  thanks in advance for your time.....

    Until recently the vast majority of people used 32 bit Office applications.  Now, however, Office 365 by default installs the 64 bit version.  If an Access database includes calls to the Widows API (Application Programming Interface) anyone previously using 32 bit Access will find that such Windows API function calls will no longer work in 64 bit Access.  Previously the declaration of such functions began with Declare Function.  To enable them to work in 64 bit Access in most cases merely requires this to be changed to Declare PtrSafe Function.

    Consequently to update an Access file which includes Windows API function will merely require a simple global 'find and replace' in the VBA editor

    If a database which calls a Windows API function is to be used in both 32 bit and 64 bit Access then conditional compilation can be used, e.g. when declaring the ShellExecute function to open or print a file:

    #If VBA7 Then
        Declare PtrSafe 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 nshowcm As Long)
    #Else
        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 nshowcm As Long)
    #End If

    Note, however, that when installing Office 365 it is still possible to opt for the 32 version.

    PS:  I thought I'd try adding the PtrSafe keyword to the above function declaration in 32 bit Access to see what happened.  I found that it compiled quite happily, so there is in fact no need for conditional compilation.


    Ken Sheridan, Stafford, England


    Friday, September 27, 2019 3:50 PM
  • In your view what would be the most common examples of an application feature that calls to the Windows API (Application Programming Interface) ?  I realize this is a subjective question. 

    Applications are being put onto O365 by the user base typically without the developer's awareness. One assumes many common Access applications' features such as PDF creation, links to Outlook, or send Emails out of an Access application don't involve the Windows API.  

    This initial post above doesn't state what user feature set is that causes the error, only that there is an error...so I'm wonder, as a rule of thumb, what common user feature(s) - in the non technical sense - we might want to keep an eye out for that would most probably run into this issue.  My guess is maybe Web calls, though I've never been asked to do those - would be interested in your thoughts.  again TIA.

    Friday, September 27, 2019 10:29 PM
  • PS:  I thought I'd try adding the PtrSafe keyword to the above function declaration in 32 bit Access to see what happened.  I found that it compiled quite happily, so there is in fact no need for conditional compilation.

    Hi Ken,

    This does not yet hold for A2003 (and other old versions?), as expected though.

    Imb.

    Saturday, September 28, 2019 6:20 AM
  • This does not yet hold for A2003 (and other old versions?), as expected though.
    In that case conditional compilation would be the appropriate solution.  I can only speak for Office 365, of which we have 32 and 64 bit versions installed on different machines.

    Ken Sheridan, Stafford, England

    Saturday, September 28, 2019 12:08 PM
  • In your view what would be the most common examples of an application feature that calls to the Windows API (Application Programming Interface) ?


    I can only go by my own experience.  The two I still frequently use are the GetUserName and ShellExecute functions.  The former gets the Windows user name of the currently logged in user, and is safer than the commonly used Environ function.  The latter opens a file, and also enables a suitable file to be printed directly, whereas the commonly used FollowHyperlink method only opens a file.

    In the past I used the GetOpenFileName function extensively via Bill Wilson's freely distributed BrowseForFileClass class module (amended slightly by me).  This opened the file dialogue, but in Access has been superseded by the much simpler FileDialog property of the Application object.  It is still quite likely to be found in use in older Access files.


    Ken Sheridan, Stafford, England

    Saturday, September 28, 2019 12:38 PM