Upgrading VBA to 64bits, What does it means?

Moore71

DEVELOPER
Local time
Today, 04:29
Joined
Jul 14, 2012
Messages
158
Hi please how can I resolve this issue?
"Compiler 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.
--------------------------------------------------------------------------------------------------
This is my original code that is generating this error:

'Revised Type Declare for compatability with NT
Type tagOPENFILENAME
lStructSize As Long
hwndOwner As Long
hInstance As Long
lpstrFilter As String
lpstrCustomFilter As Long
nMaxCustFilter As Long
nFilterIndex As Long
lpstrFile As String
nMaxFile As Long
lpstrFileTitle As String
nMaxFileTitle As Long
lpstrInitialDir As String
lpstrTitle As String
Flags As Long
nFileOffset As Integer
nFileExtension As Integer
lpstrDefExt As String
lCustData As Long
lpfnHook As Long
lpTemplateName As Long
End Type

Private Declare Function GetOpenFileName Lib "comdlg32.dll" _
Alias "GetOpenFileNameA" (OPENFILENAME As tagOPENFILENAME) As Long

Private Sub HandleError(strLoc As String, strError As String, intError As Integer)
MsgBox strLoc & ": " & strError & " (" & intError & ")", 16, "CheckTableLinks"

End Sub

Private Function TableLinkOkay(strTableName As String) As Boolean
'Function accepts a table name and tests first to determine if linked
'table, then tests link by performing refresh link.
'Error causes TableLinkOkay = False, else TableLinkOkay = True
Dim CurDB As DAO.Database
Dim tdf As TableDef
Dim strFieldName As String
On Error GoTo TableLinkOkayError
Set CurDB = DBEngine.Workspaces(0).Databases(0)
Set tdf = CurDB.TableDefs(strTableName)
TableLinkOkay = True
If tdf.Connect <> "" Then
strFieldName = tdf.Fields(0).Name 'Do not test if nonlinked table
End If
TableLinkOkay = True
TableLinkOkayExit:
Exit Function
TableLinkOkayError:
TableLinkOkay = False
GoTo TableLinkOkayExit

End Function
 
Hi,

Your code is for use in a 32-bit system. If you need to run it in a 64-bit system, you’ll need to update it to a proper syntax for 64-bit systems. I’ll see if I can find a link for you.

Sent from phone...
 
There you go. I found the same ones.

Cheers!
 
Moore71 - you have the links that tell you what to do. Here is WHY you need to do it.

Access was originally developed in something called a "32-bit memory model" which governs how addresses are managed. For a long time, a 32-bit LONGWORD was the longest addressing entity possible due to hardware limitations. These limitations also limited the size of the computer RAM that you could use. The 32-bit address range is 4 GB so it should be no surprise that PCs from the Win XP era were limited to 4 GB of RAM.

As time passed, hardware stepped to the next logical limit, a "64-bit memory model" which allowed for longer addresses - which is how Windows computers gained the ability to have more than 4 Gigabytes of RAM. With the advent of longer physical memory addresses, the 8 GB machine became possible. I have seen servers with 192 GB of RAM.

Microsoft provided a special environment in which you can still be limited to 32 bits for addresses and the environment compensates for this by putting you in a 32-bit "shell" that manages your memory for you. In that environment, your programs "think" they are still in the 32-bit world but in fact they are in a bubble.

For Access it is not significant because internal stuff didn't change much, but for Excel and a few other utilities, breaking out of the bubble also breaks past limitations on programs. A 64-bit version of Excel can have worksheets with literally a million rows whereas the 32-bit version is more limited. If you want to use Excel with the large file options, you need to switch to 64-bit Office.

In order to enter this environment, you have to modify your VBA code so that it knows how to handle the double-sized addresses. The message that you got informs you that your code had not been adjusted properly for the new address size. That "PtrSafe" is about "Pointer Safe" - making addresses comply with the rules for the larger memory model. The code doesn't otherwise need to change - but subroutine calls that pass object pointers definitely need updating.
 
Thank you all for your quick and reliable responses.
My next puzzle is where do I insert or edit in this code to be 64bit and backward compartible as the examples given where all running incomplete statements with ... ends
Please edit this my code and let me see the typical example here.
Thanks!


'Revised Type Declare for compatability with NT
Type tagOPENFILENAME
lStructSize As Long
hwndOwner As Long
hInstance As Long
lpstrFilter As String
lpstrCustomFilter As Long
nMaxCustFilter As Long
nFilterIndex As Long
lpstrFile As String
nMaxFile As Long
lpstrFileTitle As String
nMaxFileTitle As Long
lpstrInitialDir As String
lpstrTitle As String
Flags As Long
nFileOffset As Integer
nFileExtension As Integer
lpstrDefExt As String
lCustData As Long
lpfnHook As Long
lpTemplateName As Long
End Type

Private Declare Function GetOpenFileName Lib "comdlg32.dll" _
Alias "GetOpenFileNameA" (OPENFILENAME As tagOPENFILENAME) As Long

Private Sub HandleError(strLoc As String, strError As String, intError As Integer)
MsgBox strLoc & ": " & strError & " (" & intError & ")", 16, "CheckTableLinks"

End Sub

Private Function TableLinkOkay(strTableName As String) As Boolean
'Function accepts a table name and tests first to determine if linked
'table, then tests link by performing refresh link.
'Error causes TableLinkOkay = False, else TableLinkOkay = True
Dim CurDB As DAO.Database
Dim tdf As TableDef
Dim strFieldName As String
On Error GoTo TableLinkOkayError
Set CurDB = DBEngine.Workspaces(0).Databases(0)
Set tdf = CurDB.TableDefs(strTableName)
TableLinkOkay = True
If tdf.Connect <> "" Then
strFieldName = tdf.Fields(0).Name 'Do not test if nonlinked table
End If
TableLinkOkay = True
TableLinkOkayExit:
Exit Function
TableLinkOkayError:
TableLinkOkay = False
GoTo TableLinkOkayExit

End Function
 
Sorry but I believe it won't work in 64-bit Access even if you use conditional compilation
The Windows common controls library comdlg32.all on which GetOpenFileName depends has never been updated for 64-bit and in fact isn't included with recent versions of Windows 10

If you want code for 64-bit that will allow you to browse for a file and select it, I suggest you use FileDialog code instead.
By chance I just published something today that uses that code
See https://www.access-programmers.co.uk/forums/showthread.php?t=302291
 
Last edited:
Sorry but I believe it won't work in 64-bit Access even if you use conditional compilation
The Windows common controls library comdlg32.all on which GetOpenFileName depends has never been updated for 64-bit and in fact isn't included with recent versions of Windows 10

If you want code for 64-bit that will allow you to browse for a file and select it, I suggest you use FileDialog code instead.
By chance I just published something today that uses that code
See https://www.access-programmers.co.uk/forums/showthread.php?t=302291


Thanks, I think this will work for me.
Thank you so much
 
Thank you all who contributed immensely to my question.
After series of suggestions and advice from this house, I have resolve to use just 32-bits access application and it worked perfectly
I learned from this research that there's difference between 32 and 64-bits even of the same access 2016 which I am using. I never knew before now


Thank you all once again!
 
On behalf of all of us, you're welcome

However if you are developing for other users, you need to bear in mind that the 64-bit user base is slowly increasing.

Based on a non-scientific sample of AWF users, it may be that approx 1/3 of users now have 64-bit on at least one PC.
See https://www.access-programmers.co.uk/forums/showpost.php?p=1583055&postcount=1

So at some stage you may have to cater for 64-bit as well.
 

Users who are viewing this thread

Back
Top Bottom