ODBC Error connection
Moderators: chulett, rschirm, roy
ODBC Error connection
Hi all,
We are migrating datastage 7.5 to 8 and I was changing the .odbc.ini and uvodbc.config file to be able to make a connection to a MSSQL database.
When I try to test the connection from unix (with DS_CONNECT) or when i try to import the table data in datastage i get the following error:
SQLConnect error: Status = -1 SQLState = 01000 Natcode = 145
[ODBC:145] [DataDirect][ODBC SQL Server Driver][libssclient22]ConnectionOpen (connect()).
I've checked some sites and found that SQLState 01000 is a general warning but I can't find anywhere what NATCODE = 145 is (in datastage he just sais CODE = 145).
This is the connection string in .odbc.ini:
[db_messagent]
Driver=/prd/lib/sft/dts/install/8.0.1/InformationServer/Server/branded_odbc/lib/
VMmsss22.so
Description=DataDirect SQL Server Wire Protocol
Database=DB_MESSAGENT
LogonID=<removed for positing issues>
Password=<removed for positing issues>
Address=192.168.240.180,1433
QuotedId=No
AnsiNPW=No
String in uvodbc.conifg:
<db_messagent>
DBMSTYPE = ODBC
Does anybody got an idea ?
Many thnx in advance
We are migrating datastage 7.5 to 8 and I was changing the .odbc.ini and uvodbc.config file to be able to make a connection to a MSSQL database.
When I try to test the connection from unix (with DS_CONNECT) or when i try to import the table data in datastage i get the following error:
SQLConnect error: Status = -1 SQLState = 01000 Natcode = 145
[ODBC:145] [DataDirect][ODBC SQL Server Driver][libssclient22]ConnectionOpen (connect()).
I've checked some sites and found that SQLState 01000 is a general warning but I can't find anywhere what NATCODE = 145 is (in datastage he just sais CODE = 145).
This is the connection string in .odbc.ini:
[db_messagent]
Driver=/prd/lib/sft/dts/install/8.0.1/InformationServer/Server/branded_odbc/lib/
VMmsss22.so
Description=DataDirect SQL Server Wire Protocol
Database=DB_MESSAGENT
LogonID=<removed for positing issues>
Password=<removed for positing issues>
Address=192.168.240.180,1433
QuotedId=No
AnsiNPW=No
String in uvodbc.conifg:
<db_messagent>
DBMSTYPE = ODBC
Does anybody got an idea ?
Many thnx in advance
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
If it's an informational message, can i try an sql statement after the DS_CONNECT to check if the connection really works ? (can't seem to find the command).
In datastage designer we still have the issue that if we want to import table definitions for the ODBC database that we get the same error as in unix but has the following prefix
DSR.MetaGeta(GET.DSNINFO)(SQLCONNECT('db_messagent','datawarehouse'):BCI Error : <unix error>
But it keeps doing that in an endless loops and never retrieves the data, that's why i am assuming that is not just informational.
In datastage designer we still have the issue that if we want to import table definitions for the ODBC database that we get the same error as in unix but has the following prefix
DSR.MetaGeta(GET.DSNINFO)(SQLCONNECT('db_messagent','datawarehouse'):BCI Error : <unix error>
But it keeps doing that in an endless loops and never retrieves the data, that's why i am assuming that is not just informational.
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
DS_CONNECT (which may be DS.CONNECT) can be executed through Administrator client Command window. It's an interactive environment so you will need to use the Response window there.
Does it really say "<unix error>" (sic) when failing to import metadata?
Does it really say "<unix error>" (sic) when failing to import metadata?
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
I select the import tables for ODBC, select the DSN (db_messagent), then i enter the username and password, then datastage client hangs and after a while i get the following
Datastage Repository interface (name of the window with yellow triangle)
DSR.MetaGeta(GET.DSNINFO)(SQLConnect('db_messagent','datawarehouse')): BCI Error:
SQLSTATE=01000,CODE=145,[DataStage][SQL Client][ODBC][DataDirect][ODBC SQL Server Driver][libssclient22]ConnectionOpen (connect())
Clicking OK results in an endless loop the error box (or warning).
Perhaps there is a way to supress this message ?[/img]
Datastage Repository interface (name of the window with yellow triangle)
DSR.MetaGeta(GET.DSNINFO)(SQLConnect('db_messagent','datawarehouse')): BCI Error:
SQLSTATE=01000,CODE=145,[DataStage][SQL Client][ODBC][DataDirect][ODBC SQL Server Driver][libssclient22]ConnectionOpen (connect())
Clicking OK results in an endless loop the error box (or warning).
Perhaps there is a way to supress this message ?[/img]
ConnectionOpen (connect()) -ERROR
DSR.MetaGeta(GET.DSNINFO)(SQLConnect('db_messagent','datawarehouse')): BCI Error:
SQLSTATE=01000,CODE=145,[DataStage][SQL Client][ODBC][DataDirect][ODBC SQL Server Driver][libssclient22]ConnectionOpen (connect())
Could you please explain me what the exact solution of this issues as you have mentioned it is a firewall issue.
How did you resolve this problem/
Thanks in advance!!!
SQLSTATE=01000,CODE=145,[DataStage][SQL Client][ODBC][DataDirect][ODBC SQL Server Driver][libssclient22]ConnectionOpen (connect())
Hi,Druid_Elf wrote:Problem has been solved. Apparently it was a firewall issue
Could you please explain me what the exact solution of this issues as you have mentioned it is a firewall issue.
How did you resolve this problem/
Thanks in advance!!!
The problem was that the unix server on which the new datastage environment was installed, was in an other network segment.
The ACL's of the routers did not allow connection from the unix machine (where DS was running) to the machine on which the database was running for an ODBC connection.
The network administrators changed the ACLs on the routers so that connection was allowed to the the target machine. Then the problem was resolved.
Hopefully this helps.
The ACL's of the routers did not allow connection from the unix machine (where DS was running) to the machine on which the database was running for an ODBC connection.
The network administrators changed the ACLs on the routers so that connection was allowed to the the target machine. Then the problem was resolved.
Hopefully this helps.
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact: