ODBC connection failed to new server after move

[techjohnny]

I'm having trouble establishing an ODBC connection to a Progress database. The connection worked fine before moving the database to a new server. The test connection responds with the warning message:

[DataDirect][ODBC Progress OpenEdge Wire Protocol driver] (then some strange ascii characters.

 

[oli]

Take a look at the registry to see more precisely where are those strange ASCII characters .

For 32bits DSN: HKLM\Software\Wow6432Node\ODBC\ODBC.INI\...
For 64bits DSN: HKLM\Software\ODBC\ODBC.INI\...

 

[techjohnny]

Take a look at the registry to see more precisely where are those strange ASCII characters .

For 32bits DSN: HKLM\Software\Wow6432Node\ODBC\ODBC.INI\...
For 64bits DSN: HKLM\Software\ODBC\ODBC.INI\...

Take a look at the registry to see more precisely where are those strange ASCII characters .

For 32bits DSN: HKLM\Software\Wow6432Node\ODBC\ODBC.INI\...
For 64bits DSN: HKLM\Software\ODBC\ODBC.INI\...

Thanks. Look around the registry on the clients XP 32-bit and the server 2008 64-bit, but nothing is different from the original server in the registry that pertains to those keys.

 

[Rob Fitzpatrick]

The connection worked fine before moving the database to a new server.

So the database moved to a new server. What else changed? Is your DLC version different from the old? What is your DLC version? Did your DB startup parameters change? Can you connect to the DB locally with sqlexp?

Also, it would be helpful to see the actual error message.

 

[techjohnny]

So the database moved to a new server. What else changed? Is your DLC version different from the old? What is your DLC version? Did your DB startup parameters change? Can you connect to the DB locally with sqlexp?

Also, it would be helpful to see the actual error message.

[2/18/14 6:12:54 PM]=== Start logging. Local time: 2/18/14 6:12:54 PM. ===
[2/18/14 6:12:54 PM]
[2/18/14 6:12:54 PM] [3] [SQLExplorer]           Local c:\epicor\oe101b_wrk\SQLExplorer.properties file will be used. (SQLMsg036)
[2/18/14 6:12:54 PM] [3] [SQLExplorer]           Setting Connect to jdbc:datadirect:Openedge://192.168.2.3:8350;databaseName=mfgsys
[2/18/14 6:12:54 PM] [3] [SQLExplorer]           === SQLExplorer starting. ===
[2/18/14 6:12:54 PM] [3] [SQLExplorer]           ### ARGS:    -db mfgsys -S 8350 -user *********  -password  ********* -H 192.168.2.3
[2/18/14 6:12:54 PM] [3] [SQLExplorer]           Connecting user "******" to URL "jdbc:datadirect:Openedge://192.168.2.3:8350;databaseName=mfgsys"... (8920)
[2/18/14 6:12:54 PM] [3] [SQLExplorer]           Loading JDBC driver com.ddtek.jdbc.openedge.OpenEdgeDriver.
[2/18/14 6:12:54 PM] [0] [*UnexpectedError*]   * recorded as exception #3 in file c:\epicor\oe101b_wrk\SQLExplorer.exceptions.
[2/18/14 6:12:54 PM] [3] [SQLExplorer]           === SQLExplorer ending. ===
====== Start exception logging == "c:\epicor\oe101b_wrk\SQLExplorer.exceptions" opened == Tue Feb 18 17:51:19 GMT 2014 ======


**** 2 ****

   Exception at Tue Feb 18 17:51:19 GMT 2014: java.lang.NullPointerException
   Message (throw): ### Connect stack trace. ###
   Message (excp):  null
   Stack Trace:
java.lang.NullPointerException
    at com.ddtek.jdbc.base.BaseConnection.connect(Unknown Source)
    at com.ddtek.jdbc.base.BaseConnection.setupImplConnection(Unknown Source)
    at com.ddtek.jdbc.base.BaseConnection.open(Unknown Source)
    at com.ddtek.jdbc.base.BaseDriver.connect(Unknown Source)
    at java.sql.DriverManager.getConnection(DriverManager.java:512)
    at java.sql.DriverManager.getConnection(DriverManager.java:171)
    at com.progress.sql.explorer.SQLConnectServer.call(SQLConnectServer.java:37)
    at com.progress.common.rmiregistry.TryIt.run(TryIt.java:186)

 

[techjohnny]

[2/18/14 6:12:54 PM]=== Start logging. Local time: 2/18/14 6:12:54 PM. ===
[2/18/14 6:12:54 PM]
[2/18/14 6:12:54 PM] [3] [SQLExplorer]           Local c:\epicor\oe101b_wrk\SQLExplorer.properties file will be used. (SQLMsg036)
[2/18/14 6:12:54 PM] [3] [SQLExplorer]           Setting Connect to jdbc:datadirect:Openedge://192.168.2.3:8350;databaseName=mfgsys
[2/18/14 6:12:54 PM] [3] [SQLExplorer]           === SQLExplorer starting. ===
[2/18/14 6:12:54 PM] [3] [SQLExplorer]           ### ARGS:    -db mfgsys -S 8350 -user *********  -password  ********* -H 192.168.2.3
[2/18/14 6:12:54 PM] [3] [SQLExplorer]           Connecting user "******" to URL "jdbc:datadirect:Openedge://192.168.2.3:8350;databaseName=mfgsys"... (8920)
[2/18/14 6:12:54 PM] [3] [SQLExplorer]           Loading JDBC driver com.ddtek.jdbc.openedge.OpenEdgeDriver.
[2/18/14 6:12:54 PM] [0] [*UnexpectedError*]   * recorded as exception #3 in file c:\epicor\oe101b_wrk\SQLExplorer.exceptions.
[2/18/14 6:12:54 PM] [3] [SQLExplorer]           === SQLExplorer ending. ===
====== Start exception logging == "c:\epicor\oe101b_wrk\SQLExplorer.exceptions" opened == Tue Feb 18 17:51:19 GMT 2014 ======


**** 2 ****

   Exception at Tue Feb 18 17:51:19 GMT 2014: java.lang.NullPointerException
   Message (throw): ### Connect stack trace. ###
   Message (excp):  null
   Stack Trace:
java.lang.NullPointerException
    at com.ddtek.jdbc.base.BaseConnection.connect(Unknown Source)
    at com.ddtek.jdbc.base.BaseConnection.setupImplConnection(Unknown Source)
    at com.ddtek.jdbc.base.BaseConnection.open(Unknown Source)
    at com.ddtek.jdbc.base.BaseDriver.connect(Unknown Source)
    at java.sql.DriverManager.getConnection(DriverManager.java:512)
    at java.sql.DriverManager.getConnection(DriverManager.java:171)
    at com.progress.sql.explorer.SQLConnectServer.call(SQLConnectServer.java:37)
    at com.progress.common.rmiregistry.TryIt.run(TryIt.java:186)

Update:

Still receiving the error above when connecting using the sqlexp tool locally. I was able to connect to a test database on the same server using the sqlexp tool.

 

[Rob Fitzpatrick]

Try reinstalling the drivers on the client side.

 

[techjohnny]

Try reinstalling the drivers on the client side.

I'm running the sqlexp tool for the server. The drivers were re-installed on the clients.

 

[techjohnny]

I'm running the sqlexp tool for the server. The drivers were re-installed on the clients.

Okay, all you Progress experts, copied the entire c:\oe101b from a working machine to this machine, and now it will connect using the sqlexp, but I'm concerned there might be some side effect to doing this? There wasn't one thing in the config files I knew of that was different, but after copy, it connects now.

Do I need to be worried about the database?

 

[Rob Fitzpatrick]

Do I need to be worried about the database?

I don't think there is enough information to say. But if you said "I'm not worried about the database", that would be worrying.

I was on a client's Windows database server years ago where _dbutil.exe would regularly crash out with a Windows error. Yet the same command on their DR box it worked fine. The "fix" in that case was to copy the executable from DR to prod, so obviously there was some corruption in the file on disk or in the file system structures that described it. There were other issues on that box (e.g. 1124 errors) that made me suspect disk subsystem issues as the root cause.

It may be that you had one or more broken DLC files and overwriting them with copies from a different box fixed that symptom. But the root cause of the problem that manifested that symptom may well remain unresolved.

Suggestions:

• Check the logs or diagnostics of your storage subsystem (RAID array? SAN?).
  
• Check the Windows System event log for errors.
  
• Check the 4GL client logs, if any, and the database log for errors.
• Run a disk diagnostic.
• Run a file system diagnostic.

Is your server and storage hardware of a similar vintage to your Progress version?

 

[TomBascom]

Good advice.

 

[techjohnny]

I don't think there is enough information to say. But if you said "I'm not worried about the database", that would be worrying.

I was on a client's Windows database server years ago where _dbutil.exe would regularly crash out with a Windows error. Yet the same command on their DR box it worked fine. The "fix" in that case was to copy the executable from DR to prod, so obviously there was some corruption in the file on disk or in the file system structures that described it. There were other issues on that box (e.g. 1124 errors) that made me suspect disk subsystem issues as the root cause.

It may be that you had one or more broken DLC files and overwriting them with copies from a different box fixed that symptom. But the root cause of the problem that manifested that symptom may well remain unresolved.

Suggestions:

• Check the logs or diagnostics of your storage subsystem (RAID array? SAN?).
  
• Check the Windows System event log for errors.
  
• Check the 4GL client logs, if any, and the database log for errors.
• Run a disk diagnostic.
• Run a file system diagnostic.

Is your server and storage hardware of a similar vintage to your Progress version?

Thanks for the advice. Looks like the solution was overwriting the c:\oe101b\bin directory from the working system. Now the sqlexp and ODBC connections are successful.

There were no hardware or events errors logged pertaining to Progress in the Windows event logs.

I was able to recreate the connection errors on a clean install of Progress on 2 separate machines. Still not sure why our original production server contained a different copy of the \bin directory, and the development server's \bin directory did not work nor did the new production server clean Progress install contained the broken \bin directory.

Regards,

--tj

 

[Rob Fitzpatrick]

There were no hardware or events errors logged pertaining to Progress in the Windows event logs.

The error you're looking for, if it exists, might have nothing to do with Progress (e.g. a disk error).

Still not sure why our original production server contained a different copy of the \bin directory, and the development server's \bin directory did not work nor did the new production server clean Progress install contained the broken \bin directory.

Maybe the result of people manually copying DLC directory contents?

Maybe your installation archive is bad. Try re-downloading the code from Progress and compare to what you have.

Also, it would be a very good idea to try to upgrade to a supported release of OpenEdge, for exactly this reason. If you go to PSC for help your options are limited on 10.1B. You're also prone to more bugs.