freetds AT lists.ibiblio.org
Subject: FreeTDS Development Group
List archive
RE: [freetds] ODBC bug: server errors not reported
- From: "ZIGLIO, Frediano, VF-IT" <Frediano.Ziglio AT vodafone.com>
- To: "FreeTDS Development Group" <freetds AT lists.ibiblio.org>
- Subject: RE: [freetds] ODBC bug: server errors not reported
- Date: Wed, 10 Mar 2004 09:36:05 +0100
>
> > > I don't understand how SQLExecDirect() can (correctly) stop before
> > > DONEPROC. How is the application expected to learn of
> the ERROR?
> >
> > I think on next SQLMoreResults or perhaps on SQLFetch (I didn't test
> > it)...
>
> Please try the attached diff. It creates a stored procedure
> that returns an error behind a good resultset, and calls
> SQLBindCol() and SQLFetch(). It does not see an error.
>
> There is another problem:
>
> if (discard_test < 1) {
> /* generate an error */
> printf("discard_test is %d\n", discard_test);
> result = CommandWithResult(Statement, "EXEC testerror");
>
> If this block of code is executed more than once -- "if
> (discard_test < 2)", say -- the second time the Test()
> function is called will yield a 24000 cursor state error.
> The error is produced regardless of what command is executed;
> it can be "testinsert". I don't know if that's my failure to
> use the API correctly or a lingering problem in CVS head.
>
Using ODBC you must read all results, or call
SQLFreeStmt(CLOSE/DROP)/SQLFreeHandle/SQLCloseCursor.
> I have tested the "testerror" procedure with DBD::ODBC. It
> also does not notice any error. For that reason, I think
> this is a FreeTDS bug.
>
No, you never retrieved next recordset (with error), so you do not get
error. This raise another question: what's correct result calling
SQLFreeStmt(CLOSE/DROP)/SQLFreeHandle/SQLCloseCursor with error pending
??
Perhaps it's time to add a new test ??
> Naturally I would be delighted to learn that my methodology
> is wrong. If you can modify transaction.c to report the
> server's error message, that would be great.
>
> Thanks for your time, Freddy.
>
Don't mind. ML traffic was very low... I'm happy it was just a sleeping
dog :)
Some problems raised very recently however comparing with older one are
very impressive. We are not speaking about how to read data from a
simple select but how and when retrieve an error when a given weird
condition happen!
freddy77
-
[freetds] ODBC bug: server errors not reported,
Lowden, James K, 03/09/2004
- <Possible follow-up(s)>
- RE: [freetds] ODBC bug: server errors not reported, ZIGLIO, Frediano, VF-IT, 03/10/2004
- RE: [freetds] ODBC bug: server errors not reported, Lowden, James K, 03/10/2004
-
RE: [freetds] ODBC bug: server errors not reported,
ZIGLIO, Frediano, VF-IT, 03/11/2004
- Re: [freetds] ODBC bug: server errors not reported, James K. Lowden, 03/11/2004
Archive powered by MHonArc 2.6.24.