Re: catching posting exceptions
От | Ken J. Wright |
---|---|
Тема | Re: catching posting exceptions |
Дата | |
Msg-id | 3.0.32.19990816130552.00a39980@ren.cncware.com обсуждение исходный текст |
Список | pgsql-interfaces |
At 10:10 07/30/1999 -0400, you wrote: > > >"Ken J. Wright" wrote: > >> Attached are the logs pertaining to the posting error. Hopefully they will >> shed some light. At the end of sql.log there is a SQLDisconnect. This is >> the point in the program at which the dataset state goes to InActive. I can >> not as of yet, determine where the SQLDisconnect is originating. >> >> Byron, could you please have a look for a possible driver problem? >> > >I don't see anything. It looks like it is working correctly. The driver is >returning an error from sqlexecute. Shouldn't the application handle that? > Byron, The driver is returning a SQLSTATE of "08S01" (communication link failure) for any hstmt type error. The error in this case was from attempting to duplicate a unique key. My application never had the chance to judge the error, as the api (OCBDExpress) has a hard coded block that terminates the connection if the SQLSTATE is a "08xxx". This is where my problem stems from. I believe that both the api & the driver are not correct. The MS ODBC reference states that the SQLSTATE is not required by the driver and should not be trusted by an app. This is where I believe ODBCExpress is wrong. However, 08S01 indicates a rather fatal connection type of error. This is where I believe the driver is wrong. A failed sql statement does not constitute a connection failure. The closest error I can find that would work is HY000 (general error). Comments? Ken
В списке pgsql-interfaces по дате отправления: