Viewing 15 posts - 41,791 through 41,805 (of 59,067 total)
Hugo Kornelis (9/24/2009)
--Jeff Moden
Change is inevitable... Change for the better is not.
September 24, 2009 at 4:57 pm
Hugo Kornelis (9/24/2009)
Based on visual inspection of your code, I fail to see any way that this code could cause "gaps" in the tally table. I think what you...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 24, 2009 at 4:52 pm
Lynn Pettis (9/23/2009)
Also, the DATE data type does make sense in those areas where time is not needed, such as DateHired, DateTerminated. Who cares what the time is there.
Heh......
--Jeff Moden
Change is inevitable... Change for the better is not.
September 24, 2009 at 2:34 pm
DavidL (9/24/2009)
--===== Presets
DECLARE @DateStart DATETIME
DECLARE @DateEnd DATETIME
SELECT @DateStart = '2008-01-01 06:00',
...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 24, 2009 at 2:25 pm
I also need to know how many rows you actually have in your Tally table, please.
--Jeff Moden
Change is inevitable... Change for the better is not.
September 24, 2009 at 2:19 pm
DECLARE @DateStart DATETIME
DECLARE @DateEnd DATETIME
--===== Find the min and max dates in the range of data
SELECT @DateStart = MIN(SalesDate),
@DateEnd...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 24, 2009 at 2:18 pm
Gosta Munktell (9/23/2009)Quick and dirty?
Heh... very... it's quite easy to do exactly the same thing in T-SQL.
--Jeff Moden
Change is inevitable... Change for the better is not.
September 23, 2009 at 4:14 pm
David Kranes (9/23/2009)
Sorry for the delay in providing this. I have attached the DDL.
Where? Not on that post...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 23, 2009 at 4:11 pm
amos-870870 (9/23/2009)They split the time the way they did I believe because it was the straight forward way to accomplish what they wanted to do with their front end application....
--Jeff Moden
Change is inevitable... Change for the better is not.
September 23, 2009 at 4:10 pm
RBarryYoung (9/23/2009)
Great article, Lynn! I might finally be ready to stop cross-joining master..syscolumns. 🙂
I already quit... heh... I use Master.sys.All_Columns now. 😛
--Jeff Moden
Change is inevitable... Change for the better is not.
September 23, 2009 at 4:02 pm
Steve Jones - Editor (9/23/2009)
Don't know. That sounds like employment for life! Might be THE place to work.
BWAA-HAAA!!! Hadn't thought about it THAT way! You could be right!
--Jeff Moden
Change is inevitable... Change for the better is not.
September 23, 2009 at 11:41 am
Thanks Bradley and JJ. Just in case you're interested, "Part 2" can be found at the following URL:
http://www.sqlservercentral.com/articles/Crosstab/65048/
It covers how to make/automate dynamic crosstabs for reporting purposes.
--Jeff Moden
Change is inevitable... Change for the better is not.
September 23, 2009 at 9:25 am
marco-870908 (9/22/2009)
Anyway it is my firm belief that such protections should be validated once where user-input comes into the system
Roger that! One of my favorite sayings is that "If...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 22, 2009 at 9:17 pm
Lots'o good code coming out of this discussion... Haven't tested that last one for speed on the same machine that I've been testing on, but it'll gen more numbers than...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 22, 2009 at 9:14 pm
Heh... it was during my testing. I'll check this on the same machine tomorrow to keep the apples'n'oranges thing from happening.
--Jeff Moden
Change is inevitable... Change for the better is not.
September 22, 2009 at 9:00 pm
Viewing 15 posts - 41,791 through 41,805 (of 59,067 total)