when building a t-sql string , what is the preferred method to convert a datetime parameter to a string ... i could imagine doing it like this : (MyDateTimeCol is a table column of type datetime) set @sql = @sql + 'MyDateTimeCol = ''' + convert(varchar(10),@MyDateTimeParam,101) + '''' is there a better/preferred way ?
The preferred method, to be quite honest, is to avoid "building a t-sql string" in the first place. See http://www.sommarskog.se/dynamic_sql.html The only problem I see with your chosen method is that 101 is not a safe format. I would rather use CHAR(8), 112 -- this producs YYYYMMDD, the only truly safe format independent of language, dateformat and regional settings. Also, if your DateTime column includes time information, you probably want a range query (>= day and < day + 1) as opposed to a simple equality... -- Aaron Bertrand SQL Server MVP http://www.aspfaq.com/ [quoted text, click to view] "John A Grandy" <johnagrandy-at-yahoo-dot-com> wrote in message news:uXxEcC9DEHA.3404@TK2MSFTNGP10.phx.gbl... > when building a t-sql string , what is the preferred method to convert a > datetime parameter to a string ... > > i could imagine doing it like this : (MyDateTimeCol is a table column of > type datetime) > > set @sql = @sql + 'MyDateTimeCol = ''' + > convert(varchar(10),@MyDateTimeParam,101) + '''' > > is there a better/preferred way ? > >
hmmm.... well, first off, in this case i'm not doing comparisons , i doing SET statements ... set @sql = @sql + ' set MyDateTimeCol = ''' + convert( varchar(10), @MyDateTimeParam, 112 ) + '''' second, what is so terrible about dynamic sql ? it's the only way good way i know of to write a stored procedure where parameters passed as nulls indicate that the current col value should be left alone. [quoted text, click to view] "Andrew John" <aj@DELETEmistrose.com> wrote in message news:uYTYRo9DEHA.3716@TK2MSFTNGP10.phx.gbl... > "John A Grandy" <johnagrandy-at-yahoo-dot-com> wrote in message news:uXxEcC9DEHA.3404@TK2MSFTNGP10.phx.gbl... > > when building a t-sql string , what is the preferred method to convert a > > datetime parameter to a string ... > > > > i could imagine doing it like this : (MyDateTimeCol is a table column of > > type datetime) > > > > set @sql = @sql + 'MyDateTimeCol = ''' + > > convert(varchar(10),@MyDateTimeParam,101) + '''' > > > > is there a better/preferred way ? > > > > John, > > As written, I would have to agree with Aaron. You have used an > explicit style to convert, so you definitely get a string of the format you > specify. But assuming MyDateTimeCol is actually smalldatetime/datetime, > this string is then IMPLICITLY promoted to a datetime to do the comparison to > the column ( check Books Online under data type precedence ), so you are relying > on the region settings / date format matching at runtime. > > There are 3 methods I have used to do this safely: > > 1) Force SQL to do the convert explicitly > > set @sql = @sql + ' MyDateTimeCol = convert( datetime, ''' + convert( varchar(10), @MyDateTimeParam, 101 ) + ''', 101 )' > > which is a lot of typing, but handles times safely as well as just dates. > > 2) Use the "guaranteed" format: > > set @sql = @sql + ' MyDateTimeCol = ''' + convert( varchar(10), @MyDateTimeParam, 112 ) + '''' > > 3) Don't use dyanamic SQL ! > > Regards > AJ > >
that article doesn't say "DON'T USE DYNAMIC SQL" .... it spells out the pros & cons , the contexts where it's useful , the tradeoffs, etc ... [quoted text, click to view] "Aaron Bertrand [MVP]" <aaron@TRASHaspfaq.com> wrote in message news:OdaSJI9DEHA.2932@tk2msftngp13.phx.gbl... > The preferred method, to be quite honest, is to avoid "building a t-sql > string" in the first place. See http://www.sommarskog.se/dynamic_sql.html > > The only problem I see with your chosen method is that 101 is not a safe > format. I would rather use CHAR(8), 112 -- this producs YYYYMMDD, the only > truly safe format independent of language, dateformat and regional settings. > Also, if your DateTime column includes time information, you probably want a > range query (>= day and < day + 1) as opposed to a simple equality... > > -- > Aaron Bertrand > SQL Server MVP > http://www.aspfaq.com/ > > > > > > > "John A Grandy" <johnagrandy-at-yahoo-dot-com> wrote in message > news:uXxEcC9DEHA.3404@TK2MSFTNGP10.phx.gbl... > > when building a t-sql string , what is the preferred method to convert a > > datetime parameter to a string ... > > > > i could imagine doing it like this : (MyDateTimeCol is a table column of > > type datetime) > > > > set @sql = @sql + 'MyDateTimeCol = ''' + > > convert(varchar(10),@MyDateTimeParam,101) + '''' > > > > is there a better/preferred way ? > > > > > >
[quoted text, click to view] > second, what is so terrible about dynamic sql ?
Did you actually READ the article about dynamic SQL? [quoted text, click to view] > it's the only way good way > i know of to write a stored procedure where parameters passed as nulls > indicate that the current col value should be left alone.
So why don't you ask that question? I prefer: UPDATE table SET column = COALESCE(@param, column) If @param is NULL, the column will keep its current value. -- Aaron Bertrand SQL Server MVP http://www.aspfaq.com/
except that then you risk incurring the wrath of others on this thread who feel that dynamic-sql is Ye Foule Beaste Of Ye Netherworlde ... [quoted text, click to view] "Erland Sommarskog" <sommar@algonet.se> wrote in message news:Xns94B54F24A3AEYazorman@127.0.0.1... > John A Grandy (johnagrandy-at-yahoo-dot-com) writes: > > when building a t-sql string , what is the preferred method to convert a > > datetime parameter to a string ... > > > > i could imagine doing it like this : (MyDateTimeCol is a table column of > > type datetime) > > > > set @sql = @sql + 'MyDateTimeCol = ''' + > > convert(varchar(10),@MyDateTimeParam,101) + '''' > > > > is there a better/preferred way ? > > convert(char(8), @date, 112) is my favourite, as this is a safe format. > > However, best is to use sp_executesql, and pass the @date value as a > parameter. Then you don't have to bother about converting at all. Look > at http://www.sommarskog.se/dynamic_sql.html#sp_executesql for a > quick example. For a longer example, look at > http://www.sommarskog.se/dyn-search.html#sp_executesql. > > > -- > Erland Sommarskog, SQL Server MVP, sommar@algonet.se > > Books Online for SQL Server SP3 at > http://www.microsoft.com/sql/techinfo/productdoc/2000/books.asp
[quoted text, click to view] "John A Grandy" <johnagrandy-at-yahoo-dot-com> wrote in message news:uXxEcC9DEHA.3404@TK2MSFTNGP10.phx.gbl... > when building a t-sql string , what is the preferred method to convert a > datetime parameter to a string ... > > i could imagine doing it like this : (MyDateTimeCol is a table column of > type datetime) > > set @sql = @sql + 'MyDateTimeCol = ''' + > convert(varchar(10),@MyDateTimeParam,101) + '''' > > is there a better/preferred way ? >
John, As written, I would have to agree with Aaron. You have used an explicit style to convert, so you definitely get a string of the format you specify. But assuming MyDateTimeCol is actually smalldatetime/datetime, this string is then IMPLICITLY promoted to a datetime to do the comparison to the column ( check Books Online under data type precedence ), so you are relying on the region settings / date format matching at runtime. There are 3 methods I have used to do this safely: 1) Force SQL to do the convert explicitly set @sql = @sql + ' MyDateTimeCol = convert( datetime, ''' + convert( varchar(10), @MyDateTimeParam, 101 ) + ''', 101 )' which is a lot of typing, but handles times safely as well as just dates. 2) Use the "guaranteed" format: set @sql = @sql + ' MyDateTimeCol = ''' + convert( varchar(10), @MyDateTimeParam, 112 ) + '''' 3) Don't use dyanamic SQL ! Regards AJ
FWIW, below is an article about datetime formats, and my recommendations: http://www.karaszi.com/sqlserver/info_datetime.asp -- Tibor Karaszi, SQL Server MVP http://www.karaszi.com/sqlserver/default.asp [quoted text, click to view] "John A Grandy" <johnagrandy-at-yahoo-dot-com> wrote in message news:uXxEcC9DEHA.3404@TK2MSFTNGP10.phx.gbl... > when building a t-sql string , what is the preferred method to convert a > datetime parameter to a string ... > > i could imagine doing it like this : (MyDateTimeCol is a table column of > type datetime) > > set @sql = @sql + 'MyDateTimeCol = ''' + > convert(varchar(10),@MyDateTimeParam,101) + '''' > > is there a better/preferred way ? > >
John A Grandy (johnagrandy-at-yahoo-dot-com) writes: [quoted text, click to view] > when building a t-sql string , what is the preferred method to convert a > datetime parameter to a string ... > > i could imagine doing it like this : (MyDateTimeCol is a table column of > type datetime) > > set @sql = @sql + 'MyDateTimeCol = ''' + > convert(varchar(10),@MyDateTimeParam,101) + '''' > > is there a better/preferred way ?
convert(char(8), @date, 112) is my favourite, as this is a safe format. However, best is to use sp_executesql, and pass the @date value as a parameter. Then you don't have to bother about converting at all. Look at http://www.sommarskog.se/dynamic_sql.html#sp_executesql for a quick example. For a longer example, look at http://www.sommarskog.se/dyn-search.html#sp_executesql. -- Erland Sommarskog, SQL Server MVP, sommar@algonet.se Books Online for SQL Server SP3 at
John A Grandy (johnagrandy-at-yahoo-dot-com) writes: [quoted text, click to view] > except that then you risk incurring the wrath of others on this thread who > feel that dynamic-sql is Ye Foule Beaste Of Ye Netherworlde ...
If you follow these newsgroups, you see lot of cases where people use dynamic SQL for no good reason at all. Maybe some are VB/ASP developers who are used to build SQL statements in client code, and just continue doing that. There are also people who think the tablename or the column name should be a parameter, or who use dynamic SQL to handle comma-separated lists. All these are example of bad usage. But there are also situations when dynamic SQL gives the best combination of functionality and performance, as long as your security scheme permits it. And I understand that from a earlier comment of yours in this thread, that you have grasped this. -- Erland Sommarskog, SQL Server MVP, sommar@algonet.se Books Online for SQL Server SP3 at
Don't see what you're looking for? Try a search.
|