Install ODBC driver without workstation setup

I started writing up this question, but  I found what I think is the solution in attempting to document the steps to my original failure. Can someone please let me know if I have this correct? Skip to the bottom if you want to see my solution, because in between here and there are all the steps I was testing--with increasing degrees of success--as the solution (I hope) dawned on me by degrees.

 

 We just moved from MAS90 4 on one server (with workstation clients) to MAS90 4.5 on another server, with all clients now running the new MAS90 via RDP on the terminal server where it is installed. A couple of them now need to access the new MAS90 via ODBC (MS Query in Excel and/or MS Access). We do not want workstation access to MAS90 applications--just the ODBC driver. This is because we do not want phantom copies of old MAS90 workstation installations hanging around after future MAS90 upgrades.

 

 I tried doing the workstation installation, then un-installing, which asks this question:

 

Do you wan the Sage ERP MAS90 registry entries to be deleted? This will cause ODBC connections (such as, Crystal Reports or Visual Postmaster) for all Sage MAS 90 or 200 installations on this computer to fail.

 

This seems to infer that answering "No" will leave the MAS90 ODBC DSNs. I answered "No" and proceeded to complete the un-installation. I then successfully tested the MAS90 DSN and, sure enough, it worked--until I rebooted. Although the MAS90 driver appears on the list of drivers, any attempt to configure the existing MAS90 DSN or add a new one after the reboot is met with this message:

 

The setup routines for the MAS90 4.0 ODBC Driver ODBC driver could not be loaded due to system error code 126: The specified module could not be found. (C:\Windows\system32\PVXODBC.DLL).

 

On the theory that pvxodbc.dll was missing from System32, I reinstalled MAS90, captured a copy of the DLL, un-installed MAS90, and went to re-copy the DLL--but there was already a copy in System32. I could have saved some time by just looking to see if it stayed there in the first place, but either way, it was to no avail, as I received the same message as above:

 

The setup routines for the MAS90 4.0 ODBC Driver ODBC driver could not be loaded due to system error code 126: The specified module could not be found. (C:\Windows\system32\PVXODBC.DLL).

 

The next step was to see if it just needed to be re-registered, so I ran this:

 

regsvr32  C:\Windows\System32\pvxodbc.dll

 

but with this result:

 

The module "C:\Windows]System32\pvxodbc.dll" failed to load. Make sur ethe binary is stored at the specified path or debug it to check for problems with the binary or dependent .DLL files. The specified module could not be found.

 

That sounded awfully familar--very much like all the prior failure messages, but I noticed the reference to possible dependent DLL files, so I reinstalled MAS90 and was rewarded to find, with a bit of guesswork based on file name and date, the accompanying pvxio.dll file. I then un-installed MAS90. This DLL behaved slightly differently from the other one in that, while it remained in place in System32 until reboot, it disappeared upon reboot.

 

But now I had a copy of pvxio.dll  to drop into System32 alongside pvxodbc.dll, and now I had a functioning standalone ODBC driver (i.e. sans the MAS90 workstation installation).

 

But...I was not done yet, as I was hoping to accomplish without having to install & then remove the workstation, so I traced  these two registry keys (, which I exported, then deleted:

 

[HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBCINST.INI\MAS 90 4.0 ODBC Driver]
"Driver"="C:\\Windows\\system32\\PVXODBC.DLL"
"Setup"="C:\\Windows\\system32\\PVXODBC.DLL"
"SQLLevel"="0"
"DriverODBCVer"="03.00"
"APILevel"="1"
"ConnectFunctions"="YYN"
"FileUsage"="1"
"UsageCount"="dword:0000000"

 

[HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBCINST.INI\ODBC Drivers]
"MAS 90 4.0 ODBC Driver"="Installed"

 

This predictably broke my DSN again, but adding it back to the registry again fixed the DSN. Then there was just one more step, based on a hunch--the deletion of the license information under this registry key (with the live informaiton replaced with dummy data, since the live data is our actual serial number):

 

[HKEY_LOCAL_MACHINE\SOFTWARE\Sage Software\ProvideX ODBC Driver]

"Serial"="[Our Serial Number Here"
"Name"="[Name here]"
"Company"="[Company here]"

 

Once again, testing revealed that the DSN required this information at runtime (popped up a dialog box asking for license information). Adding it back to the registry gave me what I think is a fully-functional DSN without a prior workstation installation on the computer. It all comes down to this now:

 

Copy the two DLL files to System32

Compile the contents of three .reg files into a single .reg file, then import it into the registry.

 

Now, this was 32-bit Windows 7, and I know there would be some adjustments for 64-bit Windows 7 and even perhaps for XP, but those can wait. Of course, I also had to enter the DSN configuration information (paths, etc) from a known good configuration to make a usable DSN.

 

I successfully added these two DLL files and the registry entries to the one computer still having a MAS90 client (to our old version, on another server, for reference purposes), first ensuring there were no naming conflicts over overlaps in registry/file names, and I was then successfully able to add a new DSN which can successfully connect to the new MAS90.

 

Did I miss anything, or was there (as likely as not) a simple ODBC installation routine hiding somewhere in the MAS90 folders on the server--or, worse yet, another post in this forum that explains all of this?

Parents Reply Children
No Data