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
> 32 Bit Accde On 64bit Access, Access 2016    
post Feb 10 2017, 01:09 PM

Posts: 97
Joined: 3-February 03

I've done a bunch of research, and I sort of understand the issue regarding pointers and long integers, etc. Here's my problem:

I have one client who against my advice ( and MS advice) recommends that his employees install 64 bit office to get the "max" out of Office. Meanwhile myself and all of my other clients continue to be using 32 bit Office based on MS recommendation to do so. I have built this 64 bit client a fairly sophisticated application with a ton of code, which I protect by delivering them an accde. My client would like to be able to run the app on his 64 bit machine with 64 bit Access, but because it is an accde he gets the message that he can't run a 32 bit Access application in 64 bit Access. Does the new Office 2016 have a new way to deal with this non-backward compatibility issue?

Among other things, my client is concerned about longevity of the 32 bit technology. Has anyone found some sort of workaround that works, even as an accde?

I'd love to hear a solution if there is one.

Go to the top of the page
post Feb 10 2017, 01:30 PM

Access Wiki and Forums Moderator
Posts: 73,951
Joined: 19-June 07
From: SunnySandyEggo

Hi Sup,

Unfortunately, to run a ACCDE on a 64-bit Access machine, you'll have to create the ACCDE using a 64-bit Access also. The current workaround is to use a ACCDB.

Just my 2 cents...
Go to the top of the page
post Feb 10 2017, 01:31 PM

Utterly Crispy UA Forum Administrator
Posts: 8,793
Joined: 29-September 01
From: Edmonton,Alberta,Canada

The accde you created was on a 32 bit version and it will have to created with a 64 bit version. If all your api declarations have been updated to 64 bit then the only way I can see you doing this is if you trust your client send them the accdb and have them create the accde and it should then work for them.
Go to the top of the page
post Feb 10 2017, 06:46 PM

UtterAccess VIP
Posts: 2,705
Joined: 12-April 07
From: Edmonton, Alberta Canada

You simply have to setup a test computer or virtual machine that is running Access x64. You can then compile the accde on that x64 bit version of office/Access and you should be fine.

And backwards compatibility in our industry is a “rare” thing anyway. You can't run Windows 95 software on windows 3.1

And you can’t running windows 3.1 software on DOS.

And you can’t run windows 98 software on Windows 95. And when developing software for an x32 system, such software cannot be consumed by an x64 bit system unless a compatibility x32 system is installed.

In fact, it quite recommended that you ALWAYS develop your application with the SAME version of Access that the client going to use.

So I would setup a test mule computer, or simply setup a virtual machine on your computer into which you can install Access x64 and then develop/compile your accDB to accDE with the x64 bit version of Access.

Your code should run without changes with the exception if your code uses any windows API calls (declare statements).

So there not been a solution to this issue for the last 30 years of the computer industry – you have to match the bit size of your tools and runtimes to that of the tools you use.

Note that while near ALL windows OS today are x64 bit, they also install an x32 bit layer of code. This layer of code in windows thus allows you to continue and use x32 bit software on that x64 box. (Such code is in the windows “sysWOW” folder – called windows on windows).

So any software written for x64 bits will have to use an x64 bit layer of software to run.

You can certainly develop using Access x32, and at the last minute compile with a x64 bit version of Access, but any issues and features that you have to “change” to work with x64 are far better to be caught and “noticed” as you develop over time as opposed to finding out at the last minute some feature you used does not work and requires changes. There are options in VBA that allow you to develop code that will run on both versions – and in most cases zero VBA code changes are required – the exception being any windows api calls you make.

So there never been some “magic” backwards compatibility system that allows mixing of bit size code. However what was done in the past was usually the “next” version of windows will include a “stack” or compatibility layer to run previous version software.

So for example windows 95, 98 and I think even windows XP included a whole copy of the x16 bit windows 3.1 code. This allowed you to run windows 3.1 code on windows XP. However, windows XP code never did and never could run on windows 3.1

So it is much the same with Access. The code and VBA is “highly” compatible between both versions, but if you going to deploy compiled code, then that code has to match the platform that consumes the code.

You can distribute an accDB since the source code exists – and Access will then re-compile on the fly. With an accDE the source code is stripped out and no automatic re-compile can occur. (this is the same for windows .exe files also – they have to match the software layer available).

You can install say the Access 2013 or 2010 runtime (x32) that can exist with the x64 office 2016 – but if you use any automation of word etc., then that is not supported.

Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
Go to the top of the page
post Feb 13 2017, 09:04 AM

Posts: 97
Joined: 3-February 03

Hi Albert,

Thank you very much for your in depth explanation and advice! I am a "self taught" Access developer that has learned almost everything I know from generous people like you that share their knowledge and expertise on these Access forums. When I am trying to solve issue that is new to me, I often find my answer in one of your posts. I am honored to have received your response, and I thank you for this and all of the other education you have given me over the years.

Go to the top of the page

Custom Search

RSSSearch   Top   Lo-Fi    16th December 2018 - 07:35 PM