Quote:
Originally Posted by tdewey
When creating the Stored Procedure for UPDATE, I copied the SET NOCOUNT ON statement from the Insert procedure. This statement inhibits the count of rows affected and returns a minus one.
|
Yes, exactly. If you SET NOCOUNT ON in the update stored procedure, the stored procedure will always return -1.
That means the UpdateArticle method in SqlArticlesProvider will always return false.
This happens even when the update is successful.
The important thing to remember is that the fact that UpdateArticle returns false has absolutely nothing to do with whether the update operation was successful. You have
forced it to always return false because you have SET NOCOUNT ON.
The same thing applies with Insert and Delete. If you SET NOCOUNT ON, then the interger that would normally be returned by executing the query will always be -1.
This is why it is common to SET NOCOUNT ON when doing an insert. When doing an insert, the return value you are interested in is usually the ID of the newly inserted article, not the number of rows affected.
However, it is common to leave the count enabled when doing updates and deletes. When doing updates and deletes, the number of rows affected is important information.
BOTTOM LINE: - It is generally okay to SET NOCOUNT ON for inserts if you are returning the ID of the newly inserted item.
- For updates and deletes, you should not SET NOCOUNT ON. You should let the sproc return the number of rows affected.
Does that make sense?