FreeTDS Development Group

["James K. Lowden" <jklowden AT freetds.org>]

Bodo Schulze wrote:
> 
> But while DBD::Sybase throws no error, execute() invariably returns -1,
> meaning that the number of rows affected is unknown.
> 
> My client confirms that there is no problem with the underlying stored
> procedure (to which I have no access).

I think you need another way to detect how many rows were affected.  I
tried this:

$ TDSDUMP=dump sqsh -S$S -U$U -P$P <<< "$(printf 'create table #t(t int)
insert #t values (1)\ngo\ncreate proc #tp as insert #t values (3)\ngo\n
exec #tp\ngo\nselect * from #t\ngo\n')"
(1 row affected)
(return status = 0)
 t          
 -----------
           1
           3

(2 rows affected)

As you can see above, sqsh prints "rows affected" only for open SQL. 
Let's look at what the server returned:

$ grep valid dump
done_count_valid = 0 # changed databasse
done_count_valid = 0 # create table
done_count_valid = 1 # insert
done_count_valid = 0 # create proc
done_count_valid = 1 # proc's insert
done_count_valid = 0 # return status
done_count_valid = 1 # select

Without looking too deeply at DBD::Sybase, let's just say there's a real
challenge -- and not much point -- in trying to return to the application
the number of rows affected by a stored procedure.  A challenge, because
it's in not the final DONE packet returned by the server.  Not worthwhile,
because a stored procedure can contain many SQL statements.  What "rows
affected" number would you like to see?   The first, last, total, or
something else?  

ct-lib does produce a special row for return status, and IIRC DBD::Sybase
supports both that and output parameters.   

HTH.  

--jkl