freetds AT lists.ibiblio.org
Subject: FreeTDS Development Group
List archive
Re: [freetds] "Fix affected rows after insert with prepared query" side effect
- From: John Kendall <john AT capps.com>
- To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
- Subject: Re: [freetds] "Fix affected rows after insert with prepared query" side effect
- Date: Tue, 10 May 2016 21:31:04 +0000
It appears the patch for this ("fix ct-library rows count") has broken
compute in ctlib:
select col=1 into #tbl insert #tbl values (2) select * from #tbl compute
sum(col)
(1 row affected)
(1 row affected)
col
-----------
1
2
2
(3 rows affected)
dblib (and ctlib RC1) does the expected:
select col=1 into #tbl insert #tbl values (2) select * from #tbl compute
sum(col)
(1 row affected)
(1 row affected)
col
-----------
1
2
sum
===========
3
(3 rows affected)
Sorry to keep finding things!
John
> On Apr 30, 2016, at 4:23 PM, Frediano Ziglio <freddy77 at gmail.com> wrote:
>
> Now works much better. Please try last RC (4).
>
> Frediano
>
>
> 2016-04-24 16:55 GMT+01:00 John Kendall <john at capps.com>:
>> 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.
>>>
>>>> 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?
>>
>>
>> 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>
-
Re: [freetds] "Fix affected rows after insert with prepared query" side effect,
John Kendall, 05/04/2016
- <Possible follow-up(s)>
-
Re: [freetds] "Fix affected rows after insert with prepared query" side effect,
John Kendall, 05/10/2016
-
Re: [freetds] "Fix affected rows after insert with prepared query" side effect,
Frediano Ziglio, 05/10/2016
-
Re: [freetds] "Fix affected rows after insert with prepared query" side effect,
Sergio NNX, 05/10/2016
- Re: [freetds] "Fix affected rows after insert with prepared query" side effect, Frediano Ziglio, 05/11/2016
-
Re: [freetds] [GRAYMAIL] Re: "Fix affected rows after insert with prepared query" side effect,
John Kendall, 05/11/2016
- Re: [freetds] [GRAYMAIL] Re: "Fix affected rows after insert with prepared query" side effect, Frediano Ziglio, 05/11/2016
-
Re: [freetds] [GRAYMAIL] Re: "Fix affected rows after insert with prepared query" side effect,
Frediano Ziglio, 05/11/2016
- Re: [freetds] "Fix affected rows after insert with prepared query" side effect, John Kendall, 05/11/2016
- Re: [freetds] "Fix affected rows after insert with prepared query" side effect, John Kendall, 05/11/2016
-
Re: [freetds] "Fix affected rows after insert with prepared query" side effect,
Sergio NNX, 05/10/2016
-
Re: [freetds] "Fix affected rows after insert with prepared query" side effect,
Frediano Ziglio, 05/10/2016
Archive powered by MHonArc 2.6.24.