G
Guest
OK...
Can't find alot about this but by reading .NET sqlError and
sqlErrorCollection I would hope I would get the same behavior issuing calls
to SQL Server 2000 sprocs. The problem...unless you use
sqlCommand.ExecuteNonQuery() you will only receive one sqlError (i.e. use the
sqlDataAdapter.Fill() to reproduce) no matter how many times you issue a
RAISEERROR (severity 11 in this example) in the spocs. Yet if I use the same
call through ExecuteNonQuery() and my sproc calls RAISEERROR more than once
(severity level 11), I get all raises in sqlErrorCollection. Cmon....why the
inconsistent behavior? Just because someone does Fill()...doesn't mean the
script is doing otherthings than fetching rows...I would like more
information from my sprocs than just the original unique constraint violation
(as an example)...hence the many RAISERRORS through the sprocs and subsprocs
I have coded...
Is this a feature or bug? Why is the behavior not doumented? Any thoughts or
solutions or fixes?
Can't find alot about this but by reading .NET sqlError and
sqlErrorCollection I would hope I would get the same behavior issuing calls
to SQL Server 2000 sprocs. The problem...unless you use
sqlCommand.ExecuteNonQuery() you will only receive one sqlError (i.e. use the
sqlDataAdapter.Fill() to reproduce) no matter how many times you issue a
RAISEERROR (severity 11 in this example) in the spocs. Yet if I use the same
call through ExecuteNonQuery() and my sproc calls RAISEERROR more than once
(severity level 11), I get all raises in sqlErrorCollection. Cmon....why the
inconsistent behavior? Just because someone does Fill()...doesn't mean the
script is doing otherthings than fetching rows...I would like more
information from my sprocs than just the original unique constraint violation
(as an example)...hence the many RAISERRORS through the sprocs and subsprocs
I have coded...
Is this a feature or bug? Why is the behavior not doumented? Any thoughts or
solutions or fixes?