FreeTDS Development Group

[John Kendall <john AT capps.com>]

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