Skip to Content.
Sympa Menu

freetds - [freetds] "Fix affected rows after insert with prepared query" side effec

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: John Kendall <john AT capps.com>
  • To: FreeTDS Group <freetds AT lists.ibiblio.org>
  • Subject: [freetds] "Fix affected rows after insert with prepared query" side effec
  • Date: Sun, 24 Apr 2016 15:49:36 +0000

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.dc32300.1570/html/sqlug/X31520.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>



  • [freetds] "Fix affected rows after insert with prepared query" side effec, John Kendall, 04/24/2016

Archive powered by MHonArc 2.6.24.

Top of Page