Skip to Content.
Sympa Menu

freetds - Re: [freetds] Can't write to DB using stored procedure

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "James K. Lowden" <jklowden AT freetds.org>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] Can't write to DB using stored procedure
  • Date: Sat, 16 May 2009 19:12:55 -0400

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





Archive powered by MHonArc 2.6.24.

Top of Page