A
Andreas Lauffer
I have a very strange problem with a JET-ODBC-Connection.
Using Access97-Runtime, we connect the table with a
DSN-less-ODBC-Connection to SQLServer 2000 SP3.
The Application runs on a Windows Server 2003 Terminal-Server with
CITRIX Metaframe.
Office 2003 is also installed (no Access2003)
And now the problem:
-------------------------------------------------------
When our application is installed anew, the ODBC-Connection works fine.
When I start any Office2003-Application like Winword, the system files
MSJINT35.DLL and MSJTER35.DLL are changed. (I used ashampoo Uninstaller
Suite to check this issue).
Afterwards, our Application doesn't run anymore, the Application quits
without any error.
If I copy the MSJINT35.DLL anew from the install-directory, our
application runs again correctly.
The strange thing is, that the "changed" MSJINT35.DLL is exactly the
same as the original file. Version, Metadata, Language, Filesize, and
even a Hex-based-compare result that the files are identically.
Nevertheless, a copy of the file into system32 is a workaround to fix
the problem for a few hours.
Using Access97-Runtime, we connect the table with a
DSN-less-ODBC-Connection to SQLServer 2000 SP3.
The Application runs on a Windows Server 2003 Terminal-Server with
CITRIX Metaframe.
Office 2003 is also installed (no Access2003)
And now the problem:
-------------------------------------------------------
When our application is installed anew, the ODBC-Connection works fine.
When I start any Office2003-Application like Winword, the system files
MSJINT35.DLL and MSJTER35.DLL are changed. (I used ashampoo Uninstaller
Suite to check this issue).
Afterwards, our Application doesn't run anymore, the Application quits
without any error.
If I copy the MSJINT35.DLL anew from the install-directory, our
application runs again correctly.
The strange thing is, that the "changed" MSJINT35.DLL is exactly the
same as the original file. Version, Metadata, Language, Filesize, and
even a Hex-based-compare result that the files are identically.
Nevertheless, a copy of the file into system32 is a workaround to fix
the problem for a few hours.