Home/ Questions/Q 411595
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-12T18:00:08+00:00

So I came across an instance where a stored procedure which handled the Updates

  • 0

So I came across an instance where a stored procedure which handled the Updates on a specific table was doing nothing because the record didn’t exist [duh].

So what I decided to do was change the stored procedure to:

 UPDATE    Table
 SET       col1 = @var1
 WHERE     Type = @type AND UserId = @userId 
 IF @@ROWCOUNT = 0
 BEGIN
  INSERT INTO Table
---etc....
 END

So this obviously solved the problem and I renamed the sproc from UpdateTable to SetTable.

Is this a good idea, or should I do something at the application level where if the update returns 0 rows affected, call the insert procedure.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I prefer the “upsert” that you have shown because it allows me to stay that much further away from persistence related logic. In the application I just want to work with my objects and “if I must” ask them to save / persist. With update and insert separately you are forced to think about this in the domain model. But the biggest advantage to persistence ignorance is that you can focus on real business problems instead of infrastructure concerns.

    This design also helped me migrate to an ORM earlier this year because I didn’t have a ton of “update” / “insert” calls, but instead a simple “save”

    • 0