[unixODBC-dev] SQL error code/status for DBMS unavailability

anand.vasudevan at wipro.com anand.vasudevan at wipro.com
Mon Jan 16 12:36:48 GMT 2006

But in case of Ingres when there is no DBMS server available, it still
gives 08004, which indicates that the server is available but the
credentials are wrong.

[unixODBC][CA][Ingres ODBC Driver][Ingres]Unable to connect to Name
Server: Blank or incorrect Name

The above fact is true for Oracle also, as it returns 08001 in both the
cases when the credentials are wrong and when the DBMS server is

So how do we distinguish between these 2 different errors based on the
SQL_STATE values?


-----Original Message-----
From: unixodbc-dev-bounces at easysoft.com
[mailto:unixodbc-dev-bounces at easysoft.com] On Behalf Of Nick Gorham
Sent: Monday, January 16, 2006 5:52 PM
To: Development issues and topics for unixODBC
Subject: Re: [unixODBC-dev] SQL error code/status for DBMS

anand.vasudevan at wipro.com wrote:
> Hi
> Is there a specific error code or sql status which could be checked
> in the application, when SQLConnect fails because the DBMS itself is
> available or not running.

Well 08001 is "Client unable to establish connection" and 08004 is
"Server rejected the connection"

So I would say the examples you give are consistent. A 08004 suggests
the server is there but rejected the connection, and 08001 suggests
there is no server to connect to, or the details don't point to a

Nick Gorham
Easysoft Limited
unixODBC-dev mailing list
unixODBC-dev at easysoft.com

The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments.

WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.


More information about the unixODBC-dev mailing list