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: "James K. Lowden" <jklowden AT schemamania.org>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] ODBC bug: server errors not reported
  • Date: Thu, 11 Mar 2004 09:08:35 -0500

On Thu, 11 Mar 2004, "ZIGLIO, Frediano, VF-IT"
<Frediano.Ziglio AT vodafone.com> wrote:
> >
> > 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.

Quite so! ;-)

> It's not easy to fix but I'll fix it ASAP.

That would be positively wonderful. I looked at it, but, as you say, it's
not easy.

> 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...

There will always be specialized tests. My "isql" idea is a program that
is more generalized than our unit tests. It can process arbitrary SQL
from stdin: multiple result sets, all data types, compute rows, etc. If
we can make it misbehave by altering the SQL, we have an instant test case
for a bug report.

> > 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.

Well, you're probably right. :-/ The fix may be extensive, and may have
other ramifications that will take time to notice.

> About TODO list (copied)

I'll try to look after some of these. None of them is critical, however.
By comparison, folks using 0.62 risk data corruption if they're relying on
SQLFetch() to report errors. I guess that means you're doing the more
important work.

An alternative would be to apply your fix to 0.62 (releasing 0.62.2), and
hold off on 0.63 until your TODO is done. I put together a patdch to do
that. Let me send it to you and see if it's right.

Regards,

--jkl






Archive powered by MHonArc 2.6.24.

Top of Page