Skip to Content.
Sympa Menu

freetds - RE: [freetds] ODBC bug: server errors not reported

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • 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: Thu, 11 Mar 2004 10:44:59 +0100

>
> > From: ZIGLIO, Frediano, VF-IT [mailto:Frediano.Ziglio AT vodafone.com]
> > Sent: March 10, 2004 3:36 AM
> > >
> > > if (discard_test < 1) {
> > > /* generate an error */
> > > printf("discard_test is %d\n", discard_test);
> > > result = CommandWithResult(Statement, "EXEC testerror");
> >
> > Using ODBC you must read all results, or call
> > SQLFreeStmt(CLOSE/DROP)/SQLFreeHandle/SQLCloseCursor.
>
> I committed a corrected version. It executes the query and
> fetches the results, looking for errors from SQLFetch & Co.,
> and (while we're at it) makes sure the fetched value matches
> the inserted value. ;-)
>
> We're out of spec, I'm sure. The docs say that if a row has
> an error (e.g. division by zero), SQLFetch eventually returns
> SQL_SUCCESS_WITH_INFO "unless an error occurs in every row
> ... in which case it returns SQL_ERROR. In particular, if the
> rowset size is 1 and an error occurs in that row, SQLFetch
> returns SQL_ERROR."
>
> Our SQLFetch is wrong on both counts. It's returning
> SQL_SUCCESS when it should at least return
> SQL_SUCCESS_WITH_INFO. My test tries the more extreme case,
> where every row (or the only row) has a division-by-zero
> error, which should return SQL_ERROR.
>

I see. However tests should reflect what we want, not what works,
updated test should fail, not success. It's not easy to fix but I'll fix
it ASAP.

> DBD::ODBC is somehow finding the error, BTW. Perhaps it's
> inspecting the row status array.
>

I don't know, perhaps it reads errors.

> > This raise another question: what's correct result calling
> > SQLFreeStmt(CLOSE/DROP)/SQLFreeHandle/SQLCloseCursor with
> > error pending??
>
> You listening, Steve Murphree? Feel free to jump in any time.
>
> > 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!
>
> I agree, it's progress, that's for sure. :-)
>
> It's really not so very weird, though. It's quite common for
> stored procedures to include multiple result sets. And, even
> though it never happens to you or me, it's also not all that
> rare for them to generate errors. Really, you'd be amazed.
>
> Now that the basic functionality is there, I think we're
> finding that our testing methodology needs revamping. What
> we really need is one "isql" for each API that is specialized
> to test SQL scripts. The "isql" would be generalized handle
> all the kinds of results (regular, compute, parameter, return
> status) we can handle, and could also exercise the
> forthcoming column-wise fetching. It would serve not only as
> a test harness, but also as an example of correct use of the API.
>
> With a program like that, we could try to generate errors and
> such just by altering the external SQL. (We'd need some
> special syntax to test placeholders.)
>

I don't fully understand what you have in mind with this "isql". Current
isql do a lot of things and is not as goods as it seems... We require
for example to get data using different way (SQLGetData, pre bind, post
bind, some columns binded, other not...) while isql use always the same
method...

>
> Freddy, if you can see your way to fixing this, I'd like to
> issue a new release this weekend. How does that strike you?
>

I disagree. We have still to fix the problem and I don't think it's time
to think a release. We should leave a week or two for testing. A rc
whould be fine.

About TODO list (copied)

1- name normalization (removing INFO and others)
finished ? BCPCOLINFO rename ? I think this structure should be
removed (in a future version)
* post it to next version
2- header privatizations (removing tds.h dependency)
this is quite important for future binary compatibility. Export
limitation are committed and works.
* post it to next version
3- cancel. We added a test, analyzed the problem but no code... We have
two options: comment test or start coding.
* comment test (and document in README ??)
4- prepared statement. There are some code (needed for Oracle bindings)
to fetch data types after prepare. There are a lot of TODO (for
optimizations and others problems). binary_test fails if compiled with
--enable-developing.
* without --enable-developing it works, post it
5- ODBC data test fails for numeric, convert.c do not convert NUMERIC ->
NUMERIC changing precision/scale, however it's a new feature so we can
comment this part of test and place a TODO
* this part never worked, comment it
6- ODBC testodbc test need some adjustement (Sybase compatibility and
cursors handling)
* not hard to fix... I'll fix ASAP

freddy77




Archive powered by MHonArc 2.6.24.

Top of Page