"Fix affected rows after insert with prepared query" side effect

Sorry, my last post had the wrong link to sybase infocenter.

2016-04-23 13:04 GMT+01:00 Frediano Ziglio <freddy77 at gmail.com>:

> 2016-04-22 1:03 GMT+01:00 John Kendall <john at capps.com>: 
> 
>> Thu, 21 Apr 2016 11:04:54 +0100 Frediano Ziglio <freddy77 at gmail.com> 
>> 
>>> 2016-04-21 8:00 GMT+01:00 John Kendall <john at capps.com>: 
>>>> On Oct 19, 2015 this patch was applied to ct.c: 
>>>> 
>>>> "Fix affected rows after insert with prepared query" 
>>>> 
>>>> This patch has the side-effect of a 'rows affected' being displayed for every 
>>>> select statement within a ASE stored procedure. For example, sp_help returns 
>>>> 136 extra 'rows affected' lines. See below. Backing out this patch stops this from 
>>>> happening. I only tested this on sp_help, but I figured that was enough. FYI, this
>>>> patch does not have this effect on MS SQL 2008's sp_help sproc. 
>>>> 
>>>> John 
>>>> 
>>> 
>>> I'm not sure if this is a regression or an improvement. I have to 
>>> check what's the original CT-Library behaviour. 
>>> 
>>> Frediano 
>> 
>> Hi, Frediano. 
>> 
>> I compiled sqsh against Sybase 16 libs and it does not return all those 'rows affected'
>> lines. I could be reading it wrong, but in the archives, it appears the patch applied was
>> not the one requested by David Nichols. 
>> 
> 
> There was another patch that make the change the same. 
> 
>> http://lists.ibiblio.org/pipermail/freetds/2015q4/029631.html
>> 
>> Could we remove that patch? 
>> 
> 
> I don't think so. But probably the patch fixed an issue and introduced a problem 
> so we should find a solution. I think that Dave/Ondrei wanted to have the row 
> number returned by a DONEINPROC in the case of a prepared statement. This 
> does not mean they want all DONEINPROC from the server. 
> 
> Basically
> - before: no DONEINPROC
> - after: all DONEINPROC
> - wanted (you): one DONEINPROC (which one and how still to be defined) 
> Does this make sense?


Yes. 

As far as I can tell, it should only return the count for the last statement that could affect rows:

http://infocenter.sybase.com/help/index.jsp?topic=/com.sybase.infocenter.dc36065.1570/html/ctlibmig/X65200.htm

So, the last insert, delete or update, perhaps?



>> Thanks, 
> 
>> John 
>> 
>> 
> 
> I think this is the only no-build issue we had since the 1.0 RC. Not bad! Frediano >
> 
>>>> 
>>>> sqsh> sp_help Movetype 
>>>> (1 row affected) 
>>>> Name Owner Object_type 
>>>> -------------------------------- -------------------- ---------------------------------------- 
>>>> Movetype dbo user table 
>>>> 
>>>> Column_name Type Length Pre 
>>>> ------------------------------------------------ ---------------- ------------------------ --- 
>>>> movetype char 2 NUL 
>>>> move_desc char 20 NUL 
>>>> move_revenue bit 1 NUL 
>>>> 
>>>> (1 row affected) 
>>>> (1 row affected) 
>>>> (1 row affected) 
>>>> (0 rows affected) 
>>>> (1 row affected) 
>>>> (0 rows affected) 
>>>> (1 row affected) 
>>>> (1 row affected) 
>>>> (1 row affected) 
>>>> (1 row affected) 
>>>> (1 row affected) 
>>>> (1 row affected) 
>>>> (1 row affected) 
>>>> Object has the following indexes 
>>>> 
>>>> (1 row affected) 
>>>> (1 row affected) 
>>>> ... etc 
>>>> <snip>