Viewing 15 posts - 51,736 through 51,750 (of 59,098 total)
Balmukund Lakhani (3/17/2008)
SQL Server 2008 would have this feature out-of-the-box.its called Change data capture (CDC)
That's nice... got anything for 2005?
--Jeff Moden
Change is inevitable... Change for the better is not.
March 17, 2008 at 12:23 am
Temp tables and table variables both start out in memory and spill over to disk if they get large enough.
There's a whole lot of minor differences but the big difference...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 17, 2008 at 12:20 am
Correct in some areas, Thomas... you can try the code I posted to verify...
The source data is queried once for each correlated subquery meaning that, with the correct index, 3...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 16, 2008 at 11:54 pm
Thanks, Matt... that'll teach me... I normally do a lot more research and "due diligence" before I post an article. I got in a hurry this time and didn't...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 16, 2008 at 11:34 pm
Ack... sorry Barry... the darned thing doesn't work in 2k5... gives a permissions error. I'm trying to find a back door but it doesn't look promising yet.
--Jeff Moden
Change is inevitable... Change for the better is not.
March 16, 2008 at 11:23 pm
It's a fairly large subject... best bet it to look in Books Online under "BCP". Get familiar with the terms and do a bit of studying... try a couple...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 16, 2008 at 11:21 pm
Tim Mitchell (3/16/2008)
Take them to lunch...
That's step 1 in the porkchop reference 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
March 16, 2008 at 11:07 pm
peer_mohamed2k (3/14/2008)
I have 1,65,00,000 rows [16 million rows] in one table. I am using this table for SQL reports. When I use this table joining with some other tables, my...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 16, 2008 at 9:46 pm
The short answer is NO and sys.tables won't tell you a thing about this.
--Jeff Moden
Change is inevitable... Change for the better is not.
March 16, 2008 at 9:41 pm
Heh... all good methods but they left a really good one out... it's really old fashioned but it works really well... look at the drive... if the little red light...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 16, 2008 at 9:40 pm
Yep... also try sp_helpdb. Not as robust but will tell you the overall size. And thanks for posting even though you found your own answer.
--Jeff Moden
Change is inevitable... Change for the better is not.
March 16, 2008 at 9:37 pm
DECLARE @EndTime DATETIME
DECLARE @StartTime DATETIME
SET @StartTime = GETDATE()
--... code here to be measured for duration
SET @EndTime = GETDATE()
PRINT...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 16, 2008 at 9:35 pm
Dunno if it's any of these... see attached... might be DBCC Buffer or DBCC ProcBuf.
--Jeff Moden
Change is inevitable... Change for the better is not.
March 16, 2008 at 9:16 pm
I found it... it's an article on this forum by a good fellow by the name of David Poole... I had it in my "favorites"...
http://www.sqlservercentral.com/articles/Administering/utilityprocedures/2272/
--Jeff Moden
Change is inevitable... Change for the better is not.
March 16, 2008 at 9:10 pm
kumar99ms (3/16/2008)
could plz tel me is there another way to find out dead lock
How can i rectify this deadlock
Which situvastion it will occure
Blocking and dead lock which...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 16, 2008 at 9:05 pm
Viewing 15 posts - 51,736 through 51,750 (of 59,098 total)