RE: [ODBC] Re: ODBC Interface version 07_01_0005, problemwith C++ exceptions

Started by Hiroshi Inouealmost 25 years ago2 messagesbugs
Jump to latest
#1Hiroshi Inoue
Inoue@tpf.co.jp

Hi,
Probably the cuase is as follows.

Currently SQLExecute/ExecDirect returns SQL_ERROR and the SQLSTATE ==
'00000'
in case of ERRORs and (some) NOTICEs.

Of cource SQL_ERROR means an error but SQLSTATE == '00000' indicates
success.
MFC ODBC class seems to ignore the error message when SQLSTATE == '00000'
(I got the error message in an application using VB).

regards,
Hiroshi Inoue

Show quoted text

-----Original Message-----
From: Kristis Makris [mailto:kristis.makris@datasoft.com]

Hello,

On 14 Jun 2001 15:51:18 +0900, Hiroshi Inoue wrote:

Mister X wrote:

Hi,

developing in MFC/Visual Studio 6 I've encountered a strange problem
in last version of ODBC Driver (actually 07_01_0005). Each time a SQL
error occours, the istructions TRY/ CATCH doesn't report the error
string: the CDBException ' member m_strError is empty
Follows an example:

// MFC C++ Code

CDatabase myDB;

[.....] // Init and Open database...

//create a table with a WRONG SQL statement:

CString sSQLStatement="CREATE TABLE Dummy ( int DummyID, )";
// The statement is WRONG beacuse the comma
after the last column definition.

//Executes The statement and catch errors:

TRY
{
myDB.ExecuteSQL(sSQLStatement);
}
CATCH(CDBException, e)
{
AfxMessageBox(e->m_strError);
}
END_CATCH

Well, with driver version v06-50-0000 i got the string "Error
creating the table; ERROR: parser: parse error at or near ")", that
it is the correct error message from the back-end.
Instead, with Version 07_01_0005 of the ODBC driver, the string
e->m_strError is always empty, and the member m_nRetCode of
CDBException class is = -1;

Probably the cause is the same as another bug I recently
found. I'm asking pgsql-obdc ML why the error handling was
changed.

regards,
Hiroshi Inoue

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

I don't whether the following has anything to do with this problem, but
while developing in VC++ 6 I've come across a few cases where I've sent
a valid SQL statement through ODBC that did not take any effect. I've
sent an UPDATE statement to postrgres, but nothing was updated. I did
not get any errors/exceptions from the driver in a similar try/catch
block (so I assumed that the statement was accepted and processed fine).
I looked into the C:\psqlodbc_xxx.log file, and did not even see a line
in it that shows that the statement was sent to the backend. I only saw
I couple of lines that were used to initiate the connection. (driver
7.01.00.05)

I haven't been able to reproduce this yet, but I'd be glad to provide a
copy of the log and some snippet code if I come across it again.

PS. I've been using try/catch instead of TRY/CATCH, and haven't come
across the problem described here yet. Could this have something to do
with VC++'s TRY/CATCH macros?

--
---------------------------------------------------------------------
Kristis Makris Datasoft Coproration
kristis.makris@datasoft.com http://www.datasoft.com
---------------------------------------------------------------------

#2Mister ics
mister_ics@hotmail.com
In reply to: Hiroshi Inoue (#1)
RE: [ODBC] Re: ODBC Interface version 07_01_0005, problemwith C++ exceptions

Hi,

I perfectly agree your analisys of the problem, and i would ask to the ODBC
developer team to consider the following simple fix in the next version of
the driver:

in case of errors set SQLSTATE = SQL_ERROR or something else but not 0.

It's more difficult to change the MFC behavior ;)

regards,
Silvio

Hi,
Probably the cuase is as follows.

Currently SQLExecute/ExecDirect returns SQL_ERROR and the SQLSTATE ==
'00000'
in case of ERRORs and (some) NOTICEs.

Of cource SQL_ERROR means an error but SQLSTATE == '00000' indicates
success.
MFC ODBC class seems to ignore the error message when SQLSTATE == '00000'
(I got the error message in an application using VB).

regards,
Hiroshi Inoue

-----Original Message-----
From: Kristis Makris [mailto:kristis.makris@datasoft.com]

Hello,

On 14 Jun 2001 15:51:18 +0900, Hiroshi Inoue wrote:

Mister X wrote:

Hi,

developing in MFC/Visual Studio 6 I've encountered a strange

problem

in last version of ODBC Driver (actually 07_01_0005). Each time a

SQL

error occours, the istructions TRY/ CATCH doesn't report the error
string: the CDBException ' member m_strError is empty
Follows an example:

// MFC C++ Code

CDatabase myDB;

[.....] // Init and Open database...

//create a table with a WRONG SQL statement:

CString sSQLStatement="CREATE TABLE Dummy ( int DummyID, )";
// The statement is WRONG beacuse the comma
after the last column definition.

//Executes The statement and catch errors:

TRY
{
myDB.ExecuteSQL(sSQLStatement);
}
CATCH(CDBException, e)
{
AfxMessageBox(e->m_strError);
}
END_CATCH

Well, with driver version v06-50-0000 i got the string "Error
creating the table; ERROR: parser: parse error at or near ")", that
it is the correct error message from the back-end.
Instead, with Version 07_01_0005 of the ODBC driver, the string
e->m_strError is always empty, and the member m_nRetCode of
CDBException class is = -1;

Probably the cause is the same as another bug I recently
found. I'm asking pgsql-obdc ML why the error handling was
changed.

regards,
Hiroshi Inoue

---------------------------(end of

broadcast)---------------------------

TIP 4: Don't 'kill -9' the postmaster

I don't whether the following has anything to do with this problem, but
while developing in VC++ 6 I've come across a few cases where I've sent
a valid SQL statement through ODBC that did not take any effect. I've
sent an UPDATE statement to postrgres, but nothing was updated. I did
not get any errors/exceptions from the driver in a similar try/catch
block (so I assumed that the statement was accepted and processed fine).
I looked into the C:\psqlodbc_xxx.log file, and did not even see a line
in it that shows that the statement was sent to the backend. I only saw
I couple of lines that were used to initiate the connection. (driver
7.01.00.05)

I haven't been able to reproduce this yet, but I'd be glad to provide a
copy of the log and some snippet code if I come across it again.

PS. I've been using try/catch instead of TRY/CATCH, and haven't come
across the problem described here yet. Could this have something to do
with VC++'s TRY/CATCH macros?

--
---------------------------------------------------------------------
Kristis Makris Datasoft Coproration
kristis.makris@datasoft.com http://www.datasoft.com
---------------------------------------------------------------------

_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.