Beginning Microsoft SQL Server 2008 ... - S3 Tech Training

Chapter 12: Stored Procedures
SQL Server won’t perform this insert for you because there is a FOREIGN KEY constraint on both
BusinessEntityID and PersonID that references other tables. Since there is not a matching record in
both tables, the record we are trying to insert into Person.BusinessEntityContact violates both of
those foreign key constraints and is rejected:
Msg 547, Level 16, State 0, Line 1
The INSERT statement conflicted with the FOREIGN KEY constraint
“FK_BusinessEntityContact_Person_PersonID”. The conflict occurred in database
“AdventureWorks2008”, table “Person.Person”, column ‘BusinessEntityID’.
The statement has been terminated.
Pay attention to that error 547 up there — that’s something of which we can make use.
It’s worth noting that just the first foreign-key violation shows up in the error SQL Server provided.
This is because SQL Server got to that error, saw it, and knew there was no point in going further. If we
fixed the first error, then the second would be detected and we would again error out.
Making Use of @@ERROR
380
We already talked some about this bad boy when we were looking at scripting, but it’s time to get a lot
friendlier with this particular system function.
To review, @@ERROR contains the error number of the last T-SQL statement executed. If the value is zero,
then no error occurred. This is somewhat similar to the ERROR_NUMBER() function we saw in the last
chapter when we first discussed TRY/CATCH blocks. While ERROR_NUMBER() is only valid within a
CATCH block (and remains the same regardless of where you are within that CATCH block), @@ERROR
receives a new value with each statement you execute.
The caveat with @@ERROR is that it is reset with each new statement. This means that
if you want to defer analyzing the value, or you want to use it more than once, you
need to move the value into some other holding bin — a local variable that you have
declared for this purpose.
Play with this just a bit using the INSERT example from before:
USE AdventureWorks2008;
GO
DECLARE @Error int;
-- Bogus INSERT - there is no PersonID or BusinessEntityID of 0. Either of
-- these could cause the error we see when running this statement.
INSERT INTO Person.BusinessEntityContact
(BusinessEntityID
,PersonID
,ContactTypeID)
VALUES
(0,0,1);
-- Move our error code into safekeeping. Note that, after this statement,
-- @@Error will be reset to whatever error number applies to this statement