Viewing 15 posts - 58,396 through 58,410 (of 59,067 total)
Jennifer,
I agree with Serqiy...
SELECT STR(yourcolumn,10,4)
FROM yourtable...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 20, 2006 at 6:59 pm
Not quite true... table variables are also connection sensitive...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 16, 2006 at 10:07 pm
Jesper... I don't believe your formula works correctly...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 16, 2006 at 10:03 pm
Ya just gotta love what Microsoft did with their execution plans
... I absolutely agree that both execution plans came out the same for...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 16, 2006 at 6:30 pm
Funny, I just posted a similar solution to remove everything except 0-9...
If you don't already have a "Tally" table, now's the time to make one... here's the code to make...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 16, 2006 at 12:43 am
Govinn,
If you don't already have a "Tally" table, now's the time to make one... here's the code to make a Tally table...
--===== Create and populate a Tally table...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 16, 2006 at 12:04 am
Yep... for starters...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 13, 2006 at 8:28 pm
Steve,
What is the datatype of the column you are storing this data in?
--Jeff Moden
Change is inevitable... Change for the better is not.
February 13, 2006 at 6:07 pm
Just a couple of things...
If the Inserts will, more or less, be in order by [Date], then having a Clustered Index on date will be OK, otherwise, the Inserts will...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 13, 2006 at 4:26 am
Yeah, but, good Lord... don't use a cursor to find and delete dupes (or for anything else for that matter)... here's a fully commented template for deleting dupes... you could...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 12, 2006 at 8:59 pm
Ron,
This is what I posted on the "other" forum you posted the same question on...
> First, I have to do due diligence... what you're suggesting is, for so many reasons,...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 11, 2006 at 7:00 pm
Bullfrog,
I'm thinking that your times are a bit screwed up in your example data... they're all 8:23:00. But, I'm thinking we get the idea...
The hard part is, I can figure...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 11, 2006 at 6:58 pm
If you just want duration and not actual CPU seconds used, then something like this works...
--===== Declare a couple of variables to measure duration
DECLARE @StartTime DATETIME
DECLARE @EndTime DATETIME
--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)
February 10, 2006 at 11:48 pm
Hi Tushar,
Look up "cross-tab reports" in Books Online... it has a great example of how to do a "Cross Tab" which some call a "Pivot". If you want true pivots,...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 10, 2006 at 11:39 pm
Absolutely... and that, in fact, your suggestion would definitely be the best way to solve the problem, but someone wanted me to demo using DATEDIFF as both a filter and...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 6, 2006 at 6:09 am
Viewing 15 posts - 58,396 through 58,410 (of 59,067 total)