[freetds] Can't write to DB using stored procedure
James K. Lowden
jklowden at freetds.org
Sat May 16 19:12:55 EDT 2009
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
$ 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)
(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
ct-lib does produce a special row for return status, and IIRC DBD::Sybase
supports both that and output parameters.
More information about the FreeTDS