[AccessD] 64-bit

[Jim Dettman]

<< I think it's going to be time to push everyone to 64-bit versions of
Office, even if we aren't on the O365 suite.>>

 I would say that would be a wise move at this point.

 Microsoft is starting to push 64 bit because as you have found, later
versions of Office are starting to run out of process address space.   I
don't believe they plan on making Access Large Address aware, so the only
"fix" for this is to move to 64 bit.

 When you move to 64 bit, all your API calls, calls to .DLL's or .OCX's, and
ODBC drivers all must be 64 bit.  Apps without any of those will just run.
Apps with those will need some porting. If you haven't dived into 64 bit as
yet, you should read the following:

Compatibility Between the 32-bit and 64-bit Versions of Office 2010
http://msdn.microsoft.com/en-us/library/ee691831(office.14).aspx

 Read the section "Introducing the VBA 7 Code Base" carefully.   It's
confusing at best.    The thing to keep clear is that the WIN64 compiler
constant is telling you if *Office* is running in 64 bit or not and VBA7 is
if you are working in the version of VBA that supports the PtrSafe Keyword
and LongLong data type (Access 2010 and above).

 There are all the API calls that will need to be modified for 64 bit:

http://www.microsoft.com/download/en/confirmation.aspx?displaylang=en&id=997
0

and here's a list of all the calls that were modified for 64 bit:
http://msdn.microsoft.com/en-us/library/aa383663(VS.85).aspx

 .DLLs, OCX's, etc you need to check with the vendor's.

ODBC drivers almost always come with 32 and 64 bit versions now, so that's
not as much of an issue as it once was.

 Only other comment is that when working with ODBC and DSN's,  you must use
the appropriate ODBC applet.  32 bit version is
C:\Windows\SysWoW64\Odbcad32.exe   and the 64 bit version is
C:\Windows\System32\Odbcad32.exe      And that executable in both cases is
correct...it is the same name.   Also to avoid confusion, make sure you
suffix any DSN's with _32 or _64.   The two applets depending on the type of
DSN (File, System, or User) may display both 32 and 64 bit setups.  This was
required for backwards compatibility, but it makes it very confusing at
times what you're working with if you don't use suffixes.

Jim.

-----Original Message-----
From: AccessD [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of
Ryan W
Sent: Thursday, September 12, 2019 3:55 PM
To: Access Developers discussion and problem solving
Subject: [AccessD] 64-bit

Now that Office 365/Access 2019 installs default to 64-bit, for the first
time ever has anyone spent the time to test their apps in it?

We're working on our Windows 10 rollout and are seeing even higher than
ever memory constraints with our application in 32-bit mode than ever
before.  Even thanks to John Colby's expertise in using classes to load and
unload subforms on the fly which has worked most effectively for Windows 7
running 32-bit Office/Access.

I think it's going to be time to push everyone to 64-bit versions of
Office, even if we aren't on the O365 suite.
-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com