Viewing 15 posts - 53,446 through 53,460 (of 59,098 total)
A covering index could certainly help... but there's a lot of things that will change an Index Seek into and Index Scan... usually non-sargeable WHERE clauses and ON clauses. ...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 23, 2007 at 12:22 am
Then, it should be a single table. If you make it an "adjacency" (parent/child) model, you may be ok depending on how you're going to drill down and how...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 23, 2007 at 12:20 am
Not only is it a "doosie", but it's darned near a duplicate...
http://www.sqlservercentral.com/Forums/Topic435994-361-1.aspx
--Jeff Moden
Change is inevitable... Change for the better is not.
December 23, 2007 at 12:10 am
Which "above script"... don't waste time, be specific, please.
You also said you wanted to update the table with address info... heh... what if a person has 2 addresses?
--Jeff Moden
Change is inevitable... Change for the better is not.
December 23, 2007 at 12:07 am
Heh... another keen observation is that you still haven't told us how things worked out. 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
December 22, 2007 at 11:58 pm
Crud... I just glanced at the formulas... didn't see that they were subtracting 1 second.
Also, didn't know which artical you were referring to... it doesn't show in the post.
Thanks for...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 22, 2007 at 11:54 pm
I have to admit, I'm confused as to why the question was even asked... the OP had a "Last day of the Month" formula... surely it's an easy deduction to...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 22, 2007 at 8:18 pm
1) Is the design I've built the "right" way to go (see condensed design below)?
2) How do I PIVOT twice?
3) There are roughly 20 tables with strict PK to FK...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 22, 2007 at 8:05 pm
I need to break these 10 tables into 50 tables 1 for each state ... Each state will have its own table... What is the best way to do...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 22, 2007 at 7:47 pm
Heh... says a lot about whether thee and me are normal, huh?
Merry Christmas, Gail.
--Jeff Moden
Change is inevitable... Change for the better is not.
December 22, 2007 at 8:51 am
What's going on is that you're updating the same columns used in the join... that's almost never a good thing because it will frequently cause the join to "reform" after...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 22, 2007 at 8:37 am
Apparently not... I've still not seen the correct answer from Karthik.
--Jeff Moden
Change is inevitable... Change for the better is not.
December 22, 2007 at 8:29 am
Karthik,
This is what I spoke of on one of the other posts... it's also why people get so angry with you. You banter the "Senior Software Engineer" label all...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 21, 2007 at 11:36 pm
Grant is spot on... If you want to avoid RBAR, stop thinking RBAR. The key or "secret" to that is to never ever think about what you want to...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 21, 2007 at 11:24 pm
Now, that's quite an article... some great references, too! Thanks for the research, Steve.
--Jeff Moden
Change is inevitable... Change for the better is not.
December 21, 2007 at 9:23 pm
Viewing 15 posts - 53,446 through 53,460 (of 59,098 total)