View latest reply
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 next step was to see if it just needed to be re-registered, so I ran this:
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?
Wow that's a lot of work. Normally I suggest that you run work station setup, run MAS once and then use Windows Explorer and delete the MAS90 folder on the workstation and any desktop icon.
I sure understand that, after my detective work on this yesterday, for sure!
I do have one question, however. One of the pressing reasons for me to figure this out, but which I did not include in my post, was that the company CFO needs to retain access to the old server via his existing v4.0 workstation because it contains several old companies which they did not want to migrate to v4.5 on the new (terminal) server at this point (maybe later). It will not be in conflict with v4.5 on the terminal server, but how would I go about installing 4.5 on his workstation, as you suggest, so he can get just the ODBC driver (which is all he needs of v4.5 on his workstation)? Would that not conflict with the existing 4.0?
It comes down to this: he needs both his existing 4.0 workstation as well as the 4.5 ODBC driver on his workstation. Maybe it is a faulty assumption on my part that there would be a conflict if I were to install 4.5 on the same workstation.
Just a bit more explanation on why I went to all the pains to figure out a solution.
Being not a MAS90 specialist, but a systems administrator responsible for the broader picture of ensuring the overall health and orderliness of both servers and workstations, I have often found two things when users remove a program folder manually without a proper uninstallation of the application:
Besides this, I find the message regarding ODBC connections failing IF the registry entries are removed somewhat misleading, since these fail even if one selects "No" at that prompt. That just made me too curious to leave this alone, so will note that about 90% of my original post was the process of getting there.
In the end, the solution was simple: copy two DLLs to System32 and double-click a .reg file to insert a few relevant registry entries. I am just a bit surprised there is no "install just the ODBC driver" option inside the workstation setup process, given how easy it would be to do it, or at least some other post here having the process I discovered through trial-and-error. All is good now, though (I think).
Your issue is that you want to run multiple installs from one desk top. That's really simple. I have 4.05, 4.10, 4.20, 4.30, 4.40 and 4.50 installed on my computer at home and run each as I need them with no issue. If he can get to the old install they just do the work station install for v.450 and give it a different name so you have two icons on your desktop and your fine.
Thank you. As I indicated, I am not a MAS90 specialist, so I am not used to programs that will allow multiple versions. Most applications I support either upgrade prior versions or conflict with them when installed.
Still, determining the actual requirements of the standalon ODBC driver was a good exercies for me--and I am just geeky enough to actually enjoy the process of figuring out registry entries, etc.
Return to Top