FreeTDS Development Group

["James K. Lowden" <jklowden AT freetds.org>]

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
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 
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?)  

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

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?  ;-)

--jkl