Viewing 15 posts - 46,756 through 46,770 (of 59,095 total)
Christopher Stobbs (12/1/2008)
Which would you consider to be a better query:
I would go with query 2 cause it uses a join rather than like in query one it uses...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 6, 2008 at 6:22 pm
Periodic "Log Shipping" or on demand "Replication" would do it.
--Jeff Moden
Change is inevitable... Change for the better is not.
December 6, 2008 at 5:18 pm
Heh... now THAT's funny!
--Jeff Moden
Change is inevitable... Change for the better is not.
December 6, 2008 at 5:16 pm
Alan! How about a little test data? This isn't difficult but it's impossible to solve in a reasonable fashion without a copy of your field table and a...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 6, 2008 at 5:14 pm
Two things... first, post the code that you've tried. Second, if you want a better answer quicker, please see the link in my signature line below. 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
December 6, 2008 at 4:57 pm
Just add the "IGNORE DUPES" option to the Primary Key constraint.
--Jeff Moden
Change is inevitable... Change for the better is not.
December 6, 2008 at 4:55 pm
Sorry, Gift Peddie... Wasn't directed at you or I'd have used your post as a quote. No... I've heard this myth about using powers of 2 for varchar lengths...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 6, 2008 at 4:46 pm
Stuff like that shouldn't be hardcoded. It should be in a configuration table.
--Jeff Moden
Change is inevitable... Change for the better is not.
December 6, 2008 at 4:41 pm
Mike Levan (12/5/2008)
above query pulls 20k records in 24min, i thing its not gud though my indexes are all doing good.
Why do you think your indexes are "all doing good"?...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 6, 2008 at 4:39 pm
For a better, tested answer quicker. please see the link in my signature below.
--Jeff Moden
Change is inevitable... Change for the better is not.
December 6, 2008 at 4:30 pm
The rowcounts in the SysIndexes table may not be anywhere near accurate until you run DBCC UPDATEUSAGE.
--Jeff Moden
Change is inevitable... Change for the better is not.
December 6, 2008 at 4:26 pm
BWAA-HAAA! Don't you guys know "vapor-ware" when you see it? It's obviously a "future release". :D:P:hehe:
--Jeff Moden
Change is inevitable... Change for the better is not.
December 6, 2008 at 4:21 pm
Dynamic SQL to run a cursor... how slow do you actually want things to run?
I agree with what the others have already stated... it would be fair better to state...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 6, 2008 at 4:19 pm
If you simply behead the first two people that make that mistake, I guarantee the others will be much more careful. 😛
--Jeff Moden
Change is inevitable... Change for the better is not.
December 6, 2008 at 4:15 pm
Ok then... anyone anywhere got any consistant demonstrable code of any type that shows any consistant performance increase using any power-of-2 length for any Varchar sitiuation in any table? ...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 6, 2008 at 4:11 pm
Viewing 15 posts - 46,756 through 46,770 (of 59,095 total)