July 14, 2009 at 12:09 pm
Hey,
The developers got an idea that sounds bad to me, but I can't support my opinion really.
They want to send UPDATE statements back to the database every time a field changes. This may be a call to a stored proc, or an on-the-fly generated statement.
This seems like a lot of overhead and round-trips to the database vs one general save routine for a given table.
Wouldn't SQL have to lock the whole row even if they are only updating one field in the row?
Sorry if this is a silly question, any links to articles would be nice, I was not very successful searching for an answer.
July 14, 2009 at 12:31 pm
The best way to do it is to allow a person to edit a record (a record may be more or less than a row in the database) in the UI then click save and update everything all at once. To call the database for each column updated is, IMO, foolish and will lead to performance problems.
Jack Corbett
Consultant - Straight Path Solutions
Check out these links on how to get faster and more accurate answers:
Forum Etiquette: How to post data/code on a forum to get the best help
Need an Answer? Actually, No ... You Need a Question
July 14, 2009 at 1:23 pm
I agree. That's a pretty poor choice for design. Not to mention the horrible chattiness of the app on your network, it's going to cause some major league contention within your database.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply