[AccessD] 64-bit

[Ryan W]

Thanks. I had already gone through and made the necessarily changes previously for 64-bit compiling with the compiler constant if/then/else logic and seemed to get a clean compile. I guess rigorous testing is next. 



Sent from my iPhone

> On Sep 13, 2019, at 6:44 AM, Jim Dettman via AccessD <accessd at databaseadvisors.com> wrote:
> 
> << 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
> 
> -- 
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com