Viewing 15 posts - 57,076 through 57,090 (of 59,067 total)
Heh... on Brian's note, Steve... I'm thinking "get the glue".
--Jeff Moden
Change is inevitable... Change for the better is not.
January 1, 2007 at 2:19 pm
Mark,
I'm thinking that you did not try the code. Use the table build code to build the table and the related indexes. Then do an execution plan on the code...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 1, 2007 at 11:36 am
Can you "sticky" this to the SQLServerCentral home page (ie. "How to ask a question and what to do with the answer" section) and force newbies to do a read (wishful...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 1, 2007 at 9:35 am
Make sure you run the code several times where indicated... you'll both be surprised... and remember the situation may change if a join is involved...
--Drop table MyHead
GO
--===== Create...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 31, 2006 at 11:39 pm
Actually, since RedGate just procurred this site, try RedGate SQL Compare ![]()
--Jeff Moden
Change is inevitable... Change for the better is not.
December 28, 2006 at 4:22 pm
Yes, it will fail if your server isn't setup to "see" the path. The SQL Server "service" must be started as a power user that can "see" the UNC path...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 28, 2006 at 7:33 am
IF you will always have 4 columns, then this will work nicely...
DECLARE @TestText VARCHAR(100)
SET @TestText = 'FIN - TIN - LIN - BIN'
SELECT PARSENAME(REPLACE(@TestText,' -...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 27, 2006 at 1:44 pm
You bet, Sol,
Sorry for the apparent rambling
in my last post... was a bit late and I just started typing without much thought to...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 26, 2006 at 6:43 am
James,
I did a search in BOL 2005 and on google... couldn't find reference to a FIRST or LAST function. Probably my problem since I don't use 2005, yet, but do...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 25, 2006 at 9:32 pm
Heh... Good luck, Yves. ![]()
--Jeff Moden
Change is inevitable... Change for the better is not.
December 25, 2006 at 7:00 pm
Kinda like when your car runs bad but you won't let the mechanic pop the hood, isn't it Sol? Heck, I don't even know what your "car" looks like... --Jeff Moden Change is inevitable... Change for the better is not.
RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.
Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)
December 25, 2006 at 12:55 pm
Yep... I realize that my response is a year late, but well done, Chris... Very nice intro to some of the performance measuring tools that are available in SQL Server.
Just...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 25, 2006 at 12:03 pm
Whatever... it's still called a cross-post and will tick off some of the people trying to help because the problem is scattered across 3 posts instead of on a single...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 24, 2006 at 10:07 am
Yeah... kinda... I normally setup a separate database for "staging tables" of large volumes of data being imported. I set the recovery mode to "Simple", as you suggest, and I...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 23, 2006 at 11:00 am
There's no single approach that fits all situations. I've found that there are lots of different factors affecting such a decision... on 24/7 tables, I might use DBCC IndexDefrag because...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 23, 2006 at 9:54 am
Viewing 15 posts - 57,076 through 57,090 (of 59,067 total)