Compile Error after migration to Office 365

[bfreescott]

A client of mine is getting a compile error in hidden module after being migrated from Office 2016 to Office 365. There were no changes to the code. Other clients still on the 2016 platform are reporting no issues with the same code. I've checked for missing libraries in the References, but there were none. In the offending module, all procedures have error handling, none are which are triggered. I'm guessing the compile issue precedes any attempt for run-time. Only one reference to a library is made where I build a connection string using Microsoft.ACE.OLEDB.12.0. I don't think the reference is the issue, as that works fine for all other Excel 2016 clients, but I'm wondering about the version of the engine. Do I need to use version 16.0? I'm also wondering if the issue is 32-bit versus 64-bit. Could there be a conflict there?

 

[6StringJazzer]

There is no way to answer this question without seeing the code. Please show the code, give the compile error message, and indicate which line of code causes the error.

Normally there is not an issue in upgrading versions of Excel; it's more common to have backwards compatibility problems. It's possible that 32 vs 64 is an issue but this generally occurs if you are using low-level DLL calls. Hence the request to see your code.

 

[bfreescott]

Just wanted to follow up on this issue in case anyone else has this problem and also to thank 6StringJazzer for replying.

The issue was indeed a 32-bit vs 64-bit problem.

Despite backwards compatibility, if you use ADO, 64-bit Excel will throw a compile error on Long variables.
With ADO on a 64-bit Excel platform, you cannot use Long or even LongLong. You must switch to Variant and allow Excel to allocate the memory space at runtime.

This is true for both 32 and 64 bit Windows.

HTH

 

[6StringJazzer]

This depends on what the variable is. Pointers must be declared as LongPtr. I would steer you away from Variant to solve a problem like this. Normally if code has to be compatible with both, compiler directives are used to select which code to include.

I have used ADO without regard to whether the environment is 32 or 64. I would be very curious to see what code you are using that would give you a compile error on Long variables.

 

[bfreescott]

LongPtr only resolves to either Long or LongLong. I tried all three with no luck. It wasn't until I found an obscure reference to ADO by a developer on S.O. who recommended Variant that the compile error went away.

 

[6StringJazzer]

Well, if it works great. If you don't want to show your code, OK. But it might be helpful to others (like me) who would like to see your solution.

 

[bfreescott]

Well, if it works great. If you don't want to show your code, OK. But it might be helpful to others (like me) who would like to see your solution.

Sorry, I left out one piece of critical info. It's the RecordCount property of the RecordSet object in ADO that dictates that Variant type in 64-bit Excel. I don't know why this is the case; I only know that it was the solution.