Alexander Farber writes: > > I'm trying to catch the return code of this stored procedure: > > create procedure delete_release @release varchar (32) > as > delete SWRFILES where RELEASE = @release > > But it doesn't work when I delete a record REFERENCEd from another table: > > DBD::Sybase::st execute failed: Server message number=547 severity=16 > state=1 line=3 procedure=delete_release text=Dependent foreign key > constraint violation in a referential integrity constraint. dbname = > 'acapackdel', table name = 'SWRFILES', constraint name = > 'LOADFILES_RELEAS_1584008674'. Statement=delete_release 'R9 CN1' Server > message number=3621 severity=10 state=0 line=3 procedure=delete_release > text=Command has been aborted. Statement=delete_release 'R9 CN1' > > - the execute fails, because I've set RaiseError => 1. But I wonder > if there is a way to catch this error in the stored procedure, so that > the script doesn't die? Just the $res should be non-zero. Thank you
I think there are two issues here. The first is how to trap this sort of error in the stored procedure. That's purely a Sybase T-SQL issue, and should probably be handled on a Sybase list ([EMAIL PROTECTED] would be a good choice). As for the DBI raiserror issue - that is potentially an issue for DBD::Sybase - I'll try to create a similar setup and see what I can come up with. (btw - you could define a syb_err_handler and have it return 0 for this error which should inhibit the DBI raiserror from firing) Michael -- Michael Peppler - Data Migrations Inc. - http://www.mbay.net/~mpeppler [EMAIL PROTECTED] - [EMAIL PROTECTED] International Sybase User Group - http://www.isug.com
