> From: pgsql-odbc-owner@postgresql.org > > [mailto:pgsql-odbc-owner@postgresql.org] On Behalf Of Jon Raiford > > It would seem that I was mistaken. My simple test case did produce the > > expected 08001 SQLSTATE with the updated driver, but when I scaled up to > > multiple connections it was not consistent. In the end I am now simply > > check HY000 errors and change them to 08001 if the text matches "*server > > closed the connection*". A brute force method, but it allows me to move > > forward. > > > > Of course it may be that I made a mistake in applying the patch or my build > > environment. I will happily test an updated build when it becomesavailable > > and report back. > > First, the SQLSTATE is 08S01, not 08001.
Yes, I can see that the code does answer 08S01, however it is being reported as 08001 to the application. This can be seen even in the ODBC trace. I'm not sure why it is changed. Maybe this is a symptom of a bigger problem? > BTW, you seem to want a method to judge that the connection is lost. > Then, SQLGetConnectAttr(hdbc, SQL_ATTR_CONNECTION_DEAD) should be > the right answer. See the following page, and please try it. > > https://msdn.microsoft.com/en-us/library/ms713605(v=vs.85).aspx > > SQL_ATTR_CONNECTION_DEAD > A read-only SQLUINTEGER value that indicates the state of the > connection. If SQL_CD_TRUE, the connection has been lost. If > SQL_CD_FALSE, the connection is still active.
Thank you! I did not know about this option. I will certainly investigate this as an alternative going forward.