Questions re: 32-bit and 64-bit file vs client (1 Viewer)

[PaulA]

Greetings.

I developed and maintain a Access db through 32-bit Office and it is utilized on a 64-bit Office system offsite.

While this has not in itself caused problems (people can access it), I'm wondering:

1. If this would effect the performance of the application (it's a split database with the number of simultaneous users growing since it was first developed).

2. Does the 32-bit status ever change in the 64-bit environment, like if I make a copy of the file in the 64-bit location, or is it always 32-bit unless converted or with the database saved as a whole while in the 64-bit client?

I've read that 32-bit file works in a 64-bit client but not the other way around. Is this correct?

Thanks for your assistance.

 

[The_Doc_Man]

To understand this, you need a SMALL hardware lesson. Intel machines started from an 4-bit environment (the Intel 4004 chip) as a local controller chipset for things like automated washing machines and the like. Programming wasn't so much of a deal. Then came the influx of better miniaturization and the 8 bit (Intel 8008) came out. Then the idea of 16-bit addresses and the Intel 8080 and later, the 8086.

At some point, as miniaturization improved, addresses grew to 32-bit, many years ago. The Intel 80486 and the Pentium (should have been the 80586 - but wasn't) marked the transition to larger and larger memory models. This was also the time when the operating system was switching from MS-DOS to Windows as a layer, followed by Windows as the O/S and DOS as the add-in.

During these transitions, one thing was remarkably constant. Other than the 4004 to 8008 transition, EVERY change in address size and data element size (to match the address size) was matched by an expansion of the instruction set for data sizes of the earlier machines. Therefore, a 486 could run the instructions of the 086. This feature was called BACKWARDS COMPATIBILITY. It has been a goal of Intel and Microsoft to, as much as possible, maintain this compatibility.

With the advent of 64-bit addressing, the SAME THING has happened. The IA64 and related chips can still execute the 32-bit instructions. So it is easy for a program (such as Access/32) to run on a 64-bit machine. All the instructions are there. And Microsoft doesn't make a big thing of it, but a lot of THEIR utilities for 32-bit systems are used unchanged on the 64-bit systems as well. I guess they didn't want to re-invent the wheel yet again.

In your Task Manager, you will see something called SVCHOST, which is the name for a "capsule" in which those 32-bit programs have a comfortable 32-bit environment. Those programs that run under SVCHOST "think" they are on a 32-bit machine and don't know any better. Nor do they know the right questions to ask. (Because if they DID, they would be able to run in 64-bit mode anyway.)

Unfortunately, on the older 32-bit machines, the 64-bit instructions don't exist. So a newer utility such as Access/64 cannot run. Some of the required instructions aren't there and the longer data sizes are not covered by the instructions. SVCHOST won't help because it doesn't support that address size either.

Therefore it is correct to say that a 32-bit app runs in a 64-bit environment, probably in the context of the SVCHOST "encapsulating" utility that provides a shell for execution. But a 64-bit app will not run in a 32-bit-only environment.

To answer your other questions:

1. (Performance effects): IF the 64-bit Office system offsite is running your 32-bit app, see my explanation. The performance will be minimally affected by SVCHOST interactions. It is quite efficient. Kind of HAS to be good because Microsoft uses it for their utilities.

2. (Change nature of app from 32 bit to 64 bit): The status of the app does not change regardless of where you port it. That status will always be the status of the version of Access on which it was developed.

To be brutally honest, we haven't seen many good effects (like higher size limitations) for the Access/64 native implementations. It's one man's opinion and I know why they don't do it, but I doubt MS will EVER do anything to upgrade the capabilities of Access/64 when compared to what they did for Excel/64 - which DID grow in capacity. By a LOT!

The ONLY way to upgrade a 32-bit Access DB to a 64-bit Access DB is to find a machine with Access/64, create a new blank database, and then FROM THE 64-bit Access environment, import the tables from the 32-bit version. (And the other structures!) But that is not generally recommended.

 

[CJ_London]

a .accdb will work in either environment, subject to some changes to library calls - primarily the use of ptrSafe and changing long to longptr where required. There is plenty of information available on this on the web

a .accde however will only work in the environment it was created in.

a backend should not be affected since these will be .accdb's although I don't know if there would be an impact on data macros - I doubt it since they are limited and not compiled.

a 32 bit file is a 32 bit file, a copy will still be 32 bit.

64 bit apps are no faster than 32 bit apps (speed is more a function of disk/network performance), however there is some 32bit functionality (primarily some activeX controls) which either have not been replicated in 64bit or have an equivalent but are called in a different way. If your client is running your app OK, then doesn't sound like you have used any of these.

 

[PaulA]

A very thorough and informative response.

Thanks.

 

[PaulA]

Thanks, CJ - especially regarding performance. This is not a compiled application so we are using accdb files for front and back ends.

These answers will be good references for others - I did an initial search and didn't find anything.

 

[Pat Hartman]

There were changes in the API when using 64-bit Office. If you are not using any API calls from VBA, you won't run into a problem with running your 32-bit app with 64-bit Office.

As has been mentioned, "bitness" is dependent on hardware and refers to the size of registers in the OS that are used as pointers to address locations. The larger bit-sizes can access larger disk drives, monitors, and memory spaces. If your register is only four digits, you can address 9999 specific locations. But if it can hold 8 digits, it can address 99999999 (this is simply an analogy for simplicity. Computers work in base 2 NOT base 10) Since Excel loads the entire spreadsheet into memory, unlike a relational database such as Access which does not, moving to 64 bit allowed users to create even more humongous spreadsheets that probably should have been database applications rather than spreadsheets anyway. Just because you can now load a million rows in your spreadsheet doesn't mean it will be fast or that your vLookups will run in less than three hours. I spent a year weaning analysts off of Excel and into Access for their preprocessing and the thing that was most compelling to them was that a query in Access that performs a join which is the equivalent of a vLookup could run in under a minute whereas their Excel process took over three hours to do the same thing.

Our hardware has been 64-bit for many years now and so has our operating systems. There is nothing inherently better about 64-bit than 32-bit (except the ability to address larger devices) and in fact, moving to 64-bit Office caused all the 32-bit addins to cease to work and so for many years, MS has suggested that everyone install 32-bit Office rather than 64-bit unless they had some pressing need for stupidly large spreadsheets.

 

[The_Doc_Man]

The ONE good thing that happened when 64-bit machines came around is that newer versions of Access (even 32-bit versions) added the QUAD integer data type. There was also the advent of the 64-bit address which is a blessing and a curse for 32-bit apps because of interfacing complexity. Other than that, nobody I know has seen much of a big benefit of having a 64-bit system for Access apps. If you aren't running something that requires 64-bit (like SharePoint, I believe, as an example), you can live on 32-bit Access with no new problems.

 

[Pat Hartman]

EXCEPT that you can't mix and match 32 and 64 bit components of Office of the same version. It is all or nothing since the various programs share libraries. Plus, if you want Access to automate other Office components, all the components must be the same bitness.

 

[CJ_London]

I have the issue with some clients that a few users need 64 bit office for Excel (and they are real power users) but most don't. I provide two versions of the .accde front ends, one 64 bit, one 32bit and leave the client with instructions to install whichever version they require initially for new users. After that auto update takes over.

I've not had any real use for 64bit Excel personally, but anecdotally from clients the only benefit seems to be increased volume of data - a file with just less than 1m rows (so will open in 32bit) is slow compared with Access. It seems to be no faster if opened in 64bit excel.

 

[The_Doc_Man]

CJ, the SPEED difference isn't there because modern machines still use about the same speed for memories. It is not generally discussed, but the memories that plop into the little memory slots in your system are all byte-oriented. It is the "memory fetch" circuitry that takes bigger or smaller gulps in a single operation or at least that is how it appears to YOU. You wouldn't see the internal extra cycles caused by memory boundary misalignments anyway.

The system clocks are still running at a rate of approximately 3.2 to 3.8 GHz (depending on internal bus specifications). The memories have approximately the same cycle speeds; i.e. a PC3200 DDR SDRAM runs at 3200 MB/s or 3.2 GB/s. The internal system memory caches at the various levels (L1, L2, L3) are fast and efficient and thus are able to avoid expensive physical memory fetches for popular locations. But it comes down to the same physical memory design for 32-bit vs 64-bit systems. The address registers are twice the size. Memory fetches can be initiated at twice the size. But the circuits behind the scene still take their gulps from chips that are byte-oriented.

Therefore, the speed of the hardware being the same means the speed of the software will rarely be different. Your anecdotal comment that you see little difference in speed between 32-bit and 64-bit Excel is because, as Pat pointed out, Excel pulls everything into memory and at that point, memory speeds take over as the most significant thing you see.

The only other thing you would have to watch out for is that WINDOWS has something to say about this. If you have an insanely large spreadsheet, you have to boost the size of your page/swap file (Virtual Memory file) if you have previously forced it to a fixed size. I recall that the Windows rule is simple: You can't grow the size of your Virtual Memory unless there is room for it in the VM file EVEN if Excel never actually out-swaps.

 

[CJ_London]

that's what I thought