From: Andy B. on
I have a stored procedure that inserts a row into a table. When someone
tries to insert a row and violates a unique constraint, should I only return
2601 and force the client to figure out what the problem was? or should I
return a 1 row resultset with the 2601 and a formatted string explaining
what went wrong? Any ideas?


From: Uri Dimant on
Hi
Another option is to check within a stored procedure that value and NOT
inserting a wron value , something like that

IF NOT EXISTS (SELECT * FROM tbl WHERE col=(a)col)---does not exist
INSERT INTO .....




"Andy B." <a_borka(a)sbcglobal.net> wrote in message
news:uVBQ4RQxKHA.4240(a)TK2MSFTNGP06.phx.gbl...
>I have a stored procedure that inserts a row into a table. When someone
>tries to insert a row and violates a unique constraint, should I only
>return 2601 and force the client to figure out what the problem was? or
>should I return a 1 row resultset with the 2601 and a formatted string
>explaining what went wrong? Any ideas?
>


From: Plamen Ratchev on
As Uri noted it may be best to prevent this from happening at all. If you prefer to send error, then it is really your
preference on how you handle errors. I would normally just raise an error with the message and then handle this in the
app layer.

--
Plamen Ratchev
http://www.SQLStudio.com
From: Andy B. on
Got it. Decided to raise the error with try...catch. I will send the sql
server error number along with a descriptive error message that a non
programmer (user error) could understand. I.e.:

select @error_number as number, @error_message as message;
-- results on a failure:

number message
2601 The headline could not be added because one with that title
already exists.

-- if the insert succeeded.
number message
0 The headline was successfully saved.
--end sample output.
"Plamen Ratchev" <Plamen(a)SQLStudio.com> wrote in message
news:VqednWd54t1HCALWnZ2dnUVZ_velnZ2d(a)speakeasy.net...
> As Uri noted it may be best to prevent this from happening at all. If you
> prefer to send error, then it is really your preference on how you handle
> errors. I would normally just raise an error with the message and then
> handle this in the app layer.
>
> --
> Plamen Ratchev
> http://www.SQLStudio.com