Viewing 15 posts - 56,446 through 56,460 (of 59,069 total)
Thanks, guys. Yeah, the only thing I could think of was a minimal logging bulk insert staging table but he's not using it for that... it's a permanent cross-reference table...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 14, 2007 at 5:57 am
Who are you and what have you done with the real Serqiy? The real Serqiy I know would have said something about going back and fixing the database so there...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 13, 2007 at 9:08 pm
Don't use ISQL.exe for any batch process... it is severely deprecated... use OSQL.exe instead.
--Jeff Moden
Change is inevitable... Change for the better is not.
May 13, 2007 at 9:05 pm
I'm thinking somebody is going to need a comma or two in there ![]()
--Jeff Moden
Change is inevitable... Change for the better is not.
May 13, 2007 at 9:02 pm
Please explain what you mean by "when it rolls over into the next range". Also, it's been 2 months and you still haven't posted the exact error message. Might also...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 13, 2007 at 8:43 pm
While this may sound incredibly simple, it is also incredibly common... have the network guy check the "duplex" on all the "boxes" in the connection chain to that remote server......
--Jeff Moden
Change is inevitable... Change for the better is not.
May 12, 2007 at 4:22 pm
I think "business intelligence" is a bit of an oxy-moron when it comes to management... if you can't get them to invest in intelligent/skilled people to run and protect their...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 12, 2007 at 4:13 pm
Just my 2 cents... My testing shows that following all have identical execution plans and they all take an average of 1004 milliseconds to run...
DECLARE @BitBucket INT
--===== WHERE...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 11, 2007 at 11:55 pm
Timeouts frequently have nothing to do with duration.... sometimes if tables are locked for update by a long running explicit transaction, you can get a timeout almost immediately.
--Jeff Moden
Change is inevitable... Change for the better is not.
May 11, 2007 at 6:47 am
Also, don't forget... that if you have any VARCHAR columns > 4000 characters, you could have a serious problem with truncation...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 11, 2007 at 6:38 am
And please provide the query that allowed you to select which rows you want deleted! Stop making us guess!
--Jeff Moden
Change is inevitable... Change for the better is not.
May 11, 2007 at 6:32 am
Nah... you can get INDEX SEEKS out of non-clustered indexes... they just won't be CLUSTERED INDEX SEEKS. And, (as you know, ol' friend), I don't think they'll come close to...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 9, 2007 at 12:41 am
You'll never do better than an INDEX SCAN with all the queries written so far... not sure there's one better, either. Might be able to tweek a couple of things...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 8, 2007 at 5:24 pm
I don't remember where I got these from... they seem to work... of course, the spreadsheet must already exist but you can make a master template, copy it to a...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 8, 2007 at 5:11 pm
That'll definitely work although it doesn't do much for the amout of time it will take with all the indexes the orginal poster portrayed. Not sure it'll do much for...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 8, 2007 at 4:24 pm
Viewing 15 posts - 56,446 through 56,460 (of 59,069 total)