Compile error 64-bit system

LanaR

LanaR

Member
Local time
Today, 19:16
Joined
May 20, 2021
Messages
113
I've just taken possession of a new pc with windows 11, and of course the latest version of access. One of my DB's (I'm sure there will be others) is now giving me the following error, which I have no idea how to fix. I'm pretty sure it is code I found in these forums sometime ago.

1669988125642.png
 
Easiest way would be to revert back to Access 32 bit, unless you specifically need 64 bit, else would need to add PtrSafe as it mentions.

Plenty of threads on here about conversion to 64 bit.

You would think MS would have a converter by now? :(
 
jdraw said:
LanaR,

I agree with Paul. You have met a common problem when moving from 32bit to 64bit Access/Office.
You may find some insight in this Richard Rost video.
There are other videos and various posts in the forums.
Click to expand...
That's the one I was looking for but you were quicker on the "draw"...
 
LanaR said:
I've just taken possession of a new pc with windows 11, and of course the latest version of access.
One of my DB's (I'm sure there will be others) is now giving me the following error, which I have no idea how to fix. I'm pretty sure it is code I found in these forums sometime ago.

View attachment 105013
Click to expand...
What others have alluded to, but not made explicit, is that you installed the 64 bit version of Office when you installed "...of course the latest version..."

Office has been available in both 32 bit and 64 bit versions from some time, but up until recently, the 32 bit version was the default. In the recent past, that changed and now the default installation will be the 64 bit version, which you have.

While you could uninstall the 64 bit version and install the 32 bit version, it's probably a good idea to modify your code, and there are lots of resources available to show you how to do that.
 
Gasman said:
Easiest way would be to revert back to Access 32 bit, unless you specifically need 64 bit, else would need to add PtrSafe as it mentions.

Plenty of threads on here about conversion to 64 bit.

You would think MS would have a converter by now? :(
Click to expand...
Your VBA is custom code, created by you , for your application. You REALLY want MS trying to convert your custom code for you? I sure don't.
 
Thanks for all the advice. Most appreciated :)
 
check if this will work for you:
Code: 
' updated for x64 by arnelgp
'
#If VBA7 Then
    Type tsFileName
        lStructSize As Long
        hwndOwner As LongPtr
        hInstance As LongPtr
        strFilter As String
        strCustomFilter As String
        nMaxCustFilter As Long
        nFilterIndex As Long
        strFile As String
        nMaxFile As Long
        strFileTitle As String
        nMaxFileTitle As Long
        strInitialDir As String
        strTitle As String
        flags As Long
        nFileOffset As Integer
        nFileExtension As Integer
        strDefExt As String
        lCustData As Long
        lpfnHook As LongPtr
        lpTemplateName As String
    '#if (_WIN32_WINNT >= 0x0500)
        pvReserved As LongPtr
        dwReserved As Long
        FlagsEx As Long
    '#endif // (_WIN32_WINNT >= 0x0500)
    End Type
#Else
    Type tsFileName
        lStructSize As Long
        hwndOwner As Long
        hInstance As Long
        strFilter As String
        strCustomFilter As String
        nMaxCustFilter As Long
        nFilterIndex As Long
        strFile As String
        nMaxFile As Long
        strFileTitle As String
        nMaxFileTitle As Long
        strInitialDir As String
        strTitle As String
        flags As Long
        nFileOffset As Integer
        nFileExtension As Integer
        strDefExt As String
        lCustData As Long
        lpfnHook As Long
        lpTemplateName As String
    End Type
#End If

#If VBA7 Then
    Declare PtrSafe Function ts_apiGetOpenFileName Lib "comdlg32.dll" Alias "GetOpenFileNameA" (pOpenfilename As tsFileName) As Long
    Declare PtrSafe Function ts_apiGetSaveFileName Lib "comdlg32.dll" Alias "GetSaveFileNameA" (pOpenfilename As tsFileName) As Long
    Private Declare PtrSafe Function CommDlgExtendedError Lib "comdlg32.dll" () As Long
#Else
    Declare Function ts_apiGetOpenFileName Lib "comdlg32.dll" _
        Alias "GetOpenFileNameA" (OFN As tsFileName) As Boolean
        
    Declare Function ts_apiGetSaveFileName Lib "comdlg32.dll" _
        Alias "GetSaveFileNameA" (OFN As tsFileName) As Boolean
    Private Declare Function CommDlgExtendedError Lib "comdlg32.dll" () As Long
#End If
 
GPGeorge said:
Your VBA is custom code, created by you , for your application. You REALLY want MS trying to convert your custom code for you? I sure don't.
Click to expand...
For an expert, I would have thought it would be relatively easy to copy the lines, comment them out and amend for 64bit?
It is only the API calls after all, is it not?

I am on 2007, so no big deal for me. :)
 
There are two schools of thought on this problem. If you don't need million-row spreadsheets or million-character Word documents, it might be easier to back out of 64-bit Office and install the 32-bit Office version. You will not see any negatives in anything unless and until you create something SO large that it becomes a mental challenge to understand it. 32-bit Office runs absolutely fine on a 64-bit machine. (I'm doing it now!)

Further, note that due to reasons known only to Microsoft, SOME of the possible libraries you might use in your References list were not converted to use 64-bit addressing, thus adding to the fun of conversion. I don't know if all of the unconverted libraries have been updated as of this date but I know that a lot of them were "left behind" when the default for Office became the 64-bit version.

In this thread's "Similar Threads" section (always after the last post in the thread) you might find some other articles on 32-bit vs. 64-bit issues.
 
There is only one real benefit to using 64-bit Access though it is important.
The 64-bit version has much better memory handling which means significantly reduced risk of Access crashing due to out of memory errors. It also means some very demanding process will be able to run or will run faster.

It is possible to alleviate this by adding large address awareness (LAA) to 32-bit Access running under 64-bit Windows though at the moment LAA gets overwritten each time Access is updated.
For more details, see

The /LARGEADDRESSAWARE (LAA) flag - Remedy for out-of-memory errors

How to apply the /LARGEADDRESSAWARE (LAA) flag to the MsAccess.exe to get rid of out-of-memory and resources exceeded errors.
codekabinett.com codekabinett.com

As for the 3 APIs above, I suggest you scrap the code you're using that the relies on the first two. Instead use File System Object (FSO) code which runs in both bitnesses. I've never used the ComDlgExtendedError API
 
The code looks like a FileDialog. You could also use the one from the MS Office object library, preferably in a variant using late binding by Daniel Pineault: Late Binding the FileDialog
The selection of directories is included, this will not be the case with your variant.
 
moke123 said:
As a big fan of FSO, that's a helpful tidbit of information.

Book marked Phil's article for future refernce.
Click to expand...
Preface: I feel the exact same way.

Nonetheless, it reminds me of a time when I was working in an ultra professional team of ETL developers at a major bank. A little over my head, as I was the lowest-skilled guy on the team, despite my love for SSIS and having produced hundreds of packages in my time.
Anyway, one of the main things that I was called out for was my Script Tasks.
Their first shock was that I was using vb.net option instead of c#.net option, they wondered why anyone under the age of 80 might be doing that. I didn't have any defense other than, I was used to "all things VB*", and therefore tried in vain to defend it but that was when I realized the frequent dev shop preference for c#.net over vb.net. In my defense I then tried to study the why's, but can't remember them any more. A lotta brackets was all I remember.
The second thing that DID make me flush briefly was they pointed out that while I had made a nice little vb.net Script Task, I wasn't even leveraging the .Net benefits in the first place!--pointing out my use of Createobject() for Office app instantiations, and as the icing on the cake that basically ended the meeting, my use of Scripting.FileSystemObject to work with files and folders...they were like "man, that stuff is so OOOLD and gross you're lucky the toilet down the hall didn't start leaking when you ran that". I had no defense other than OK, you got me -- I'm much more a VBA developer than I am a .Net developer but I will try to learn and be better.
In my defense I did then proceed to study a bit about .Net's ability to fly through files and folders and DAMN, it really WAS good. In the snap of literally a few words of code you could stack up an array of folders, files, and make all kinds of useful inquiries about them. Pretty slick.

I only stayed on that job 10 mo. I enjoyed learning from people "above" me, that wasn't the problem. What was ultimately my downfall was the stressful feeling of depending on offshore team (India) to get on the phone with me and explain exactly how to use all of the SSIS templates, env variables, dynamic server environments, etc. I love learning stuff but when you have to ask a person to repeat every single sentence or phrase they say 5-6 times before it is understood (or given up on), it becomes very uncomfortable for both parties, I'm sure.
Between that and the bank's E-X-T-E-N-S-I-V-E "change management" burearocracy that required a full time job to keep up with, I decided to move to another opportunity. But I learned a lot of great SQL Server tips on that job, like the usefulness of TVF's and the wisdom of deleting large amounts of records in looped batches to avoid the SQL job hanging indefinitely and the boss having to ask why the lights were dimming.

Good memories. Sorry to soapbox the thread, but you get all kinds of feedback sometimes!
 
Management always thinks that you are ultra smart when they can't understand a word you are saying. Doesn't much matter whether it is a natural language problem or you just use technical words that do not compute:)
 
Surely, reverting to the 32 bit version is just going to delay an inevitable crunch when MS stops supporting it? Along with creating, potentially, additional work in the future.
 
If you are not dependent on any 32 bit add ins AND don't have to support any users still on 32 bit, then converting now is fine. If you have users who are using the 32 bit version of Office, I would not convert until they do.
 
You must log in or register to reply here.

Similar threads

C
Northwind 2.0 fresh template startup errors on Access 365
2
Replies
22
Views
644
jdraw
jdraw
P
32-bit + 64-bit
2
Replies
32
Views
1,113
Pat Hartman
P
K
Is this a normal behavior in Access?
2
Replies
26
Views
531
The_Doc_Man
The_Doc_Man
D
Microsoft Visual Basic for Applications Compile error: The code in this project must be updated for use on 64-bit systems.
2
Replies
34
Views
8,861
arnelgp
arnelgp
S
Solved There isn't enough memory to perform this operation... (Access 2013, 64-bit on Windows 11)
Replies
13
Views
1,185
Simon_C
S

Users who are viewing this thread

Total: 1 (members: 0, guests: 1)
Back
Top Bottom