Viewing 15 posts - 46,756 through 46,770 (of 59,101 total)
If you didn't use Gail's solution, would you mind posting your solution, please?
--Jeff Moden
Change is inevitable... Change for the better is not.
December 6, 2008 at 7:13 pm
Can't the TEXT column be changed to a VARCHAR(MAX) column?
--Jeff Moden
Change is inevitable... Change for the better is not.
December 6, 2008 at 7:11 pm
Create a temporary stored procedure, instead. You know... one that begins with a "#" sign. 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
December 6, 2008 at 7:07 pm
Heh... one religous battle coming up... ready?
NEVER DELETE! NEVER REUSE PK's!
--Jeff Moden
Change is inevitable... Change for the better is not.
December 6, 2008 at 7:02 pm
Sorry... forgot to post the results I got... single P4 1.8Ghz, 1GB RAM, 80GB IDE hard drive, SQL Server 2005 Dev Edition SP2...
(1 row(s) affected)
Table '#Client_____________________________________________________________________________________________________________00000000006E'.
Scan count 1,...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 6, 2008 at 6:57 pm
Actually, I'll take door #3 😛 ... performance is the same as WHERE EXISTS and it's even easier to read especially for newbies that may be on the team...
SET STATISTICS...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 6, 2008 at 6:51 pm
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
Viewing 15 posts - 46,756 through 46,770 (of 59,101 total)