Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Anyone have EXPERIENCE in converting 32 bit Access to 64 bit?
4,299 views
Skip to first unread message
BobAlston
Jan 29, 2012, 2:34:10 PM1/29/12
to
Anyone have EXPERIENCE in converting 32 bit Access to 64 bit?
I found this tool
http://technet.microsoft.com/en-us/library/ff453909.aspx
that apparently will report on 64 bit issues - running it now.
bob
I found this tool
http://technet.microsoft.com/en-us/library/ff453909.aspx
that apparently will report on 64 bit issues - running it now.
bob
Albert D. Kallal
Jan 29, 2012, 3:12:47 PM1/29/12
to
"BobAlston" wrote in message news:jg46v7$akn$1...@dont-email.me...
>Anyone have EXPERIENCE in converting 32 bit Access to 64 bit?
As a general rule, it is strongly recommend that you stick to Access 32.
There is little if any reason I can think of jumping to use Access x64.
The list of downsides is quite large when you move to x64.
Most if not all of any windows API code has to be modified to use the
windows 64 bit version. If you use Access x32 even on 64 bit os, no change
is required.
If one is using any external ActiveX (com objects) that are x32, then you
have to find an equivalent 64 bit version. With treeview, listview, and the
Calendar, all of these have quite common been used over the years in Access
applications. However, NONE of them can be used with Access x64 (you have to
find x64 versions of these controls, and for the most part none exist!).
So for applications that use treeview, then Access x64 cannot be used.
Last but not least, x64 of Access cannot automate say Outlook 2007 or ANY
previous version of word. In other words, you cannot mix and max the "bit
size" of applications. So if you deploy the Access x64 runtime on a machine
with any previous version of office, you not be able to automate Word,
Excel, Outlook etc.
Last but not least, be aware that an accDE compiled with Access x64 cannot
be consumed and used by Access x32 (even including the same release and
office version of Access). In other words you now have to maintain and
distribute two versions of an accDE if you going to support Access x64. This
requirement does not exist for accDB since the VBA source code is included
and thus on-demand compiles can occur. However, the VBA code will have to
include switches for API calls etc. and of course one cannot use the x64 bit
wide new variable types we have in the x64 bit version of Access in the x32
version.
Since there are VERY few reasons to use Access x64, it best to use and stick
to using Access x32, and that is even the case for office 2010.
--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
Pleasenos...@msn.com
>Anyone have EXPERIENCE in converting 32 bit Access to 64 bit?
There is little if any reason I can think of jumping to use Access x64.
The list of downsides is quite large when you move to x64.
Most if not all of any windows API code has to be modified to use the
windows 64 bit version. If you use Access x32 even on 64 bit os, no change
is required.
If one is using any external ActiveX (com objects) that are x32, then you
have to find an equivalent 64 bit version. With treeview, listview, and the
Calendar, all of these have quite common been used over the years in Access
applications. However, NONE of them can be used with Access x64 (you have to
find x64 versions of these controls, and for the most part none exist!).
So for applications that use treeview, then Access x64 cannot be used.
Last but not least, x64 of Access cannot automate say Outlook 2007 or ANY
previous version of word. In other words, you cannot mix and max the "bit
size" of applications. So if you deploy the Access x64 runtime on a machine
with any previous version of office, you not be able to automate Word,
Excel, Outlook etc.
Last but not least, be aware that an accDE compiled with Access x64 cannot
be consumed and used by Access x32 (even including the same release and
office version of Access). In other words you now have to maintain and
distribute two versions of an accDE if you going to support Access x64. This
requirement does not exist for accDB since the VBA source code is included
and thus on-demand compiles can occur. However, the VBA code will have to
include switches for API calls etc. and of course one cannot use the x64 bit
wide new variable types we have in the x64 bit version of Access in the x32
version.
Since there are VERY few reasons to use Access x64, it best to use and stick
to using Access x32, and that is even the case for office 2010.
--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
Pleasenos...@msn.com
bobal...@gmail.com
Jan 11, 2017, 9:43:53 PM1/11/17
to
Anyone care to update the answer for 2017?
Bob
Bob
Albert Kallal (Access MVP)
Jan 18, 2017, 10:04:44 PM1/18/17
to
On Wednesday, January 11, 2017 at 7:43:53 PM UTC-7, bobal...@gmail.com wrote:
> Anyone care to update the answer for 2017?
>
> Bob
Well, time does march on. And we now seeing more and more clients and companies adopt the x64 bit version of Access.
> Anyone care to update the answer for 2017?
>
> Bob
For those using AutoCAD, or .net applications, then to automate Access, or more often have Access automate and use “other” programs, those other programs “more and more” are now x64 bits.
As a result the above trend is forcing our hand to adopt and use Access x64.
So the reasons to jump to x64 Access does over time tilt things more towards one having to use or deal with Access x64.
There not a lot of “news” or changes in regards to adopting Access x64, and the steps are much the same as outlined 4 years ago.
They are:
If you use any ActiveX, such as a calendar control, then you need to find + use an x64 bit version of that ActiveX.
There not an x64 bit version of the TreeView or the Calendar control – so once again before committing to upgrade access x32 to x64, then any ActiveX control used will have to be replaced with an x64 bit version. If such controls are not available (and they often are not), then moving to x64 would be a challenge.
Changes to API code.
If one is using any API code in VBA then such code will have to be upgraded to work with x64 windows API. To my knowledge all x32 windows API’s do have an x64 bit version. The only challenge here is making modifications to the API declares in Access – they can be a challenge.
Other than above – no real changes to the previous post. While office x32 is still the recommended choice today, when one is faced with having to interface with .NET applications, or other x64 bit versions of office (such as Excel), then you have to choose Access x64.
The “most” common occurrence I see is power users adopting Excel x64 – the memory and abilities of Excel x64 is greater than that of Excel x32. So if a company is using Excel x64, and you need to interface or automate that Excel x64 application from Access, then you have to adopt Access x64.
Regards,
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
PleaseNoS...@msn.com
Edmonton, Alberta Canada
Ron Paii
Jan 19, 2017, 4:03:07 PM1/19/17
to
I ran into the 64 bit issue when pulling information from AutoCad. My solution was to have the Access application push data into a SQL server database. Access (32 bit) had no problems with the 64 bit SQL server driver being installed.
Depending on the 64 bit application, you may be able to automate from 32 bit Access. One example is Solidworks' EPDM.
PS: My 1st attempt was to attached the MDB using Linked Servers in SQL server, but access was painfully slow compared to SQL tables.
Depending on the 64 bit application, you may be able to automate from 32 bit Access. One example is Solidworks' EPDM.
PS: My 1st attempt was to attached the MDB using Linked Servers in SQL server, but access was painfully slow compared to SQL tables.
Garry Perkins
May 24, 2023, 10:51:20 AM5/24/23
to
How about today in 2023? I remember 32-bit Access, but it has been a decade since I have used it (at least). Furthermore, I mostly used Access as an interface for SQL Server (back then I would call an Access query to a SQL table because I did not know how to pull directly from SQL in Excel, and MS Query did not exist yet1--okay, more than ten years ago).
Now I am working with a standalone Access database. More accurately I would call them a suite of standalone and interconnected Access databases. I am in the process of converting them to something more scaleable and easier to work with, but for now, these are mission critical. The problem is that I cannot open the 32-bit files. I never recall having this issue, but I have not used Access since the Ribbon was implemented.
How can I access these 32-bit Access databases? I have no need to convert them to Access (although I do plan to convert them to SQL, at least the backend data).
Thank you,
Garry
Now I am working with a standalone Access database. More accurately I would call them a suite of standalone and interconnected Access databases. I am in the process of converting them to something more scaleable and easier to work with, but for now, these are mission critical. The problem is that I cannot open the 32-bit files. I never recall having this issue, but I have not used Access since the Ribbon was implemented.
How can I access these 32-bit Access databases? I have no need to convert them to Access (although I do plan to convert them to SQL, at least the backend data).
Thank you,
Garry
Philip Herlihy
May 25, 2023, 6:49:00 AM5/25/23
to
In article <88ed41a5-55f2-4d5c...@googlegroups.com>, Garry
Perkins wrote...
I was wary of opening my 32-bit Access-2013 database files in 64-bit Access
365, but they opened, and operated, without any hitch at all. All
relationships, macros, and SQL within form property pages were intact. I'm now
using 32 and 64 versions on the same files via OneDrive, simply depending on
which machine I'm on. So that's one option - although no-one could guarantee
there wouldn't be some glitches arising from a custom-built database. But
that's what mine were.
If I had to pick up and use data from an Access database I'd want to open it in
access in order to study how it's structured and implemented, and only then
would I feel I knew enough to migrate the data to another platform.
If you just want the tables, you can import them into Excel. Open Excel; Data
tab; "Get External Data" group, and "From Access". Navigate to the file, and
Excel will open it, and offer you choices, including raw table data, and Pivot
Tables (though I'm not sure quite what would be involved in the latter). Excel
has increasingly powerful data import and manipulation facilities, including
Power Query (which recently solved in 2 minutes a problem expected to take many
hours). I would say, though, that Access is a much safer place than Excel to
hold and process data which has any structure to it, and it's a powerful and
rather beautiful application in my view.
--
Phil, London
Perkins wrote...
365, but they opened, and operated, without any hitch at all. All
relationships, macros, and SQL within form property pages were intact. I'm now
using 32 and 64 versions on the same files via OneDrive, simply depending on
which machine I'm on. So that's one option - although no-one could guarantee
there wouldn't be some glitches arising from a custom-built database. But
that's what mine were.
If I had to pick up and use data from an Access database I'd want to open it in
access in order to study how it's structured and implemented, and only then
would I feel I knew enough to migrate the data to another platform.
If you just want the tables, you can import them into Excel. Open Excel; Data
tab; "Get External Data" group, and "From Access". Navigate to the file, and
Excel will open it, and offer you choices, including raw table data, and Pivot
Tables (though I'm not sure quite what would be involved in the latter). Excel
has increasingly powerful data import and manipulation facilities, including
Power Query (which recently solved in 2 minutes a problem expected to take many
hours). I would say, though, that Access is a much safer place than Excel to
hold and process data which has any structure to it, and it's a powerful and
rather beautiful application in my view.
--
Phil, London
Ron Paii
May 25, 2023, 8:05:21 AM5/25/23
to
If you can't open it, start a new database and import all objects. The new db can be mdb or accdb. It should compile fine except for any define statements, which will need to be modified for x64.
James
May 25, 2023, 9:09:26 AM5/25/23
to
I just converted an Access app I built 10 years ago from 32 bit to 64. Mainly because our default installation base is 64 bit Office across the Enterprise, plus as Albert mentioned, time does march on and I did not want to hang on to older technology that is clearly being replaced. Plus, that app is conflicting with other 64-bit apps that we depend on. 10 years ago, 32 bit was definitely the standard in Office deployments; now, not so much. More and more software is being developed as 64-bit, so I spent some time converting my Access app from Access 2013 32-bit to Access 365 64-bit. It's more of an automated application instead of one being used interactively, so the transition was not that painful. Plus, we have other apps on the same machine that are 64-bit, and which use Office-based ODBC drivers, and you cannot have the same driver in both 32- and 64 bit on the same machine. I'm currently testing out my converted Access app (again, which runs in unattended automation all day) and so far the results have been good. Again, to Albert's point - if you have 32-bit dependencies, then you're kinda stuck unless you're somehow able to remove that dependency.
James
James
Ron Paii
May 25, 2023, 2:38:40 PM5/25/23
to
On Thursday, May 25, 2023 at 8:09:26 AM UTC-5, James wrote:
> I just converted an Access app I built 10 years ago from 32 bit to 64. Mainly because our default installation base is 64 bit Office across the Enterprise, plus as Albert mentioned, time does march on and I did not want to hang on to older technology that is clearly being replaced. Plus, that app is conflicting with other 64-bit apps that we depend on. 10 years ago, 32 bit was definitely the standard in Office deployments; now, not so much. More and more software is being developed as 64-bit, so I spent some time converting my Access app from Access 2013 32-bit to Access 365 64-bit. It's more of an automated application instead of one being used interactively, so the transition was not that painful. Plus, we have other apps on the same machine that are 64-bit, and which use Office-based ODBC drivers, and you cannot have the same driver in both 32- and 64 bit on the same machine. I'm currently testing out my converted Access app (again, which runs in unattended automation all day) and so far the results have been good. Again, to Albert's point - if you have 32-bit dependencies, then you're kinda stuck unless you're somehow able to remove that dependency.
>
> James
Albert's 2017 post
> I just converted an Access app I built 10 years ago from 32 bit to 64. Mainly because our default installation base is 64 bit Office across the Enterprise, plus as Albert mentioned, time does march on and I did not want to hang on to older technology that is clearly being replaced. Plus, that app is conflicting with other 64-bit apps that we depend on. 10 years ago, 32 bit was definitely the standard in Office deployments; now, not so much. More and more software is being developed as 64-bit, so I spent some time converting my Access app from Access 2013 32-bit to Access 365 64-bit. It's more of an automated application instead of one being used interactively, so the transition was not that painful. Plus, we have other apps on the same machine that are 64-bit, and which use Office-based ODBC drivers, and you cannot have the same driver in both 32- and 64 bit on the same machine. I'm currently testing out my converted Access app (again, which runs in unattended automation all day) and so far the results have been good. Again, to Albert's point - if you have 32-bit dependencies, then you're kinda stuck unless you're somehow able to remove that dependency.
>
> James
"There not an x64 bit version of the TreeView or the Calendar control – so once again before committing to upgrade access x32 to x64, then any ActiveX control used will have to be replaced with an x64 bit version. If such controls are not available (and they often are not), then moving to x64 would be a challenge."
Is out of date. Microsoft has a 64bit version of common controls (MSCOMCTL.OCX) for Windows 10. My forms using the TreeView control recompiled in 64 bit access with no changes. Using conditional compile I now maintain x32 and x64 bit versions of Access frontends only needing re-compile.
Philip Herlihy
May 26, 2023, 7:35:38 AM5/26/23
to
In article <MPG.3ed94ce1...@news.eternal-september.org>, Philip
Herlihy wrote...
Worth adding I don't have any experience of SQL server, and it seems likely
that there would be facilities to import from Access there as well.
--
Phil, London
Herlihy wrote...
that there would be facilities to import from Access there as well.
--
Phil, London
Ron Paii
May 26, 2023, 8:38:49 AM5/26/23
to
ABGLaura
May 31, 2023, 4:56:25 PM5/31/23
to
I'm doing it now. I had to change all the Declare Function to Declare PtrSafe Function. I'm having another problem with trying to get the file explorer dialog to open but otherwise, it's been ok.
Ulrich Möller
May 31, 2023, 5:34:20 PM5/31/23
to
Hi Laura,
Am 31.05.2023 um 22:56 schrieb ABGLaura:
>
> I'm doing it now. I had to change all the Declare Function to Declare PtrSafe Function. I'm having another problem with trying to get the file explorer dialog to open but otherwise, it's been ok.
using the ptrsafe keyword alone does not automatically make your API
declarations 64bit ready. The data structures and length specifications
must also be modified.
Look for a Win32API_PtrSafe.TXT file from MS. Many common 32/64bit API
declarations are documented in this file.
Greetings
Ulrich
Am 31.05.2023 um 22:56 schrieb ABGLaura:
>
> I'm doing it now. I had to change all the Declare Function to Declare PtrSafe Function. I'm having another problem with trying to get the file explorer dialog to open but otherwise, it's been ok.
declarations 64bit ready. The data structures and length specifications
must also be modified.
Look for a Win32API_PtrSafe.TXT file from MS. Many common 32/64bit API
declarations are documented in this file.
Greetings
Ulrich
0 new messages