Re: "Fix affected rows after insert with prepared query" side effect
Frediano Ziglio <[email protected]>
| Newsgroups | gmane.comp.db.tds.freetds |
|---|---|
| Message-ID | <CAHt6W4e5mapE0QMHXcHK__3YqDsW5ti5nAgS28eT6GSYH=kGxQ@mail.gmail.com> |
Now works much better. Please try last RC (4). Frediano 2016-04-24 16:55 GMT+01:00 John Kendall <[email protected]>: > 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> > _______________________________________________ > FreeTDS mailing list > [email protected] > http://lists.ibiblio.org/mailman/listinfo/freetds