[freetds] ct_results handles DONEPROC and/or DONEINPROC differently than Sybase Client Lib

John Kendall john at capps.com
Fri Aug 26 19:26:17 EDT 2016


Bear with me on this one.

I've built sqsh with both freetds and sybase ct libs.  Output from them differs when stored procedures are called.  It isn't terribly different, but I would like it to be the same.  I spent a few hours on it and determined that I don't have what it takes to fix it.  Here's the setup for the tests I use to reproduce the issue.  

create procedure proc1
as
   print "This is proc1"
go

create procedure proc2
as
   declare @i int
   select @i=123
   print "This is proc2"
go

create procedure proc3
as
   exec proc1
   print "This is proc3"
go

create procedure proc4
as
   declare @i int
   select @i=123
   exec proc1
   print "This is proc4"
go

create procedure proc5
as
   declare @i int
   select @i=123
   exec proc1
   print "This is proc5"
   select @i union select 456  
go

If you exec each of the stored procedure, you will see that the first three produce the same output whether using sybase or freetds libs.  However, proc4's output looks like this using sybase libs:


   This is proc1
   This is proc4
   (return status = 0)
  

and it looks like this using freetds

   This is proc1
   This is proc4
   (1 row affected, return status = 0)


Not a big deal, but where did that "1 row affected" come from.  It seems to be left over from the 

    select @i=123


which would normally not show up, because variable assignments in procs are not considered rows affected.  Indeed, if proc2 is run, which has that same "select @i=123" line, it produces no rows affected line, no matter which library is used.

Then if we run proc5 using sybase libs we get:

   This is proc1
   This is proc5
            
    -----------
            123
            456

   (2 rows affected, return status = 0)

The "2 rows affected" comes from the final select, which makes sense.  Procedures in client lib are supposed to report the rows affected by the last select/update/delete/insert.  Running proc5 using freetds libs, however, we get:

   This is proc1
   This is proc5
   (1 row affected)
            
    -----------
            123
            456

   (2 rows affected, return status = 0)

The "1 row affected" really wants to be heard.

Since proc2 never mentions this variable assignment and proc4 does, I am assuming that the calling of proc1 within proc4 causes a reporting of rows affected information that should not have been reported.  If you've read this far, bless you.  

Any ideas?
Thanks,
John







More information about the FreeTDS mailing list