All Things WinBatch > WinBatch

Under the comes back to haunt you category

(1/2) > >>

stanl:
I developed multiple scripts around 10 years ago, all that used ACE Provider 12.0 for ADO connections. Some users have written saying they just upgraded to Office 365 or Office 2016 which register ACE 16.0 [or 14.0 in some instances]. So I wanted to write a function to determine if 32-bit ACE 12.0 was installed, or a 64-bit version. They are not supposed to coexist, and there is a work-around but it is a lot of work and not guaranteed.


Long story short: Haven't used WB registry functions in a while but RegExistKey(handle, subkey-string [,view-flag]) seems to be the ticket.

* 32-bit:  look for HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Office\12.0\Access Connectivity Engine\Engines\ACE
* 64-bit:  look for HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\16.0\Access Connectivity Engine\Engines\ACEbut then in the notes there is this: using the 32 or 64 values cause these functions to error if a function's subkey parameter contains the string 'wow6432node'


I understand a user could have a 64-bit OS but still have 32-bit Office, and/or WB can compile a 64-bit script.


What is the best way to come up with a function to determine ACE provider, then adjust an existing script to run successfully with the correct ACE Provider?

td:
Use the View flag and call the function twice...

stanl:

--- Quote from: td on May 17, 2023, 06:04:14 am ---Use the View flag and call the function twice...

--- End quote ---


So by "twice' you would recommend

* call with the 32-bit flag for ACE 12.0
* If not there... call with the 64-bit flag for ACE.14 or ACE 16.0like...



--- Code: --- ace = "12.0" ;to be replace in ADO Provider string if present
 If Call32() = ""
else
    ace = "16.0"
     Call64()
endif
Return ace





--- End code ---

td:
Not what I mean. If you need to determine if the target driver is present on the system, you need to check both views by calling the function twice with the same key.  If you find only one target, you would likely need a script compiled to the bitness of the driver present. That said MSFT seems to be providing both versions of some of their COM-related drivers in more recent releases. That may be due to the fact that some dotNet classes are nothing more than covers for underlying COM-based functionality. But I think the ACE ODBC stuff cannot be installed as both 32-bit and 64-bit. I have a vague notion that there is or was a sneaky workaround for this but I don't recall what it was. It may be a false memory or something.

32-bit registry redirection for 32-bit apps has been around since VISTA (2007) so it is not something new. It has been well documented but most of the forum discussions concerning it are buried in the deep past by now.

Note that if one registry key can be used with both 32-bit and 64-bit you don't need to worry about it. Just call into the registry with the default view. 

stanl:

--- Quote from: td on May 17, 2023, 01:51:24 pm --- But I think the ACE ODBC stuff cannot be installed as both 32-bit and 64-bit. I have a vague notion that there is or was a sneaky workaround for this but I don't recall what it was. It may be a false memory or something.


--- End quote ---


I remember posting something about that here. Assume you have the ACE Provider for 64. You can download the AccessDatabaseEngine.exe 2010; call it from the command line with /QUIET parameter. Was supposed to install the ACE 12.0 32bit Provider.

Navigation

[0] Message Index

[#] Next page