Select statement problem

This is what's going on. I need to SELECT a subset of records filtered by adateTime type parameter. It's supposed to be very simple. I ran into a problem of the SELECT statement ignoring majority of records altogether. Instead of expected about 250 records I get only 62. In order to verify if this is the case, I set up a test table and ran the same statement. I tried to make sure that the structures for the two tables: thetest oneand myworking tablebe as closely matched as possible. The statement works on the test table and the result is366 but on my working table I get62 records instead of expected..... I do not know exactly how many I can expect, not 366 of course but close to250. I would be surprised if I could get anything less than that. In my working table the days do not follow calendar strictly. Only weekdays are present. Holidays and weekends are excluded.

I go to my working table and see that many of the records are simply ignored. The dates are there but they do not appear in the result table.

The only difference is that in myworking tablethe dates all have12:00:00 AM for hh:mm:ss.fff. Another mystery is that in theresulting SQL server table records (the ones I get after executingexec sp_sqlexec @SQLat the second statement below) from the working table appear as00:00:00.000.

The whole date in SQL result set looks like2006-03-23 00:00:00.000whereas in the SQL table the same record will look as3/23/2005 12:00:00 AM

USE DailyClose
GO
DECLARE @SQL varchar (256)
DECLARE @cDateLast varchar (23)
DECLARE @cDateFirst varchar (23)
DECLARE @dateTimedLast dateTime
DECLARE @dateTimedFirst dateTime
SET @dateTimedLast = GETDATE()
SET @dateTimedFirst = DATEADD (year, -1, GETDATE())
PRINT @dateTimedLast
PRINT @dateTimedFirst
SET @cDateLast = CONVERT(varchar(23), @dateTimedLast, 121)
SET @cDateFirst = CONVERT(varchar(23), @dateTimedFirst, 121);
PRINT @cDateLast
PRINT @cDateFirst

CREATE TABLE t (
[Id] [int] NOT NULL,
[dateTimed] [dateTime] NULL
);
DECLARE @i int;
DECLARE @ddt dateTime;
SET @i = 1;
SET @ddt = GETDATE();
WHILE @i < 1001 BEGIN
INSERT INTO t ([Id],[dateTimed]) VALUES (@i, @ddt)
SET @i = @i + 1;
SET @ddt = DATEADD (day, -1, @ddt)
END;

SET @SQL = 'SELECT dateTimed FROM t
WHERE dateTimed >= CAST ('''+@cDateFirst+''' AS dateTime) ORDER BY dateTimed '
exec sp_sqlexec @SQL -- this statemetn works fine
SET @SQL = 'SELECT DISTINCT dateTimed FROM dailyCl_DJIA
WHERE dateTimed >= CAST ('''+@cDateFirst+''' AS dateTime) ORDER BY dateTimed '
exec sp_sqlexec @SQL -- this statement gives me absurd results

I want Andrea to note (in case you read this) that I changed the format of SELECT ... WHERE statement by adding the CAST clause. I did it out of desperation so to speak when tried to find a solution. The cast did not make any difference but I left it there anyway.

I hope somebody will suggest a resolution to this strange problem. Strange for me anyway.

Many thanks.

[3564 byte] By [AlexBB] at [2007-12-27]
# 1
I just noticed that in the second SET SQL statement I left DISTINCT clause inadvertently. Removal of this statement does not make any difference at all. It was my mistake to leave it there. Sorry.
AlexBB at 2007-9-4 > top of Msdn Tech,SQL Server,SQL Server Express...
# 2
First off, the "The whole date in SQL result set looks like 2006-03-23 00:00:00.000 whereas in the SQL table the same record will look as 3/23/2005 12:00:00 AM" thing is either the result of your using CONVERT(..121) or the result of which tools you are using to look at the data. Enterprise Manager/.NET/SSMS Object Browser will show the data differently than just running a query in Query Analyzer/SSMS Query window. The date is the same, as you know.

Secondly, why are you using dynamic SQL? There's certainly no need for it in the example given.

Thirdly, Why are you using strings for dates? What it your reasoning for using VARCHAR(23) in these examples instead of DATETIME (sorry - the stupid editor is adding bold to this text for some reason lol).

As a final thought, you could use SMALLDATETIME here since you aren't worried about seconds.

Here's my version of your script. Noticec how I've removed the unnecessary use of variables and dynamic SQL calls in addition to the VARCHAR().

DECLARE @dateTimedLast SMALLDATETIME, @dateTimedFirst SMALLDATETIME, @i int, @ddt SMALLDATETIME

SET @dateTimedLast = GETDATE()
SET @dateTimedFirst = DATEADD (year, -1, @dateTimedLast)
SET @i = 1;
SET @ddt = @dateTimedLast;

PRINT @dateTimedLast
PRINT @dateTimedFirst

CREATE TABLE #t (
[Id] [int] NOT NULL IDENTITY(1,1),
[dateTimed] [dateTime] NOT NULL
)

WHILE @i < 1001
BEGIN
INSERT INTO #t ([dateTimed]) VALUES (@ddt)
SET @i = @i + 1;
SET @ddt = DATEADD (day, -1, @ddt)
END

SELECT dateTimed FROM #t WHERE dateTimed >= @dateTimedFirst ORDER BY dateTimed]

Lastly, the reason the first script sends back 366 rows is that the first date is one year previous (as a result of SET @dateTimedFirst = DATEADD (year, -1, @dateTimedLast))

If your production table, running the same script, only returns 62 rows, then there are only 62 rows that meet the criteria - end of story. Your SQL code is the same; that means that your data is probably not what you think it is!

I will say that your code doesn't really make any sense. Why are you creating a table to store 1001 rows of previous dates but then limiting the final result to only the past one year? It just doesn't make sense given how you posted the problem. Also, if you just want all the rows in the table since a given date, why don't you just say

SELECT dateTimed
FROM ProductionTable
WHERE dateTimed >=
DATEADD (year, -1, GETDATE())
ORDER BY dateTimed]

If I'm not mistaken, that one SELECT statement returns every row you want without using the variables, a temp table, or anything.

Hope this helps - and feel free to post back if I've misunderstood your problem/question!

Scott Whigham

Check out my SQL Server 2005 Video Tutorials: http://www.learnsqlserver.com/

ScottWhigham at 2007-9-4 > top of Msdn Tech,SQL Server,SQL Server Express...
# 3

hi Alex,

when working with datetime datatypes you should consider the intrinsic problem of repreentation, which i different to the internal format.. please have a look at http://www.karaszi.com/sqlserver/info_datetime.asp ..

another beautifull article, by Our Lady SQL Server, Kalen Delaney, is available at http://www.sqlmag.com/Articles/Index.cfm?ArticleID=9147 but for subscribers only..

regards

AndreaMontanari at 2007-9-4 > top of Msdn Tech,SQL Server,SQL Server Express...

SQL Server

Site Classified