Thread: ODBC Interface version 07_01_0005, problem with C++ exceptions

ODBC Interface version 07_01_0005, problem with C++ exceptions

From
Mister X
Date:
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;
Handling errors with C++ exception is a great thing, i thing this is a
bug of ODBC driver. The only way to discover the SQL errors reported
by the back-end is to analyze the driver connection log, after each
SQLExecute failed istruction, and it is not very very confortable for
the programmer :)

 Thank you.

Silvio.   mister_ics@hotmail.com

Re: ODBC Interface version 07_01_0005, problem with C++ exceptions

From
Hiroshi Inoue
Date:
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

Re: ODBC Interface version 07_01_0005, problem with C++ exceptions

From
"Mister ics"
Date:
Thank you for your answer,

i hope we'll find soon the solution for this bug

I'm trying to build the driver's source code with Visual Studio 6.0, but the
dll so builded seems not work correctly.... maybe it's due different
settings of compilation enviroinment. I'm working on it.

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

Re: [ODBC] Re: ODBC Interface version 07_01_0005, problem with C++ exceptions

From
Kristis Makris
Date:
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
---------------------------------------------------------------------