Alexander Farber (EED) writes:
> I have a web page for deleting so-called OWNER's
> with the help of this stored procedure:
<snip>
> if @@error != 0 or @@rowcount = 0
> return -1
You should probably return a positive non-0 value. Negative values are
used by Sybase (e.g. -4 is deadlock, IIRC, -6 is execution failed)
> my $dbh = DBI -> connect ('dbi:Sybase:server=xxx', 'xxx', 'xxx',
> { RaiseError => 1,
> AutoCommit => 1,
> ChopBlanks => 1,
> syb_do_proc_status => 1 });
OK - the problem is that the failure isn't caught by RaiseError. If
you check the return value from $sth->execute you'll see that an error
code is indeed returned.
To force a RaiseError failure you probably need to put a raiserror
statement in your stored proc, something like:
if @@error != 0 or @@rowcount = 0
begin
raiserror 31001 "Failed to delete owner '%1!'", @owner
return 31001 -- or whatever
end
Now the user-defined error code 31001 will be returned to the client.
Note that this will work whether syb_do_proc_status is set or not.
I suppose that it would be better if RaiseError could catch non-0 proc
status return values when syb_do_proc_status is set. The issue here is
that IIRC RaiseError checks the value of $sth->err, and that value is
of course 0 because no server error has occured.
Michael
--
Michael Peppler - Data Migrations Inc. - [EMAIL PROTECTED]
http://www.mbay.net/~mpeppler - [EMAIL PROTECTED]
International Sybase User Group - http://www.isug.com
Sybase on Linux mailing list: [EMAIL PROTECTED]
