Skip to Content.
Sympa Menu

freetds - Re: [freetds] 0.64 feature set and schedule

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "Lowden, James K" <LowdenJK AT bernstein.com>
  • To: "FreeTDS Development Group" <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] 0.64 feature set and schedule
  • Date: Tue, 10 Jan 2006 11:30:46 -0500

> From: ZIGLIO, Frediano, VF-IT
> Sent: Monday, January 09, 2006 5:02 AM
>
> > I held off releasing 0.64 because I'm hoping you'll have a fix
> > for the results-error-results problem illustrated by my little
> > test (cf. "quick ODBC test" December 6-8).
>
> Well, current test
>
> On Linux with latest CVS (t return error while t2 return warning)
[basically success]
> On Windows with MS ODBC
[same success]

> Executing: "{? = call t }" with parameters ''
> execute returned: '-1'
> Result #1:
> [FirstResult]
> 'Here is the first row'
> ===> state: 42000 msg: This is an example error message.
> DBD::ODBC::st fetchrow failed: (DBD: st_fetch/SQLMoreResults err=-1)
at
> odbc_rpc.pl line 116.
> 'Here is the first row'
> ===> state: HY010 msg: Function sequence error
> DBD::ODBC::st fetchrow failed: (DBD: st_fetch/SQLFetch err=-1) at
> odbc_rpc.pl line 116.

It *is* very odd that the ODBC driver returns the same row twice.

The fact that you get an error message in no way suggests to me that the
result set should become corrupted. Correct behavior IMHO would be to
return the error and continue with the next result set. After all, the
error doens't prevent the server from sending the data, and the error
doesn't necessarily pertain to the second (or later) result set.

Perhaps the test module needs to call some function before continuing to
read the data? Some kind of "clear error status" call or something?

> You can see that - some state code are missing - error for raiserror
> >= 10 is different ("Invalid cursor state" instead of "Function
> sequence error") but similar - odbc_async_exec is different (0 for
> FreeTDS 1 for MS ODBC), expected (we do not support async execute)
> - the rest is the same So, well, I'll fix state (trivial) and I
> consider the stopover not existing anymore.
>
> !!!! To sum up: we are ready for 0.64 !!!!

The very good news is that warnings and errors aren't being dropped on
the floor. That's a very big improvement for production environments.
On their behalf, thanks very much for chasing this down.

--jkl



-----------------------------------------
The information contained in this transmission may be privileged and
confidential and is intended only for the use of the person(s) named
above. If you are not the intended recipient, or an employee or agent
responsible
for delivering this message to the intended recipient, any review,
dissemination,
distribution or duplication of this communication is strictly prohibited. If
you are
not the intended recipient, please contact the sender immediately by reply
e-mail
and destroy all copies of the original message. Please note that we do not
accept
account orders and/or instructions by e-mail, and therefore will not be
responsible
for carrying out such orders and/or instructions. If you, as the intended
recipient
of this message, the purpose of which is to inform and update our clients,
prospects
and consultants of developments relating to our services and products, would
not
like to receive further e-mail correspondence from the sender, please "reply"
to the
sender indicating your wishes. In the U.S.: 1345 Avenue of the Americas, New
York,
NY 10105.




Archive powered by MHonArc 2.6.24.

Top of Page