Skip to Content.
Sympa Menu

freetds - Re: [freetds] SQL_NO_DATA or SQL_SUCCESS

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] SQL_NO_DATA or SQL_SUCCESS
  • Date: Wed, 27 Feb 2008 17:15:38 +0100

>
> ZIGLIO, Frediano, VF-IT wrote:
> > MS driver NEVER
> > > > returns SQL_NO_DATA !!!
> ...
> >
> > Mmmm... as said if nobody complains I would commit... so I
> complain :)
> >
> > Yes, it seems that DELETE/UPDATE with no rows produce SQL_NO_DATA!!
> > However I must say that as documented only DELETE/UPDATE
> with no rows
> > should return SQL_NO_DATA. The situaction is complicated by the fact
> > that only mssql (no Sybase) return proper informations to detect
> > UPDATE/DELETE execution!
>
> I have been trying to test this for you with the Sybase ODBC
> driver on my
> OS X box. Last night I built FreeTDS on it for the first
> time, but didn't
> get to testing anything.
>
> http://msdn2.microsoft.com/en-us/library/ms715424(VS.85).aspx
>
> I'm sure you've read the above confusing page more than once. It says

Agreed :)

> that whether SQLExecute returns SQL_NO_DATA or SQL_SUCCESS depends on:
>
> 1. Whether the *application* is 2.x or 3.x.
> 2. Whether the "searched update or delete" was part of a batch.
> 3. Whether any rows were affected.
>
> According to the documentation, then, SQLExecute returns
> SQL_NO_DATA only
> if
>
> 1. a "searched update or delete" is not part of a batch --
> or, I presume,
> a stored procedure -- and

I think "not" here is only a typo error.

> 2. is issued by a 3.x application, and
> 3. affected zero rows.
>
> (I do not know what a "searched update" is. I guess it means
> one with a
> WHERE clause. If I issue "UPDATE tablename SET columname =
> 0" on a table
> with zero rows, it affects zero rows. What should the driver return
> then?)
>

Yes, an update with a where.

> The simplest choice: always return SQL_SUCCESS from
> SQLExecute and reserve
> SQL_NO_DATA for SQLFetch.
>

That is what the patch does... I applied on 0.82 branch.

> The "right" choice (apparently): Return SQL_NO_DATA from
> SQLExecute *only*
> for a 3.x application and *only* if you get back a DONE
> packet (0xFD) with
> rowcount == 0 immediately after issuing the query.
>
> How much simpler could it be? ;-)
>

I did some tests and it appear that driver check only for update/where.
For instance a create table or a begin transaction (which produce a done
with 0 rows). Or perhaps they produce a DONE without rows??

freddy77




Archive powered by MHonArc 2.6.24.

Top of Page