Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
r2dhart
Starting Member
3 Posts |
 Posted - 2008-08-14 : 09:35:37
|
I am interested in knowing how others deal with Updates in thier applications. I've tried a number of methods over the years and each has it's benefits and drawbacks.A few of the common ones:1 - Dynamically build an update statement in your executable code and run it against the database. Simple and effective, but not the most efficient way to do it.2 - Build a sproc that updates all of the fields whether they need it or not. Seems a bit wasteful but it's usually what I do.3 - Build a seperate update sproc for each field in the table. A management nightmare  (I only did this once).4 - Dynaicaly build a the "Set" portion of the statement in code and pass it to a sproc. I don't know if this is any more efficient than number 1 and I really don't like splitting up the code like that unless there is a significant benefit.So as I said I'd like to hear from others how they have addressed this problem. |
|
|
X002548
Not Just a Number
15586 Posts |
|
|
blindman
Master Smack Fu Yak Hacker
2365 Posts |
Posted - 2008-08-14 : 14:29:58
|
| Most front-end apps deal with the record as a distinct object, and therefor have no problem passing all the record values back through a single update procedure. Option 2.I don't even want to talk about option 3. If you promise never to mention it again, I won't either.Boycott Beijing Olympics 2008 |
 |
|
|
|
|
|
Update Strategies