Re: Update Query Runs Forever
- From: "Plamen Ratchev" <Plamen@xxxxxxxxxxxxx>
- Date: Tue, 3 Jun 2008 23:53:31 -0400
"Neil" <nospam@xxxxxxxxxx> wrote in message news:jVn1k.4024$co7.2050@xxxxxxxxxxxxxxxxxxxxxxx
Just curious: what kind of trouble down the road would using * cause? I would think it would prevent trouble down the road since, if the fields change, it automatically uses the current fields at all times. What kind of trouble are you referring to.
If you add a column to one of the tables, the statement using "*" will cause your trigger to fail. You make the assumption that someone who will change one of the tables later on will know about this trigger and the process of archiving to another table, but what if not? Even you did not think about the trigger when seeing this performance problem at first...
Also, a question: do you have any idea why the update query and trigger worked when there were 200 rows being updated, but not 1200?
If you have concurrent users running queries on the table, a transaction that updates 200 rows may have a chance for time span to complete in between user queries. But a transaction that updates 1200 rows one at a time takes more than 10 times longer and gets blocked. A set based update may be very fast for 1200 rows, but the cursor you use is not.
HTH,
Plamen Ratchev
http://www.SQLStudio.com
.
- Follow-Ups:
- Re: Update Query Runs Forever
- From: Plamen Ratchev
- Re: Update Query Runs Forever
- References:
- Re: Update Query Runs Forever
- From: Plamen Ratchev
- Re: Update Query Runs Forever
- Prev by Date: Re: Update Query Runs Forever
- Next by Date: Re: Update Query Runs Forever
- Previous by thread: Re: Update Query Runs Forever
- Next by thread: Re: Update Query Runs Forever
- Index(es):
Relevant Pages
|
Loading