Skip to Content.
Sympa Menu

freetds - Re: [freetds] "Fix affected rows after insert with prepared query" side effect

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Frediano Ziglio <freddy77 AT gmail.com>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] "Fix affected rows after insert with prepared query" side effect
  • Date: Sat, 23 Apr 2016 13:04:06 +0100

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

There was another patch that make the change the same.

> https://lists.ibiblio.org/sympa/arc/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?

> 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)
>>> (1 row affected)
>>> (1 row affected)
>>> (1 row affected)
>>> (1 row affected)
>>> (1 row affected)
>>> (1 row affected)
>>> (0 rows affected)
>>> (8 rows affected)
>>> (1 row affected)
>>> (1 row affected)
>>> (1 row affected)
>>> (1 row affected)
>>> (1 row affected)
>>> (1 row affected)
>>> (1 row affected)
>>> (1 row affected)
>>> (1 row affected)
>>> (1 row affected)
>>> (1 row affected)
>>> (1 row affected)
>>> (1 row affected)
>>> (1 row affected)
>>> (1 row affected)
>>> (1 row affected)
>>> (1 row affected)
>>> (1 row affected)
>>> (1 row affected)
>>> (0 rows affected)
>>> ... etc
>>> <snip>




Archive powered by MHonArc 2.6.24.

Top of Page