Migrating to 64 bit access db solution
in [Help]
|
From: Yuval Nir on 20 Jan 2010 22:37 Hello all. I don't know if anybody encountered upgrading to 64 bit. I have an older database that I need to upgrade and place on office 64bit machine. I am getting a compile error message: The code in this project must be updated for use on 64 bit systems. Please review and update declare statements and then mark them with the PtrSafe attribute. Those of you who are as "seasoned" as I am, might remember the code changes we had to make moving from 16 to 32 bit... Any advice or KB paper? Thanks. Yuval
From: Banana on 21 Jan 2010 00:22 Yuval Nir wrote: > Hello all. I don't know if anybody encountered upgrading to 64 bit. I > have an older database that I need to upgrade and place on office > 64bit machine. I am getting a compile error message: The code in this > project must be updated for use on 64 bit systems. Please review and > update declare statements and then mark them with the PtrSafe > attribute. Those of you who are as "seasoned" as I am, might remember > the code changes we had to make moving from 16 to 32 bit... > Any advice or KB paper? > Thanks. > Yuval While I've yet to try and move my old files to my beta machine, I would ask you if you actually have any Declare statement in your code. If this is indeed the case, then you just need to update those with the PtrSafe directive... If you search on "PtrSafe" in VBE's help file, there's a good explanation. Here's an example from the file: <<< Consider the following Declare statement examples. Running the unmodified Declare statement in 64-bit versions of Office will result in an error indicating the Declare statement does not include the PtrSafe qualifier. The modified VBA example contains the PtrSafe qualifier, but notice that the return value (a pointer to the active window) returns a Long data type. On 64-bit Office, this is incorrect because the pointer needs to be 64-bits. The PtrSafe qualifier tells the compiler the Declare statement is targeting 64-bits, so the statement executes without error. But because the return value has not been updated to a 64-bit data type, the return value is truncated resulting in an incorrect value returned. Unmodified legacy VBA Declare statement example: Declare Function GetActiveWindow Lib "user32" () As Long VBA Declare statement example modified to include the PtrSafe qualifier but still using a 32-bit return value: Declare PtrSafe Function GetActiveWindow Lib "user32" () As Long To reiterate, you must modify the Declare statement to include the PtrSafe qualifier and you must update any variables within the statement that need to hold 64-bit quantities so that the variables use 64-bit data types. VBA Declare statement example modified to include the PtrSafe keyword and updated to use the proper 64-bit (LongPtr) data type: Declare PtrSafe Function GetActiveWindow Lib "user32" () As LongPtr In summary, for code to work in 64-bit versions of Office, you need to locate and modify all existing Declare statements to use the PtrSafe qualifier. And you need to locate and modify all data types within these Declare statements that reference handles or pointers to use the new 64-bit compatible LongPtr type alias, and types that need to hold 64-bit integrals with the new LongLong data type. Additionally, you must update any user defined types (UDTs) that contain pointers or handles, and 64-bit integrals to use 64-bit data types and verify all variable assignments are correct to prevent type mismatch errors. >>> So, basically, add "PtrSafe", and change "Long" to "LongPtr" for where handlers or pointers are used or expected. (Don't change Long parameter if it's not a handler or pointer type) HTH.
From: Yuval Nir on 21 Jan 2010 11:41 On Jan 20, 11:22 pm, Banana <Ban...(a)Republic.com> wrote: > Yuval Nir wrote: > > Hello all. I don't know if anybody encountered upgrading to 64 bit. I > > have an older database that I need to upgrade and place on office > > 64bit machine. I am getting a compile error message: The code in this > > project must be updated for use on 64 bit systems. Please review and > > update declare statements and then mark them with the PtrSafe > > attribute. Those of you who are as "seasoned" as I am, might remember > > the code changes we had to make moving from 16 to 32 bit... > > Any advice or KB paper? > > Thanks. > > Yuval > > While I've yet to try and move my old files to my beta machine, I would > ask you if you actually have any Declare statement in your code. > > If this is indeed the case, then you just need to update those with the > PtrSafe directive... If you search on "PtrSafe" in VBE's help file, > there's a good explanation. > > Here's an example from the file: > > <<< > > Consider the following Declare statement examples. Running the > unmodified Declare statement in 64-bit versions of Office will result in > an error indicating the Declare statement does not include the PtrSafe > qualifier. The modified VBA example contains the PtrSafe qualifier, but > notice that the return value (a pointer to the active window) returns a > Long data type. On 64-bit Office, this is incorrect because the pointer > needs to be 64-bits. The PtrSafe qualifier tells the compiler the > Declare statement is targeting 64-bits, so the statement executes > without error. But because the return value has not been updated to a > 64-bit data type, the return value is truncated resulting in an > incorrect value returned. > > Unmodified legacy VBA Declare statement example: > > Declare Function GetActiveWindow Lib "user32" () As Long > > VBA Declare statement example modified to include the PtrSafe qualifier > but still using a 32-bit return value: > > Declare PtrSafe Function GetActiveWindow Lib "user32" () As Long > > To reiterate, you must modify the Declare statement to include the > PtrSafe qualifier and you must update any variables within the statement > that need to hold 64-bit quantities so that the variables use 64-bit > data types. > > VBA Declare statement example modified to include the PtrSafe keyword > and updated to use the proper 64-bit (LongPtr) data type: > > Declare PtrSafe Function GetActiveWindow Lib "user32" () As LongPtr > > In summary, for code to work in 64-bit versions of Office, you need to > locate and modify all existing Declare statements to use the PtrSafe > qualifier. And you need to locate and modify all data types within these > Declare statements that reference handles or pointers to use the new > 64-bit compatible LongPtr type alias, and types that need to hold 64-bit > integrals with the new LongLong data type. Additionally, you must update > any user defined types (UDTs) that contain pointers or handles, and > 64-bit integrals to use 64-bit data types and verify all variable > assignments are correct to prevent type mismatch errors. > > >>> > > So, basically, add "PtrSafe", and change "Long" to "LongPtr" for where > handlers or pointers are used or expected. (Don't change Long parameter > if it's not a handler or pointer type) > > HTH. Thanks. I will do that.
From: David W. Fenton on 21 Jan 2010 13:47 Banana <Banana(a)Republic.com> wrote in news:4B57E480.3010408(a)Republic.com: > So, basically, add "PtrSafe", and change "Long" to "LongPtr" for > where handlers or pointers are used or expected. (Don't change > Long parameter if it's not a handler or pointer type) And there's no problem with this in 32-bit environments? It seems there *is* a problem, as if I do this, my code won't compile any longer. -- David W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/
From: Banana on 21 Jan 2010 14:35
David W. Fenton wrote: > Banana <Banana(a)Republic.com> wrote in > news:4B57E480.3010408(a)Republic.com: > >> So, basically, add "PtrSafe", and change "Long" to "LongPtr" for >> where handlers or pointers are used or expected. (Don't change >> Long parameter if it's not a handler or pointer type) > > And there's no problem with this in 32-bit environments? It seems > there *is* a problem, as if I do this, my code won't compile any > longer. > The help file suggests using conditional compilation. Furthermore, VBA7 supports LongPtr for both environments as it is intended to be a scalable type (converts to a Long on 32-bit, LongLong on 64-bit). I've not tested extensively and I don't have a 32-bit Access 2010 handy to see how this all would work out. I'm under the impression that when using older files, they will run just fine on a 32-bit Access 2010. I'm unclear whether 64-bit Access provides some kind of compatibility environment for those files but I understand you can take in a older file and re-compile it for 64-bit. If the code doesn't contain any API calls, then it's completely transparent - just a simple re-compile will do. OTOH, with API calls, well, the earlier suggestion applies. Maybe this will be of interest? http://www.utteraccess.com/forums/showflat.php?Cat=&Board=93&Number=1914261&fpart=1 |