Hi,

I got a reply from our tech guys, who said that auto update statistics was set to true, and in addition to that they were running sp_updatestats once a...

I'd be...

Thank you, a good article!

Not a lot of it applies to my issue I think (I may be wrong as I don't know the exact cause of my problem)...

Thanks for all your thoughts and comments. Currently it's working out okay when we delete 5000 rows performance wise, and there doesn't appear to be any locking issues. I assume...

GilaMonster (3/3/2009)

---

A clustered index is always unique. The only question is do you make it unique, or does SQL...

Depends on how you see it I guess, but

Alabama ...

People are too concerned with consistency and theoretical issues. Why all this worry about having the clustered index unique? 🙂

Making a clustered surrogate key (that you won't really use in...

A lookup table like you are suggesting with one row per state per bracket range makes sense.

Ab5sr, Thanks for your suggestion - I guess it might be worth a try to minimize the potential performance hit. I'll give this a try in our staging environment...

How many records will a query like this typically return?

It looks to me like you need a clustered index on client_Id in your gl-table. An alternate approach to try...

As your SP has several operations - figuring out what is actually the slow part is probably a good way to start instead of just rewriting it in a number...

I guess it is a design issue where to put your logic, and this may not be good advice on a database forum - but I like to keep the...

ab5sr (3/3/2009)

---

I was at a client with a similar situation. For their application, constantly searching for data across tables such as this in the OLTP environment resulted in poor performance;...

Hey, thanks for the replies.

We have the enterprise edition - and runs an online payment gateway, so we have traffic around the clock - no real "slow" period. The...