Managing 32 bit vs 64 bit References at Startup

Topic

New Reply

The need to determine whether a user is on a 32 bit or 64 bit processor has just come up. What’s a reliable way to determine this at startup, e.g. test an Enviornment variable like CommonProgramFiles for “(x64)” or use some API call? I then need to ensure several references are correct. I thought I’d simply replace the specifc ones (Remove & AddFromFile). Appreciate any insight on a good way to accomplish this.

Thanks,
Marty

Reply | Quote

Replies

Hi Marty,

Wouldn’t it be better to use late binding (no checked reference required) instead of early binding (requires checked references)? I typically develope code using early binding, so that I get the benefit of Intellisense. After the code is debugged, I convert to using late binding. Although I’ve never done any work in 64-bit environments, I suspect that late binding would be useful here as well. There are methods available to use conditional branching in VBA code, depending on 32-bit vs. 64-bit. Try searching the Access Blog at Microsoft–I’m pretty sure they have posted on this topic.

Tom Wickerath
Microsoft Access MVP
2006 – 2011

Reply | Quote

In addition to Tom’s suggestion, one way to tell whether you are running on a 64-bit system is to check for the existance of the “Program Files (x86)” folder – though if someone has a weirdly configured system where C: is not the system disk it can get interesting. The more challenging bit is determining whether you are running Office 32-bit or Office 64-bit. The concensus at this point is unless you need the really huge spreadsheet capability of Excel 64-bit, you want to avoid Office 64-bit. If you are truly stuck with having to use both versions, this MSDN article has lots of detailed information on programming issues.

Reply | Quote

Thanks for the input, Ill check the MSDN article out. Tom, regarding late binding of the references, are you refering to an approach where the db is compiled with out them and, upon the FE’s starup, the references arae set? I tried doing this, but can’t create the compiled FE. I keep getting the message:

This error is usually associated with compiling a large database into an MDE file. Because of the method used to compile the database, a considerable number of TableID references are created for each table. The Access database engine can only create a maximum of 2048 open TableIDs at one time. Exporting a database as an MDE potentially can exceed this limit if the database has a large number of objects (table, macro, form, report, etc).

There is no accurate method to estimate the number of TableIDs the Access database engine uses during the process of compiling a database as an MDE. However, each VBA module and each form uses one TableID, as a result, if the database has 500 forms, and each form’s HasModule property is set to Yes, as many as 1,000 TableIDs are used.

If I leave the references in, I have no problem compiling the FE. I must not be doing something correctly.

Marty

Reply | Quote

Hi Marty,

> Tom, regarding late binding of the references, are you refering to an approach where the db is compiled with out them…

Yes. However, if your code has not been converted to use late binding, and there is a dependency on a checked reference, then any attempt to compile the code will fail.

Note: If you can remove a reference, and your code compiles okay, then you did not need that reference, period. It is ALWAYS best to starve the references listing. In other words, do not allow a reference to remain checked unless it is absolutely necessary for your code to compile.

> …and, upon the FE’s starup, the references are set?

No. Late bound code does not require that any references be set. Here is a sample file that you are welcome to download from my web site, which uses late bound (no reference required) code to automate Excel:

Automation with Late Binding (Calling Excel’s NormInv function)
http://www.accessmvp.com/TWickerath/downloads/Statistics.zip

Tom Wickerath
Microsoft Access MVP
2006 – 2011

Reply | Quote