none
Can You Use Access 2019 X64 To Build Access ACCDE That Will Run In Access 2019 X32? RRS feed

  • Question

  • This page: https://support.office.com/en-us/article/choose-between-the-64-bit-or-32-bit-version-of-office-2dee7807-8f95-4d0c-b5fe-6c6f49b8d261?ui=en-US&rs=en-US&ad=US

    Says: "Using the 64-bit version of Office lets you deliver a 64-bit version of those solutions as well as a 32-bit version."

    Does that mean there is a switch in Access 2019 X64 that lets you run it in Access 2019 X32 compatibility mode?


    http://www.saberman.com

    Sunday, January 13, 2019 12:41 PM

All replies

  • Hi saberman,

    I notice that the issue is related to Access product. To better fix the issue, I would move the thread to Access forum for more discussion.

    Thanks for your understanding.


    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact: tnsf@microsoft.com.

    Click here to learn more. Visit the dedicated forum to share, explore and talk to experts about Microsoft Office 2019.

    Monday, January 14, 2019 9:02 AM
  • Look over https://www.devhut.net/2017/04/13/access-x32-vs-x64-compatibility/ it should help clarify what compatibility issues exist between 32 and 64 bit versions.

    Daniel Pineault, 2010-2018 Microsoft MVP
    Professional Support: http://www.cardaconsultants.com
    MS Access Tips and Code Samples: http://www.devhut.net

    Monday, January 14, 2019 1:16 PM
  • Thanks for the link but there are a couple of problems with it.  It is almost two years old and refers to Access 2013 not 2019..  It also says that Microsoft recommends using the 32 bit version of office.  That is no longer true -- Microsoft now recommends installing the 64 bit version of office on machines running Windows X64.

    So if you install Access 2019 X64 can you maintain compatibility with Access 2019 X32?


    http://www.saberman.com

    Monday, January 14, 2019 3:24 PM
  • Hi,

    If you're talking about compiling (building) a database to a ACCDE, then I believe you'll have to use the same bitness to compile the file as the one users will use to open/run it.

    Monday, January 14, 2019 4:42 PM
  • >>So if you install Access 2019 X64 can you maintain compatibility with Access 2019 X32?

    yes you can. However you can also break that compatibility also!

    So either version of office does allow you to produce files and applications that work with EITHER versions.

    However, while the above is 100% true, if you use an accDE, then such files are not compatible.

    And same goes for Excel. So while BOTH versions are happy to produce files useable by both versions, some exceptions exist, and that article does not outline those exceptions.

    It certainly goes into “COM” issues, but the scope of the article is limited, else it would be “very” long indeed.

    So I don’t see in above any mention that Excel “can” produce files that are NOT consumable by x32. (But it can).

    And same applies to power-point.

    And also to word too!

    And also to Access.

    So the files produced can be opened by either version, but power-point, and Excel, likely word, and Access all likely can ALSO produce files that are NOT consumable by the x32 edition.

    So the “many” exceptions to the compatibility are not outlined.

    To be fair, the article you link to do list out the reasons for NOT jumping to x64, and also has reasons to stay with x32.

    And I suppose they could have addressed using VSTO also! (Visual studio tools for office).

    So, the scope of the article is limited.

    From a software developer point of view, no question some issues of bit size will come up – and that applies to .net developers, and that of access developers. I think that developers are not the scope nor the target of that article.

    I assume MUCH higher levels of knowledge from developers anyway – and that article also assumes this.

    In fact, delving into x32 vs x64 from a developer’s point of view is so very much beyond the scope of that article. And to be fair, that article does mention “COM”.

    I don’t have a “list” of which office applications such as Excel, Word or even Access that “can” produce files that are NOT compatible with x32 version. However, no question that office x64 can produce files that are not compatible, but for the most part they are.

    So office x64 “can” produce files that are compatible with x32, but that does not mean “all” files are.

    quote:

    It also says that Microsoft recommends using the 32 bit version of office.  That is no longer true -- Microsoft now recommends installing the 64 bit version of office on machines running Windows X64.

    Where did you see this? I accept that this day will occur, but I did not realize that day had arrived?

    If Microsoft recommends x64 bit version, then why do the defaults remain x32 for all office installs then?

    So accDE files HAVE to match the office bit size to be consumed.

    You can STILL have one code base for that applcation, but you do have to compile to the target bit size for office.

    Keep in mind that EVEN the runtime does “compile on the fly” of code. So if bit size changes, then access (including runtime) will re-compile the VBA.

    However, with accDE, the source code is gone, and no recompile can occur.

    So you "can" keep compatibility here, but you can also break it too! And this breaking is not limited to just Access.

    However, I was not aware that Microsoft is recommending the x64 bit version of office now – do you have a link that suggests this?

    That is a “big” issue. And yes, I do accept that day will come – but was not aware it “has” arrived!

    Regards,

    Albert D. Kallal (Access MVP, 2003-2017)

    Edmonton, Alberta Canada

    Monday, January 14, 2019 7:01 PM
  • >However, while the above is 100% true, if you use an accDE, then such files are not compatible.
    IOW, The 64 bit version cannot compile an application into a 32 bit compatible version (accde) even if the accdb file is compatible.  

    >You can STILL have one code base for that applcation, but you do have to compile to the target bit size for office.
    Confused.  Can the 64 bit version create an accde that can be used by the 32 bit version?

    >Keep in mind that EVEN the runtime does “compile on the fly” of code. So if bit size changes, then access (including runtime) will re-compile the VBA.
    A compiled accde does not have the VBA code in it.

    >Where did you see this? I accept that this day will occur, but I did not realize that day had arrived?
    https://docs.microsoft.com/en-us/DeployOffice/office2019/overview
    Toward the bottom of the page:
    "All products in the Office 2019 are available in both 32-bit and 64-bit versions. We recommend 64-bit on computers that have 4 gb or more of memory. But you should assess application compatibility and other factors that might require you to use the 32-bit version. For more information, see Choose between the 64-bit or 32-bit version of Office."


    http://www.saberman.com

    Monday, January 14, 2019 8:39 PM
  • >Confused.  Can the 64 bit version create an accde that can be used by the 32 bit version?

    No, it cannot. As I pointed out, office x64 is able to create all kinds of files ranging from power-point, Excel, word (and access too!) that are not compatible with office x32.

    So while office x64 can most certainly produce files that are fine with x32, it also able to produce files that are not. If you need 100% compatibility between the two versions (bit size), then you have to avoid x64 bit features. As I stated, they are not limited to just access.

    >>We recommend 64-bit on computers

    Fair enough!

    As I stated, this day will arrive! I think the “real” change will be complete when the default office install (even from office 365) is defaulted to x64.

    So the “transition” has started. Many documents (in fact 8+ years’ worth documents, recommends, and “good” practices) STILL recommend x32, but the “change” is starting to occur.

    This “change” is certainly going to be a challenge for office users, but for Access I think the issue is even more of a challenge.

    So to be clear:

    Office x64 (Excel, word, etc. and Access) can produce files that don’t work with x32.

    While you can maintain one single code base for your access application that will work with x32/x64, you WILL require to compile the accDE to the correct bit size. If you use a accDB, then this x32/x64 issue does not apply (assuming you made the application compatible with both x32/x64. However this VBA code issue applies to even non compiled accDE applications, and also applies to all of the office suite programs (ie:  you can write VBA code that works for both bit sizes, but some effort may well be required to ensure compatibility).

    Edit: So just to be clear? You cannot produce a x64 bit accDE with office x32, and you can't produce a x32 bit accDE with office x64. If you need to support both bit sizes, then you need to run two versions of office. And, that suggests you have to adopt some kind of VMware, or the free Hyper-V included with windows 10.  The reason for this is that office of the same version does NOT support side by side installs of x32 and x64.

    Regards,

    Albert D. Kallal (Access MVP, 2003-2017)

    Edmonton, Alberta Canada




    Monday, January 14, 2019 9:11 PM
  • >Edit: So just to be clear? You cannot produce a x64 bit accDE with office x32, and you can't produce a x32 bit accDE with office x64. If you need to support both bit sizes, then you need to run two versions of office.
    That should kill the migration to Access X64 for most shops.  It will certainly stop anyone developing shrink-wrapped Access based products from using Access X64 for development. 


    http://www.saberman.com

    Tuesday, January 15, 2019 3:49 AM
  • Hum, I have to disagree.

    However, it does introduce "pain". For example, for office 2013, we have 6 versions of access now.

    Access x32   (msi install)

    Access x64  (msi install)

    Access x32 runtime (msi install)

    Access x64 runtime (msi install)

    Access x32 (Click to run - office 365)

    Access x64 (click to run - office 365)

    (and no CTR 2013 runtime was released, but WHEN this occurs, you have EIGHT!!! versions of access for a given version of office).

    And you can NOT mix and match CTR vs msi installs!

    However, it is  not at all hard to setup an installer (say inno) to detect what version of office (x32 or x64), and then install the correct access runtime (again correct x32 or x64 has to be installed). And then the correct accDE front end to match. I had such code in my inno installer for at least 5 years now.

    However, I don't have code to deal with the CTR version.

    The simple matter is if customers start moving to office x64 bits, then your Access x32 application will not be able to automate say outlook for email, and you can’t automate Excel or word either.

    So “in process” code has to match bit size. That simply means that an x32 bit program (even .net, VB6, FoxPro) cannot “automate” an x64 bit program – including outlook etc.

    This also means that ANY ActiveX components you use in x32 will NOT work in x64 (unless the vendor releases an x64 bit version of that ActiveX control).

    All “in process” software has to run as the same bit size. This is NOT new issue - we went though this in windows 3.1 code to windows 98 (16 bits to x32 bits).

    So, if someone has an Access application, and their customers start adopting office x64? Well, if access is to automate outlook or any of those other office programs, you have to match the bit size. You have to deploy and run x64 access for such a case.

    You also can’t install x32 and x64 bit parts of the SAME version of office. So if someone installs say Excel + outlook 2013 as x64 bits then you cannot install ANY x32 bit program from the office suite (version 2013).

    The reason for this is that ribbon, spell checking, VBA system (and a long list) are ALL shared between all office programs. So the "registered" version of all those bits and parts will be x64 bits.  So the first 2013 program installed (say Excel) will install VBA and all that stuff like Ribbon etc.

    Now, any additional install of a 2013 program will USE the existing office code library. So, bit size must match.

    One can get around the above by say installing access 2010 runtime, but then it will not then be able to automate outlook etc. from 2013 that is x64.

    The x64 bit version of office (and Access) came out in 2010. We now in 2019 – so almost 10 years this issue has existed.

    10 years is a “long time” in our software industry. I mean, go 10 years back from office 2010, and we at office 2000. A typical computer in 2000 had windows 98, lots of 486’s were still around, and computers had 16 megs of ram (not gigs, but megs of ram).

    So keep in mind that 9 years ago, office started shipping x32, and x64 bit versions. I would say ONLY in about this year is Microsoft starting to suggest office x64. 99% of office installs are still x32, even on x64 bit machines.

    However, I do and have encountered companies running office x64 even 5-6 years ago. (they wanted larger excel sheets).

    So we had an x32 and x64 bit version of the access runtime since 2010. And it was in 2010 when the x64 bit version of VBA was introduced. This new version of VBA not only supports “longlong” (x64 bit wide longs), but also has a long pointer type for the windows API. The longPtr type introduced in access 2010 is very useful for calling windows API code, since it is x32 in size for access x32, and x64 bits in size for access x64. This allows one to write (call) windows API code from VBA for either bit size without having two code versions of your VBA.

    So, many of us have been dealing with, and using Access x64 bits for close to 10 years now.

    Regards,

    Albert D. Kallal (Access MVP, 2003-2017)

    Edmonton, Alberta Canada


    Tuesday, January 15, 2019 7:51 AM