UtterAccess.com
X   Site Message
(Message will auto close in 2 seconds)

Welcome to UtterAccess! Please ( Login   or   Register )

Custom Search
 
   Reply to this topicStart new topic
> From 2003 To 2013 Version Problem, Access 2013    
 
   
nostor
post Jul 24 2020, 01:38 AM
Post#1



Posts: 1
Joined: 24-July 20



Hi,
I have prepared a database in msaccess with 2003 version and used it very successfully at my bussiness for years. Now I have switched to 2013 but my db gives error at the very beginning and I see a message as:
"Compile Error
The code in this project must be updated for use on 64 bit systems. Please review and update Declare statemens and then mark them with the PrtSafe attribute"
Is the problem arising from my computer? How can I solve this problem?
Thanks for advices.
p.s: my computer is new and 64 bit system.
Ruhi Kulez
Go to the top of the page
 
Gustav
post Jul 24 2020, 02:45 AM
Post#2


UtterAccess VIP
Posts: 2,305
Joined: 21-February 07
From: Copenhagen


You probably miss PtrSafe in the declarations.

Browse to paragraph API compatibility here: Compatibility between the 32-bit and 64-bit versions of Office

--------------------
Microsoft Office 365 (Access) MVP 2017 ->
Go to the top of the page
 
FrankRuperto
post Jul 24 2020, 06:39 AM
Post#3



Posts: 1,219
Joined: 21-September 14
From: Tampa, Florida USA


The other alternative is to reinstall 32-bit Office 2013, and I strongly recommend you do this because nothing is really gained by using the 64-bit version.

--------------------
Currently supporting pawnbrokers that use my store management system developed with Access 2010 on Windows7. Experienced with Informix, Oracle & PostgreSQL db's.
Go to the top of the page
 
Gustav
post Jul 24 2020, 07:20 AM
Post#4


UtterAccess VIP
Posts: 2,305
Joined: 21-February 07
From: Copenhagen


Time is turning, and the direction is 64-bit.

Thus, instead of fighting back, move ahead. The conversion issues are often small and, when done, forgotten.

We've upgraded everything to 64-bit - servers, workstations, Office, and applications - and the issues we've met have been surprisingly few.

--------------------
Microsoft Office 365 (Access) MVP 2017 ->
Go to the top of the page
 
GroverParkGeorge
post Jul 24 2020, 07:34 AM
Post#5


UA Admin
Posts: 37,632
Joined: 20-June 02
From: Newcastle, WA


First, Welcome to UtterAccess.

Microsoft recommended the 32 bit version of Office over the 64 bit version for the majority of users for quite a while. Recently, however, they changed the default installation from 32 bit to 64 bit.

To me that is a pretty good indication, that we need to acknowledge the time has come to move ahead as well.
This post has been edited by GroverParkGeorge: Jul 24 2020, 07:35 AM

--------------------
My Real Name Is George. Grover Park Consulting is where I did business for 20 years.
How to Ask a Good Question
Beginning SQL Server
Go to the top of the page
 
FrankRuperto
post Jul 24 2020, 09:23 AM
Post#6



Posts: 1,219
Joined: 21-September 14
From: Tampa, Florida USA


My opinion is: As for the OP's post, I think he can quickly get his 2003 app running in Access 2013 if he just reinstalls 32-bit Office/Access. Then he has plenty of time to mod his app to run 64-bit. I also think its still premature to rush into everything 64-bit. I dont think Microsoft will ever disable 32-bit software from running on Windows. MS also has a contradiction. On one hand they still recommend using 32-bit Office, but have 64-bit Office as the default install version. 64-bit could be fine if you're starting a project from scratch, but most users already have 32-bit apps and want to continue running them ASAP.
This post has been edited by FrankRuperto: Jul 24 2020, 09:27 AM

--------------------
Currently supporting pawnbrokers that use my store management system developed with Access 2010 on Windows7. Experienced with Informix, Oracle & PostgreSQL db's.
Go to the top of the page
 
GroverParkGeorge
post Jul 24 2020, 09:34 AM
Post#7


UA Admin
Posts: 37,632
Joined: 20-June 02
From: Newcastle, WA


It literally took me less than five minutes to amend the APIs in a recent accdb I modified to run under 64 bit Access....

--------------------
My Real Name Is George. Grover Park Consulting is where I did business for 20 years.
How to Ask a Good Question
Beginning SQL Server
Go to the top of the page
 
FrankRuperto
post Jul 24 2020, 09:51 AM
Post#8



Posts: 1,219
Joined: 21-September 14
From: Tampa, Florida USA


That may be fine for your case, but other apps may be different. I think the priority is to get up and running ASAP. Another factor to consider is, some apps are using 32-bit API add-ons, but have no 64-bit equivalents.

--------------------
Currently supporting pawnbrokers that use my store management system developed with Access 2010 on Windows7. Experienced with Informix, Oracle & PostgreSQL db's.
Go to the top of the page
 
BruceM
post Jul 24 2020, 01:40 PM
Post#9


UtterAccess VIP
Posts: 8,157
Joined: 24-May 10
From: Downeast Maine


Compiling the VBA code should show you where the problems are. If it is APIs, which is likely, it's not quite as simple as changing the function declarations to LongPtr, but it's not a difficult fix. If all users have Access 2010 or later you can use the APIs posted on UA, or anywhere current versions are posted. If some installations have Access 2007 or earlier you will need to do conditional compilation. The linked article from an earlier posting has some information, but more useful information can be found here

Note that there is rarely a reason to do Win64 conditional compilation as long as you do VBA7 conditional compilation. And the only reason not simply to use the new versions of APIs is that there are pre-2010 installations.
The VBA version changed from 6 to 7 with Access 2010, which was also when 64-bit became available. PtrSafe and LongPtr refer to managing pointers or handles, which are memory locations rather than defined values. In 32-bit Access these memory locations are 32 bits, and in 64-bit they are 64 bits. It's OK as long as you are in a 32-bit version since both the memory location and the Long data type are 32 bits. However, the 64-bit doesn't know what to do with a 32-bit value in a 64-bit memory location unless you specify the necessary variables as LongPtr, which causes Access to adjust them to fit the memory location.
Go to the top of the page
 


Custom Search


RSSSearch   Top   Lo-Fi    6th August 2020 - 07:49 AM