|30 May 2012||#1|
| || |
Background: We run this program at work called "Surgisource", it is a medical billing program of sorts. Most of our computers here run Windows XP 32bit and the software runs without fail. We have aproximately 10 Windows 7 machines of which only a few are running Surgisource. Of these few only 2 are x64. Of these 2, Surgisource runs perfectly fine on one, and has issues on the other. Since in all likelihood no one will understand the nature of the software discussed here I will speak in generalities; one user is trying to generate reports and gets a "534" error on 2 of these specific reports when she adjusts the date renge beyond one month. I called Surgisource and they don't support x64 (the software is x32) but they seemed absolutely certain that the error had to do with the ODBC configuration. I am fully aware that there is a 32bit ODBC config utility which is what I used.
Now for my question: Does the ODBC config "embed" itself somewhere on Windows 7 outside of the actual config utility? Like somewhere in the registry, or in an .ini file?
At this point I suspect the problem has something to do with the ODBC config not correcting itself (upon being altered via the utility) at the location/file where the actual ODBC info is written. Here is my evidence:
In order for this software to work you have to have the ODBC configured because the data source is located on a server and by default the software does not know where this is. It is critical and the program simply will not run without this configuration. This brings us to Windows 7 x64.
I did the initial ODBC configuration through the x32 config utility located in System32 and the program ran like it was supposed to. As I looked further there was one option that I didn't set correctly; Use ANSI nulls, paddings and warnings must be unchecked for the program to work completely. You will be able to log in otherwise, and access most of the program, but the errors reported by this user are indicative of this option not being unchecked.
My Windows XP x32 had the same problem and when I unchecked the Use ANSI nulls, paddings and warnings, the prgram begun to function completely and there were no more issues. However, when I did the same for the Windows 7 x64 machine, it still had the same issues. After much thought, I went ahead and deleted the entire ODBC entry and the program still ran! This tells me that the software is looking somewhere else for the ODBC settings, possibly the initial settings, and anything done thereafter was not accounted for and thus the software continued to malfunction.
Does this make any sense? Again, this program can not run without the ODBC configured so if I delete the entry it should fail at the point of logging in.
I made the changes with admin rights.
Tried running software in compatibility mode.
Tried running program as admin.
I did a reinstall of the surgisource program.
Any Windows 7 x64 ODBC experts able to shed some light on this? Thanks!
|My System Specs|
|30 May 2012||#2|
| || |
Man, I loathe wrestling with ODBC sources (hello IBM DB2). You say one of the x64 machines runs fine, while the problem is only present on the other one?
You could root arount the registry and compare their settings to see if there's any difference. Apply standard registry editing precautions here (make backups, don't touch anything you don't understand, etc).
Main system DSN info should be in HKLM\Software\Wow6432Node\ODBC\ODBC.INI
ODBC driver info should be in HKLM\Software\Wow6432Node\ODBC\ODBCINST.INI
Some 32-bit driver info may be in HKLM\Software\ODBC\ODBCINST.INI
User DSN info should be in HKCU\Software\ODBC\ODBC.INI
You could also fire up Process Monitor (a free download app now owned by Microsoft) and check the registry access records for C:\Windows\SysWOW64\odbcad32.exe (the ODBC Data Source Administrator), to find out what registry keys to search for DSN info. This is something of a last resort though, the info you need should be in the keys above.
Compare the settings in the working installation with the settings in the one where it's not working and see.
|My System Specs|
|Our Sites ||Site Links ||About Us ||Find Us |
Windows 7 Forums is an independent web site and has not been authorized, sponsored, or otherwise approved by Microsoft Corporation. "Windows 7" and related materials are trademarks of Microsoft Corp.
© Designer Media Ltd
All times are GMT -5. The time now is 03:59 AM.