Viewing 15 posts - 56,461 through 56,475 (of 59,086 total)
Yeah... that's what I mean
Stuff like that...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 14, 2007 at 6:02 am
Heh... my boss' boss says that all the time... it's why our projects seem to go in so fast... who cares if it takes six months extra to fix what we...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 14, 2007 at 6:00 am
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
Viewing 15 posts - 56,461 through 56,475 (of 59,086 total)