Only Date Part comparison with System Date in SQL Server
I have a stored procedure :-
CREATE procedure St_Proc_GetTimeEntryID
@userID int,
@timeEntryID int output
as begin
set nocount on;
SET @timeEntryID=0
DECLARE @TEMP INT
SET @TEMP=0
SELECT @TEMP=ProductionTimeEntryID
FROM production
WHERE ProductionTimeEntryID =
(SELECT MAX(ProductionTimeEntryID)
FROM production
where UserID=@userID
and (CalendarDate = (select GETDATE()))
and IsTaskCompleted=1 )
BEGIN
SET @timeEntryID=@TEMP
END
END
Here CalendarDate is column which containing Date As 06/26/201212:00PM format .
I want to compare the date part only with system date part (06/26/2012 = 06/26/2012) in my subquery which is
(SELECT MAX(ProductionTimeEntryID)
FROM production
where UserID=@userID
and (CalendarDate = (select GETDATE()))
and IsTaskCompleted=1 )
Please guide me what modification i ll do to get the result.
add a comment |Â
I have a stored procedure :-
CREATE procedure St_Proc_GetTimeEntryID
@userID int,
@timeEntryID int output
as begin
set nocount on;
SET @timeEntryID=0
DECLARE @TEMP INT
SET @TEMP=0
SELECT @TEMP=ProductionTimeEntryID
FROM production
WHERE ProductionTimeEntryID =
(SELECT MAX(ProductionTimeEntryID)
FROM production
where UserID=@userID
and (CalendarDate = (select GETDATE()))
and IsTaskCompleted=1 )
BEGIN
SET @timeEntryID=@TEMP
END
END
Here CalendarDate is column which containing Date As 06/26/201212:00PM format .
I want to compare the date part only with system date part (06/26/2012 = 06/26/2012) in my subquery which is
(SELECT MAX(ProductionTimeEntryID)
FROM production
where UserID=@userID
and (CalendarDate = (select GETDATE()))
and IsTaskCompleted=1 )
Please guide me what modification i ll do to get the result.
Is theCalendarDatecolumnDATETIMEor something else? For clarity it's important to state the data type and also to understand that aDATETIMEdata type does not store any format as you suggest - that's just how Management Studio displays it to you, based on the regional settings of the machine, your language settings, etc. Specifying SQL Server version is also helpful.
â Aaron Bertrand
Jun 26 '12 at 12:16
The CalendarDate column is DATETIME and I m using Sql Server 2008 .Your comments helped me and next time i ll really specify all these points if trapped in any issue. Thanks for the Suggestion @Aoron
â Dharmendra Kumar Singh
Jun 27 '12 at 8:31
add a comment |Â
I have a stored procedure :-
CREATE procedure St_Proc_GetTimeEntryID
@userID int,
@timeEntryID int output
as begin
set nocount on;
SET @timeEntryID=0
DECLARE @TEMP INT
SET @TEMP=0
SELECT @TEMP=ProductionTimeEntryID
FROM production
WHERE ProductionTimeEntryID =
(SELECT MAX(ProductionTimeEntryID)
FROM production
where UserID=@userID
and (CalendarDate = (select GETDATE()))
and IsTaskCompleted=1 )
BEGIN
SET @timeEntryID=@TEMP
END
END
Here CalendarDate is column which containing Date As 06/26/201212:00PM format .
I want to compare the date part only with system date part (06/26/2012 = 06/26/2012) in my subquery which is
(SELECT MAX(ProductionTimeEntryID)
FROM production
where UserID=@userID
and (CalendarDate = (select GETDATE()))
and IsTaskCompleted=1 )
Please guide me what modification i ll do to get the result.
I have a stored procedure :-
CREATE procedure St_Proc_GetTimeEntryID
@userID int,
@timeEntryID int output
as begin
set nocount on;
SET @timeEntryID=0
DECLARE @TEMP INT
SET @TEMP=0
SELECT @TEMP=ProductionTimeEntryID
FROM production
WHERE ProductionTimeEntryID =
(SELECT MAX(ProductionTimeEntryID)
FROM production
where UserID=@userID
and (CalendarDate = (select GETDATE()))
and IsTaskCompleted=1 )
BEGIN
SET @timeEntryID=@TEMP
END
END
Here CalendarDate is column which containing Date As 06/26/201212:00PM format .
I want to compare the date part only with system date part (06/26/2012 = 06/26/2012) in my subquery which is
(SELECT MAX(ProductionTimeEntryID)
FROM production
where UserID=@userID
and (CalendarDate = (select GETDATE()))
and IsTaskCompleted=1 )
Please guide me what modification i ll do to get the result.
edited Jun 27 '12 at 18:19
Aaron Bertrand
207k27361404
207k27361404
asked Jun 26 '12 at 11:40
Dharmendra Kumar Singh
1,828103657
1,828103657
Is theCalendarDatecolumnDATETIMEor something else? For clarity it's important to state the data type and also to understand that aDATETIMEdata type does not store any format as you suggest - that's just how Management Studio displays it to you, based on the regional settings of the machine, your language settings, etc. Specifying SQL Server version is also helpful.
â Aaron Bertrand
Jun 26 '12 at 12:16
The CalendarDate column is DATETIME and I m using Sql Server 2008 .Your comments helped me and next time i ll really specify all these points if trapped in any issue. Thanks for the Suggestion @Aoron
â Dharmendra Kumar Singh
Jun 27 '12 at 8:31
add a comment |Â
Is theCalendarDatecolumnDATETIMEor something else? For clarity it's important to state the data type and also to understand that aDATETIMEdata type does not store any format as you suggest - that's just how Management Studio displays it to you, based on the regional settings of the machine, your language settings, etc. Specifying SQL Server version is also helpful.
â Aaron Bertrand
Jun 26 '12 at 12:16
The CalendarDate column is DATETIME and I m using Sql Server 2008 .Your comments helped me and next time i ll really specify all these points if trapped in any issue. Thanks for the Suggestion @Aoron
â Dharmendra Kumar Singh
Jun 27 '12 at 8:31
Is the
CalendarDate column DATETIME or something else? For clarity it's important to state the data type and also to understand that a DATETIME data type does not store any format as you suggest - that's just how Management Studio displays it to you, based on the regional settings of the machine, your language settings, etc. Specifying SQL Server version is also helpful.â Aaron Bertrand
Jun 26 '12 at 12:16
Is the
CalendarDate column DATETIME or something else? For clarity it's important to state the data type and also to understand that a DATETIME data type does not store any format as you suggest - that's just how Management Studio displays it to you, based on the regional settings of the machine, your language settings, etc. Specifying SQL Server version is also helpful.â Aaron Bertrand
Jun 26 '12 at 12:16
The CalendarDate column is DATETIME and I m using Sql Server 2008 .Your comments helped me and next time i ll really specify all these points if trapped in any issue. Thanks for the Suggestion @Aoron
â Dharmendra Kumar Singh
Jun 27 '12 at 8:31
The CalendarDate column is DATETIME and I m using Sql Server 2008 .Your comments helped me and next time i ll really specify all these points if trapped in any issue. Thanks for the Suggestion @Aoron
â Dharmendra Kumar Singh
Jun 27 '12 at 8:31
add a comment |Â
4 Answers
4
active
oldest
votes
The most efficient method (meaning fully able to utilize an index on CalendarDate, if one exists) is going to be, on SQL Server 2000/2005:
DECLARE @today SMALLDATETIME;
SET @today = DATEDIFF(DAY, 0, CURRENT_TIMESTAMP);
...
WHERE CalendarDate >= @today
AND CalendarDate < DATEADD(DAY, 1, @today);
If using SQL Server 2008+:
DECLARE @today DATE = CURRENT_TIMESTAMP;
...
WHERE CalendarDate >= @today
AND CalendarDate < DATEADD(DAY, 1, @today);
You can also use a direct cast in SQL Server 2008+, but I'm not 100% sure this is guaranteed to use an index on CalendarDate in all scenarios:
WHERE CONVERT(DATE, CalendarDate) = CONVERT(DATE, CURRENT_TIMESTAMP);
Because this casting does not work with other date/time data types, for consistency I much prefer the open-ended range technique, and definitely do not condone most of the scenarios where you perform implicit or explicit conversions on the column (since this usually means an index won't be used). I've ranted about this and several other date/time atrocities plenty at the following blog posts:
What do BETWEEN and the devil have in common?
Bad habits to kick : mis-handling date / range queries
add a comment |Â
In SQL2K8;
... WHERE CAST(CalendarDate AS DATE) <= CAST(GETDATE() AS DATE)
(This will negate any index use on CalendarDate, alternatively bracket CalendarDate between CalendarDate >= CAST(CalendarDate AS DATE) AND < DATEADD(...)
Actually this is one of the exceptions, where SQL Server does still choose to use an index even if you've converted the column to DATE. But because this is not documented (at least that I've found), because there may be exceptions outside of my test cases, and because it doesn't work with other date/time data types, I still prefer the >= & < format.
â Aaron Bertrand
Jun 26 '12 at 12:11
add a comment |Â
Something like this?
(SELECT MAX(ProductionTimeEntryID)
FROM production
where UserID=412
and (convert(datetime, convert(varchar(100), CalendarDate, 106)) <= convert(datetime, convert(varchar(100), GETDATE(), 106)))
and IsTaskCompleted=1 )
In SQL2008R2, you can also use:and CAST( CalendarDate AS DATE ) <= CAST( GETDATE() AS DATE )
â Sean
Jun 26 '12 at 11:51
@SeanW Your comment is much better than the answer. At least that still has some chance to use an index. Your answer suggests four wasteful conversions.
â Aaron Bertrand
Jun 26 '12 at 12:17
yep - that was how i used to do it pre-2008... old habits :)
â Sean
Jun 26 '12 at 12:29
add a comment |Â
Use convert function
In your case:
SELECT CONVERT(DATE,GETDATE(),101)
More specifically:
(SELECT MAX(ProductionTimeEntryID)
FROM production
where UserID=@userID
and (CONVERT(DATE,CalendarDate) = CONVERT(DATE,GETDATE()))
and IsTaskCompleted=1 )
Why do you need 101?
â Aaron Bertrand
Jun 26 '12 at 12:15
@AaronBertrand - for comparison its not required though OP specified it like this06/26/2012 = 06/26/2012i.e. Month/Day/Year
â NaveenBhat
Jun 26 '12 at 12:25
Did the OP say the data was stored as a string? My suspicion is this is just what Management Studio shows him.
â Aaron Bertrand
Jun 26 '12 at 12:26
Well, you are right Aaron. If you would, you can edit the answer to improve the quality.
â NaveenBhat
Jun 26 '12 at 12:32
add a comment |Â
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
The most efficient method (meaning fully able to utilize an index on CalendarDate, if one exists) is going to be, on SQL Server 2000/2005:
DECLARE @today SMALLDATETIME;
SET @today = DATEDIFF(DAY, 0, CURRENT_TIMESTAMP);
...
WHERE CalendarDate >= @today
AND CalendarDate < DATEADD(DAY, 1, @today);
If using SQL Server 2008+:
DECLARE @today DATE = CURRENT_TIMESTAMP;
...
WHERE CalendarDate >= @today
AND CalendarDate < DATEADD(DAY, 1, @today);
You can also use a direct cast in SQL Server 2008+, but I'm not 100% sure this is guaranteed to use an index on CalendarDate in all scenarios:
WHERE CONVERT(DATE, CalendarDate) = CONVERT(DATE, CURRENT_TIMESTAMP);
Because this casting does not work with other date/time data types, for consistency I much prefer the open-ended range technique, and definitely do not condone most of the scenarios where you perform implicit or explicit conversions on the column (since this usually means an index won't be used). I've ranted about this and several other date/time atrocities plenty at the following blog posts:
What do BETWEEN and the devil have in common?
Bad habits to kick : mis-handling date / range queries
add a comment |Â
The most efficient method (meaning fully able to utilize an index on CalendarDate, if one exists) is going to be, on SQL Server 2000/2005:
DECLARE @today SMALLDATETIME;
SET @today = DATEDIFF(DAY, 0, CURRENT_TIMESTAMP);
...
WHERE CalendarDate >= @today
AND CalendarDate < DATEADD(DAY, 1, @today);
If using SQL Server 2008+:
DECLARE @today DATE = CURRENT_TIMESTAMP;
...
WHERE CalendarDate >= @today
AND CalendarDate < DATEADD(DAY, 1, @today);
You can also use a direct cast in SQL Server 2008+, but I'm not 100% sure this is guaranteed to use an index on CalendarDate in all scenarios:
WHERE CONVERT(DATE, CalendarDate) = CONVERT(DATE, CURRENT_TIMESTAMP);
Because this casting does not work with other date/time data types, for consistency I much prefer the open-ended range technique, and definitely do not condone most of the scenarios where you perform implicit or explicit conversions on the column (since this usually means an index won't be used). I've ranted about this and several other date/time atrocities plenty at the following blog posts:
What do BETWEEN and the devil have in common?
Bad habits to kick : mis-handling date / range queries
add a comment |Â
The most efficient method (meaning fully able to utilize an index on CalendarDate, if one exists) is going to be, on SQL Server 2000/2005:
DECLARE @today SMALLDATETIME;
SET @today = DATEDIFF(DAY, 0, CURRENT_TIMESTAMP);
...
WHERE CalendarDate >= @today
AND CalendarDate < DATEADD(DAY, 1, @today);
If using SQL Server 2008+:
DECLARE @today DATE = CURRENT_TIMESTAMP;
...
WHERE CalendarDate >= @today
AND CalendarDate < DATEADD(DAY, 1, @today);
You can also use a direct cast in SQL Server 2008+, but I'm not 100% sure this is guaranteed to use an index on CalendarDate in all scenarios:
WHERE CONVERT(DATE, CalendarDate) = CONVERT(DATE, CURRENT_TIMESTAMP);
Because this casting does not work with other date/time data types, for consistency I much prefer the open-ended range technique, and definitely do not condone most of the scenarios where you perform implicit or explicit conversions on the column (since this usually means an index won't be used). I've ranted about this and several other date/time atrocities plenty at the following blog posts:
What do BETWEEN and the devil have in common?
Bad habits to kick : mis-handling date / range queries
The most efficient method (meaning fully able to utilize an index on CalendarDate, if one exists) is going to be, on SQL Server 2000/2005:
DECLARE @today SMALLDATETIME;
SET @today = DATEDIFF(DAY, 0, CURRENT_TIMESTAMP);
...
WHERE CalendarDate >= @today
AND CalendarDate < DATEADD(DAY, 1, @today);
If using SQL Server 2008+:
DECLARE @today DATE = CURRENT_TIMESTAMP;
...
WHERE CalendarDate >= @today
AND CalendarDate < DATEADD(DAY, 1, @today);
You can also use a direct cast in SQL Server 2008+, but I'm not 100% sure this is guaranteed to use an index on CalendarDate in all scenarios:
WHERE CONVERT(DATE, CalendarDate) = CONVERT(DATE, CURRENT_TIMESTAMP);
Because this casting does not work with other date/time data types, for consistency I much prefer the open-ended range technique, and definitely do not condone most of the scenarios where you perform implicit or explicit conversions on the column (since this usually means an index won't be used). I've ranted about this and several other date/time atrocities plenty at the following blog posts:
What do BETWEEN and the devil have in common?
Bad habits to kick : mis-handling date / range queries
edited Nov 10 at 21:20
answered Jun 26 '12 at 12:25
Aaron Bertrand
207k27361404
207k27361404
add a comment |Â
add a comment |Â
In SQL2K8;
... WHERE CAST(CalendarDate AS DATE) <= CAST(GETDATE() AS DATE)
(This will negate any index use on CalendarDate, alternatively bracket CalendarDate between CalendarDate >= CAST(CalendarDate AS DATE) AND < DATEADD(...)
Actually this is one of the exceptions, where SQL Server does still choose to use an index even if you've converted the column to DATE. But because this is not documented (at least that I've found), because there may be exceptions outside of my test cases, and because it doesn't work with other date/time data types, I still prefer the >= & < format.
â Aaron Bertrand
Jun 26 '12 at 12:11
add a comment |Â
In SQL2K8;
... WHERE CAST(CalendarDate AS DATE) <= CAST(GETDATE() AS DATE)
(This will negate any index use on CalendarDate, alternatively bracket CalendarDate between CalendarDate >= CAST(CalendarDate AS DATE) AND < DATEADD(...)
Actually this is one of the exceptions, where SQL Server does still choose to use an index even if you've converted the column to DATE. But because this is not documented (at least that I've found), because there may be exceptions outside of my test cases, and because it doesn't work with other date/time data types, I still prefer the >= & < format.
â Aaron Bertrand
Jun 26 '12 at 12:11
add a comment |Â
In SQL2K8;
... WHERE CAST(CalendarDate AS DATE) <= CAST(GETDATE() AS DATE)
(This will negate any index use on CalendarDate, alternatively bracket CalendarDate between CalendarDate >= CAST(CalendarDate AS DATE) AND < DATEADD(...)
In SQL2K8;
... WHERE CAST(CalendarDate AS DATE) <= CAST(GETDATE() AS DATE)
(This will negate any index use on CalendarDate, alternatively bracket CalendarDate between CalendarDate >= CAST(CalendarDate AS DATE) AND < DATEADD(...)
answered Jun 26 '12 at 11:50
Alex K.
138k21201239
138k21201239
Actually this is one of the exceptions, where SQL Server does still choose to use an index even if you've converted the column to DATE. But because this is not documented (at least that I've found), because there may be exceptions outside of my test cases, and because it doesn't work with other date/time data types, I still prefer the >= & < format.
â Aaron Bertrand
Jun 26 '12 at 12:11
add a comment |Â
Actually this is one of the exceptions, where SQL Server does still choose to use an index even if you've converted the column to DATE. But because this is not documented (at least that I've found), because there may be exceptions outside of my test cases, and because it doesn't work with other date/time data types, I still prefer the >= & < format.
â Aaron Bertrand
Jun 26 '12 at 12:11
Actually this is one of the exceptions, where SQL Server does still choose to use an index even if you've converted the column to DATE. But because this is not documented (at least that I've found), because there may be exceptions outside of my test cases, and because it doesn't work with other date/time data types, I still prefer the >= & < format.
â Aaron Bertrand
Jun 26 '12 at 12:11
Actually this is one of the exceptions, where SQL Server does still choose to use an index even if you've converted the column to DATE. But because this is not documented (at least that I've found), because there may be exceptions outside of my test cases, and because it doesn't work with other date/time data types, I still prefer the >= & < format.
â Aaron Bertrand
Jun 26 '12 at 12:11
add a comment |Â
Something like this?
(SELECT MAX(ProductionTimeEntryID)
FROM production
where UserID=412
and (convert(datetime, convert(varchar(100), CalendarDate, 106)) <= convert(datetime, convert(varchar(100), GETDATE(), 106)))
and IsTaskCompleted=1 )
In SQL2008R2, you can also use:and CAST( CalendarDate AS DATE ) <= CAST( GETDATE() AS DATE )
â Sean
Jun 26 '12 at 11:51
@SeanW Your comment is much better than the answer. At least that still has some chance to use an index. Your answer suggests four wasteful conversions.
â Aaron Bertrand
Jun 26 '12 at 12:17
yep - that was how i used to do it pre-2008... old habits :)
â Sean
Jun 26 '12 at 12:29
add a comment |Â
Something like this?
(SELECT MAX(ProductionTimeEntryID)
FROM production
where UserID=412
and (convert(datetime, convert(varchar(100), CalendarDate, 106)) <= convert(datetime, convert(varchar(100), GETDATE(), 106)))
and IsTaskCompleted=1 )
In SQL2008R2, you can also use:and CAST( CalendarDate AS DATE ) <= CAST( GETDATE() AS DATE )
â Sean
Jun 26 '12 at 11:51
@SeanW Your comment is much better than the answer. At least that still has some chance to use an index. Your answer suggests four wasteful conversions.
â Aaron Bertrand
Jun 26 '12 at 12:17
yep - that was how i used to do it pre-2008... old habits :)
â Sean
Jun 26 '12 at 12:29
add a comment |Â
Something like this?
(SELECT MAX(ProductionTimeEntryID)
FROM production
where UserID=412
and (convert(datetime, convert(varchar(100), CalendarDate, 106)) <= convert(datetime, convert(varchar(100), GETDATE(), 106)))
and IsTaskCompleted=1 )
Something like this?
(SELECT MAX(ProductionTimeEntryID)
FROM production
where UserID=412
and (convert(datetime, convert(varchar(100), CalendarDate, 106)) <= convert(datetime, convert(varchar(100), GETDATE(), 106)))
and IsTaskCompleted=1 )
answered Jun 26 '12 at 11:48
Sean
7,17074884
7,17074884
In SQL2008R2, you can also use:and CAST( CalendarDate AS DATE ) <= CAST( GETDATE() AS DATE )
â Sean
Jun 26 '12 at 11:51
@SeanW Your comment is much better than the answer. At least that still has some chance to use an index. Your answer suggests four wasteful conversions.
â Aaron Bertrand
Jun 26 '12 at 12:17
yep - that was how i used to do it pre-2008... old habits :)
â Sean
Jun 26 '12 at 12:29
add a comment |Â
In SQL2008R2, you can also use:and CAST( CalendarDate AS DATE ) <= CAST( GETDATE() AS DATE )
â Sean
Jun 26 '12 at 11:51
@SeanW Your comment is much better than the answer. At least that still has some chance to use an index. Your answer suggests four wasteful conversions.
â Aaron Bertrand
Jun 26 '12 at 12:17
yep - that was how i used to do it pre-2008... old habits :)
â Sean
Jun 26 '12 at 12:29
In SQL2008R2, you can also use:
and CAST( CalendarDate AS DATE ) <= CAST( GETDATE() AS DATE )â Sean
Jun 26 '12 at 11:51
In SQL2008R2, you can also use:
and CAST( CalendarDate AS DATE ) <= CAST( GETDATE() AS DATE )â Sean
Jun 26 '12 at 11:51
@SeanW Your comment is much better than the answer. At least that still has some chance to use an index. Your answer suggests four wasteful conversions.
â Aaron Bertrand
Jun 26 '12 at 12:17
@SeanW Your comment is much better than the answer. At least that still has some chance to use an index. Your answer suggests four wasteful conversions.
â Aaron Bertrand
Jun 26 '12 at 12:17
yep - that was how i used to do it pre-2008... old habits :)
â Sean
Jun 26 '12 at 12:29
yep - that was how i used to do it pre-2008... old habits :)
â Sean
Jun 26 '12 at 12:29
add a comment |Â
Use convert function
In your case:
SELECT CONVERT(DATE,GETDATE(),101)
More specifically:
(SELECT MAX(ProductionTimeEntryID)
FROM production
where UserID=@userID
and (CONVERT(DATE,CalendarDate) = CONVERT(DATE,GETDATE()))
and IsTaskCompleted=1 )
Why do you need 101?
â Aaron Bertrand
Jun 26 '12 at 12:15
@AaronBertrand - for comparison its not required though OP specified it like this06/26/2012 = 06/26/2012i.e. Month/Day/Year
â NaveenBhat
Jun 26 '12 at 12:25
Did the OP say the data was stored as a string? My suspicion is this is just what Management Studio shows him.
â Aaron Bertrand
Jun 26 '12 at 12:26
Well, you are right Aaron. If you would, you can edit the answer to improve the quality.
â NaveenBhat
Jun 26 '12 at 12:32
add a comment |Â
Use convert function
In your case:
SELECT CONVERT(DATE,GETDATE(),101)
More specifically:
(SELECT MAX(ProductionTimeEntryID)
FROM production
where UserID=@userID
and (CONVERT(DATE,CalendarDate) = CONVERT(DATE,GETDATE()))
and IsTaskCompleted=1 )
Why do you need 101?
â Aaron Bertrand
Jun 26 '12 at 12:15
@AaronBertrand - for comparison its not required though OP specified it like this06/26/2012 = 06/26/2012i.e. Month/Day/Year
â NaveenBhat
Jun 26 '12 at 12:25
Did the OP say the data was stored as a string? My suspicion is this is just what Management Studio shows him.
â Aaron Bertrand
Jun 26 '12 at 12:26
Well, you are right Aaron. If you would, you can edit the answer to improve the quality.
â NaveenBhat
Jun 26 '12 at 12:32
add a comment |Â
Use convert function
In your case:
SELECT CONVERT(DATE,GETDATE(),101)
More specifically:
(SELECT MAX(ProductionTimeEntryID)
FROM production
where UserID=@userID
and (CONVERT(DATE,CalendarDate) = CONVERT(DATE,GETDATE()))
and IsTaskCompleted=1 )
Use convert function
In your case:
SELECT CONVERT(DATE,GETDATE(),101)
More specifically:
(SELECT MAX(ProductionTimeEntryID)
FROM production
where UserID=@userID
and (CONVERT(DATE,CalendarDate) = CONVERT(DATE,GETDATE()))
and IsTaskCompleted=1 )
edited Jun 26 '12 at 12:43
answered Jun 26 '12 at 11:50
NaveenBhat
2,69422745
2,69422745
Why do you need 101?
â Aaron Bertrand
Jun 26 '12 at 12:15
@AaronBertrand - for comparison its not required though OP specified it like this06/26/2012 = 06/26/2012i.e. Month/Day/Year
â NaveenBhat
Jun 26 '12 at 12:25
Did the OP say the data was stored as a string? My suspicion is this is just what Management Studio shows him.
â Aaron Bertrand
Jun 26 '12 at 12:26
Well, you are right Aaron. If you would, you can edit the answer to improve the quality.
â NaveenBhat
Jun 26 '12 at 12:32
add a comment |Â
Why do you need 101?
â Aaron Bertrand
Jun 26 '12 at 12:15
@AaronBertrand - for comparison its not required though OP specified it like this06/26/2012 = 06/26/2012i.e. Month/Day/Year
â NaveenBhat
Jun 26 '12 at 12:25
Did the OP say the data was stored as a string? My suspicion is this is just what Management Studio shows him.
â Aaron Bertrand
Jun 26 '12 at 12:26
Well, you are right Aaron. If you would, you can edit the answer to improve the quality.
â NaveenBhat
Jun 26 '12 at 12:32
Why do you need 101?
â Aaron Bertrand
Jun 26 '12 at 12:15
Why do you need 101?
â Aaron Bertrand
Jun 26 '12 at 12:15
@AaronBertrand - for comparison its not required though OP specified it like this
06/26/2012 = 06/26/2012 i.e. Month/Day/Yearâ NaveenBhat
Jun 26 '12 at 12:25
@AaronBertrand - for comparison its not required though OP specified it like this
06/26/2012 = 06/26/2012 i.e. Month/Day/Yearâ NaveenBhat
Jun 26 '12 at 12:25
Did the OP say the data was stored as a string? My suspicion is this is just what Management Studio shows him.
â Aaron Bertrand
Jun 26 '12 at 12:26
Did the OP say the data was stored as a string? My suspicion is this is just what Management Studio shows him.
â Aaron Bertrand
Jun 26 '12 at 12:26
Well, you are right Aaron. If you would, you can edit the answer to improve the quality.
â NaveenBhat
Jun 26 '12 at 12:32
Well, you are right Aaron. If you would, you can edit the answer to improve the quality.
â NaveenBhat
Jun 26 '12 at 12:32
add a comment |Â
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid â¦
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid â¦
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f11206529%2fonly-date-part-comparison-with-system-date-in-sql-server%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Is the
CalendarDatecolumnDATETIMEor something else? For clarity it's important to state the data type and also to understand that aDATETIMEdata type does not store any format as you suggest - that's just how Management Studio displays it to you, based on the regional settings of the machine, your language settings, etc. Specifying SQL Server version is also helpful.â Aaron Bertrand
Jun 26 '12 at 12:16
The CalendarDate column is DATETIME and I m using Sql Server 2008 .Your comments helped me and next time i ll really specify all these points if trapped in any issue. Thanks for the Suggestion @Aoron
â Dharmendra Kumar Singh
Jun 27 '12 at 8:31