Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Converting from 32bit to 64 bit. After converting, database takes significantly longer to open

breezett93

Technical User
Jun 24, 2015
132
US
Currently I have users that are using Microsoft Office versions 2013 - 2021. All are 32 bit because our ancient access database requires 32 bit.
Now, I am migrating all users to Microsoft Business 365; so I need to convert the database to 64 bit. I updated all the Declare statements to include PtrSafe. The database opens with no errors.
However, on my current Office 2016 dev machine, the database takes 5 seconds to open. Now, on my Business 365 dev machine, the database is taking on average 60 seconds to open.

My 2016 dev machine is a 8+ year old desktop, and my 365 dev machine is a brand new laptop. Both are using wired ethernet, no wifi. The laptop has better hardware (Ryzen 5 16gb ram vs Intel i5 8GB ram); so I'm confident it has to be a software issue. Is there more I need to do to truly convert the database to 64 bit?

Thanks.
 
Does your code compile?
No. There are several modules that are very, very old, built long before I started. I have avoided correcting errors to the old sections because the program has usually run well. In the past, when I have tried correcting old code, it tends to break the rest of the program.

For example, the first error triggered during compile is in an old module, and the error tells me that the .Find method can't be found. However, I know that Find is a Microsoft function.

Are you suggesting the errors are the reason for the increased load times? If so, why are the errors not affecting older versions of Office?
 
I don’t do anything else until the compile errors are fixed. I hope your application is split so you can make updates to a copy of the front end file. “Find” error would occur if you are attempting this against a linked table. There also could be an issue with the references and DAO vs ADO. Find is DAO.
 
I don’t do anything else until the compile errors are fixed. I hope your application is split so you can make updates to a copy of the front end file. “Find” error would occur if you are attempting this against a linked table. There also could be an issue with the references and DAO vs ADO. Find is DAO.
Yes, the application is split. I made a copy of the front end. I have gone through and either corrected all errors, or commented out code with errors that were on forms no longer used.

The database is still taking approximately the same amount of time to load.
 
Is there any code running when the application opens? Do you have a default printer identified in Windows?

Some developers recommend keeping a table open in the back-end while the application is running.

You might want to check the Access Forever page which has the most up-to-date list of bugs and fixes.
 
Is there any code running when the application opens? Do you have a default printer identified in Windows?

Some developers recommend keeping a table open in the back-end while the application is running.

You might want to check the Access Forever page which has the most up-to-date list of bugs and fixes.
Yes, there is a version checker that runs immediately and triggers an auto update if the version numbers don't match.
Yes, I have a default printer on my machine.

Why would those things cause a 64 bit version of the db to run poorly compared to the 32 bit version?
 
I’m just throwing stuff at the wall to see if anything sticks. Did you check out the bugs page?
 

Part and Inventory Search

Sponsor

Back
Top