August 17, 2010 at 12:13 pm
Hi All, I have a table with following structure:
ID
DATETIME
ID will be generated for different timestamps.
I have a small query to be written which will return the count of ID's date wise. I have writen the script as follows:
select dateadd(day, datediff(day, '99991231', datetime), '99991231'),
count(id) as ABCD
from tablename
group by dateadd(day, datediff(day, '99991231', datetime), '99991231')
order by dateadd(day, datediff(day, '99991231', datetime), '99991231'
THE ISSUE IS THAT : this returns the data only for the dates for which records are available.
Need the query to return count of id as ZERO in case no record for that date exists..
Please suggest ASAP.
August 17, 2010 at 2:26 pm
Check the following article by Jeff Moden on using a Tally table..
http://www.sqlservercentral.com/articles/T-SQL/62867/
towards the bottom there's a dozens of other uses section. I think it should get you pointed in the direction you need to head.
-Luke.
August 17, 2010 at 8:22 pm
Heh... maybe I've taken things to far. No one has to write code about the Tally table anymore. π
--Jeff Moden
Change is inevitable... Change for the better is not.
August 18, 2010 at 6:10 am
Jeff, one of the best parts of your articles are the clear concise, well formatted/documented real world code examples that can be easily understood and implemented. There's just no way I could have explained it better.
It's interesting though that this was the second thread in a row where someone had posted, read Jeff's tally table article. Look at the code under heading X understand and use it.
Seems like that's the mark of very, very good reference material π
-Luke.
August 18, 2010 at 6:09 pm
Gosh, Luke... :blush: You've absolutely made my week... maybe my year. I'm humbled by your incredible comments. I really appreciate your feedback because I've had a whole lot of "well meaning" folks say that I'm a bit too "folksy" in my articles and that I should "write more professionally rather than writing like someone talks". I just can't bring myself to do such a thing because I know how I like to be taught and I write the same way as that. Heh... and, NO, I AM NOT SMARTER THAN A 5TH GRADER. π
--Jeff Moden
Change is inevitable... Change for the better is not.
August 18, 2010 at 6:51 pm
Luke L (8/18/2010)
Jeff, one of the best parts of your articles are the clear concise, well formatted/documented real world code examples that can be easily understood and implemented. There's just no way I could have explained it better.
Seems like that's the mark of very, very good reference material π
-Luke.
AGREED - I have learned a tremendous amount from Jeff's articles. Especially coming from a GUI development position and new to T-SQL. Just hope others listen and learn as I did.
Thamks Jeff
August 19, 2010 at 1:27 pm
You're welcome, Ron, and thanks for the feedback. I knew I did ok... just had no idea of how ok. Thanks, guys.
--Jeff Moden
Change is inevitable... Change for the better is not.
August 19, 2010 at 1:40 pm
Jeff, I'd say you do a fair bit more than just OK, I appreciate the humility, but in this case I don't think it's warranted. As far as the folksy stuff bah, more times than not easy to read and understand trumps dry technical writing every day and twice on Sunday for me. But like I said before it's the examples you choose to illustrate your points that really does it for me.
They are real world problems that many people face (just like the OP here), not some contrived example put forth to show a trick that will work only in some very narrow situation... While those examples can be fun to read and try to understand, code that I will need and be able to apply tomorrow or next week instead of 2 years down the road is what I read these articles for.
-Luke.
August 19, 2010 at 2:39 pm
m.kadlag (8/17/2010)
Hi All, I have a table with following structure:ID
DATETIME
ID will be generated for different timestamps.
I have a small query to be written which will return the count of ID's date wise. I have writen the script as follows:
THE ISSUE IS THAT : this returns the data only for the dates for which records are available.
Need the query to return count of id as ZERO in case no record for that date exists..
Please suggest ASAP.
So, I've got to ask... are you all set on this?
--Jeff Moden
Change is inevitable... Change for the better is not.
August 20, 2010 at 4:43 am
Hi,
I faced a similar situation when I need to get the list of all the tables with the index on them. I had to show null for the those tables also that dont have any index, so I wrote below given script. You may want to use the similar kind of script for your requirement.
* you can use ISNULL() function to replace the null values with 0 in the result set as you have specified. I wanted to show NULL so I didnt use that here.
Hope this helps π
DECLARE @TABLE_NAME SYSNAME
DECLARE @INDEX_NAMESYSNAME
DECLARE @INDEX_KEYSVARCHAR(3000)
DECLARE @INDEX_TYPEVARCHAR(1000)
IF EXISTS (SELECT 1 FROM TEMPDB..SYSOBJECTS WHERE NAME LIKE '%#TABLE_INDEX_INFO%')
BEGIN
DROP TABLE #TABLE_INDEX_INFO
END
CREATE TABLE #TABLE_INDEX_INFO
(
S_NO INT IDENTITY (1,1),
TABLE_NAME SYSNAME ,
INDEX_NAME SYSNAME,
INDEX_TYPE VARCHAR(1000),
INDEX_KEYS VARCHAR(3000)
)
IF EXISTS (SELECT 1 FROM TEMPDB..SYSOBJECTS WHERE NAME LIKE '%#SP_HELP_INDEX_RESULTS%')
BEGIN
DROP TABLE #SP_HELP_INDEX_RESULTS
END
CREATE TABLE #SP_HELP_INDEX_RESULTS
(
INDEX_NAME SYSNAME,
INDEX_TYPE VARCHAR(1000),
INDEX_KEYS VARCHAR(3000)
)
DECLARE CUR_TABLES CURSOR FAST_FORWARD
FOR SELECT NAME FROM SYS.TABLES WHERE TYPE = 'U'
OPEN CUR_TABLES
FETCH NEXT FROM CUR_TABLES INTO @TABLE_NAME
WHILE @@FETCH_STATUS = 0
BEGIN
TRUNCATE TABLE #SP_HELP_INDEX_RESULTS
INSERT INTO #SP_HELP_INDEX_RESULTS (INDEX_NAME,INDEX_TYPE,INDEX_KEYS) EXECUTE SP_HELPINDEX @TABLE_NAME
INSERT INTO #TABLE_INDEX_INFO (TABLE_NAME,INDEX_NAME,INDEX_KEYS,INDEX_TYPE)
SELECT @TABLE_NAME,INDEX_NAME,INDEX_KEYS,INDEX_TYPE FROM #SP_HELP_INDEX_RESULTS
FETCH NEXT FROM CUR_TABLES INTO @TABLE_NAME
END
CLOSE CUR_TABLES
DEALLOCATE CUR_TABLES
SELECT DB_NAME() as 'Database', T.NAME AS 'TableName',TI.INDEX_NAME as 'IndexName',TI.INDEX_KEYS as 'IndexKeys',TI.INDEX_TYPE as 'IndexType'
FROM SYS.TABLES T LEFT OUTER JOIN #TABLE_INDEX_INFO TI
ON T.NAME = TI.TABLE_NAME
ORDER BY T.NAME
-Sujeet
August 20, 2010 at 8:55 am
sujeetps (8/20/2010)
Hi,I faced a similar situation when I need to get the list of all the tables with the index on them. I had to show null for the those tables also that dont have any index, so I wrote below given script. You may want to use the similar kind of script for your requirement.
* you can use ISNULL() function to replace the null values with 0 in the result set as you have specified. I wanted to show NULL so I didnt use that here.
Hope this helps π
DECLARE @TABLE_NAME SYSNAME
DECLARE @INDEX_NAMESYSNAME
DECLARE @INDEX_KEYSVARCHAR(3000)
DECLARE @INDEX_TYPEVARCHAR(1000)
IF EXISTS (SELECT 1 FROM TEMPDB..SYSOBJECTS WHERE NAME LIKE '%#TABLE_INDEX_INFO%')
BEGIN
DROP TABLE #TABLE_INDEX_INFO
END
CREATE TABLE #TABLE_INDEX_INFO
(
S_NO INT IDENTITY (1,1),
TABLE_NAME SYSNAME ,
INDEX_NAME SYSNAME,
INDEX_TYPE VARCHAR(1000),
INDEX_KEYS VARCHAR(3000)
)
IF EXISTS (SELECT 1 FROM TEMPDB..SYSOBJECTS WHERE NAME LIKE '%#SP_HELP_INDEX_RESULTS%')
BEGIN
DROP TABLE #SP_HELP_INDEX_RESULTS
END
CREATE TABLE #SP_HELP_INDEX_RESULTS
(
INDEX_NAME SYSNAME,
INDEX_TYPE VARCHAR(1000),
INDEX_KEYS VARCHAR(3000)
)
DECLARE CUR_TABLES CURSOR FAST_FORWARD
FOR SELECT NAME FROM SYS.TABLES WHERE TYPE = 'U'
OPEN CUR_TABLES
FETCH NEXT FROM CUR_TABLES INTO @TABLE_NAME
WHILE @@FETCH_STATUS = 0
BEGIN
TRUNCATE TABLE #SP_HELP_INDEX_RESULTS
INSERT INTO #SP_HELP_INDEX_RESULTS (INDEX_NAME,INDEX_TYPE,INDEX_KEYS) EXECUTE SP_HELPINDEX @TABLE_NAME
INSERT INTO #TABLE_INDEX_INFO (TABLE_NAME,INDEX_NAME,INDEX_KEYS,INDEX_TYPE)
SELECT @TABLE_NAME,INDEX_NAME,INDEX_KEYS,INDEX_TYPE FROM #SP_HELP_INDEX_RESULTS
FETCH NEXT FROM CUR_TABLES INTO @TABLE_NAME
END
CLOSE CUR_TABLES
DEALLOCATE CUR_TABLES
SELECT DB_NAME() as 'Database', T.NAME AS 'TableName',TI.INDEX_NAME as 'IndexName',TI.INDEX_KEYS as 'IndexKeys',TI.INDEX_TYPE as 'IndexType'
FROM SYS.TABLES T LEFT OUTER JOIN #TABLE_INDEX_INFO TI
ON T.NAME = TI.TABLE_NAME
ORDER BY T.NAME
-Sujeet
Correct... the ISNULL() function could be the thing to use here. But, the original problem doesn't have a given date to use the ISNULL() function on for any dates that are missing like your table index example does.
--Jeff Moden
Change is inevitable... Change for the better is not.
August 20, 2010 at 8:57 am
Jeff Moden (8/19/2010)
m.kadlag (8/17/2010)
Hi All, I have a table with following structure:ID
DATETIME
ID will be generated for different timestamps.
I have a small query to be written which will return the count of ID's date wise. I have writen the script as follows:
THE ISSUE IS THAT : this returns the data only for the dates for which records are available.
Need the query to return count of id as ZERO in case no record for that date exists..
Please suggest ASAP.
So, I've got to ask... are you all set on this?
Kadlag... you wanted help "ASAP". The courtesy of a reply to my question above is in order here.
--Jeff Moden
Change is inevitable... Change for the better is not.
August 20, 2010 at 9:11 am
Jeff Moden (8/18/2010)
... I've had a whole lot of "well meaning" folks say that I'm a bit too "folksy" in my articles and that I should "write more professionally rather than writing like someone talks"...
Ignore them, Jeff. People vote with their fingertips. Try and count 'em. What puts your articles head and shoulders above many is the 'digestibility'. The tally table used to be an advanced concept but with your clear and digestible explanation of how it works, it's now just another tool in every TSQL developers' box.
Stick to "folksy". We like reading it, you like writing it. Seemples! <<squeak>>
For fast, accurate and documented assistance in answering your questions, please read this article.
Understanding and using APPLY, (I) and (II) Paul White
Hidden RBAR: Triangular Joins / The "Numbers" or "Tally" Table: What it is and how it replaces a loop Jeff Moden
August 20, 2010 at 1:07 pm
Chris Morris-439714 (8/20/2010)
'digestibility'. The tally table used to be an advanced concept but... ... it's now just another tool in every TSQL developers' box.
I guess that's the real key and what I've always aimed for. Thanks for the encouragement, Chris. I'll keep it "Seemples" and digestible. π
--Jeff Moden
Change is inevitable... Change for the better is not.
August 23, 2010 at 7:50 am
Jeff,
Stay folksy. Your articles are great the way they are.
I'm new to the forums and not a DBA by profession. I read the posts and articles here to broaden my understanding of SQL Server and the issues that arise.
I read your Tally Table article and it was very helpful.
Steve
Viewing 15 posts - 1 through 15 (of 15 total)
You must be logged in to reply to this topic. Login to reply