| Author |
Topic |
|
KidSQL
Yak Posting Veteran
88 Posts |
Posted - 2005-04-18 : 14:37:32
|
| Hello,I have imported a table with date columns in it which are in the nvarchar datatype. For some reason, the import process imported my pre-formatted dates as YYYY-MM-DD (despite importing them as nvarchar).My question is: I wish to alter my table to add smalldatetime columns and convert the contents of these originals to dates. However, I need a format that is MM/DD/YYYY with no hours, minutes or seconds. Does anyone know how I could specify this? Is there a code or something I should be using in my update lines as in:update mytableset newcolumn = convert(smalldatetime, oldcolumn, [SOME CODE]?)Thanks in advance to anyone willing to lend a helping hand. |
|
|
TG
Master Smack Fu Yak Hacker
6065 Posts |
Posted - 2005-04-18 : 14:43:33
|
| I think all you need to do is for the session that is doing the update:set dateformat mdy --this sets the format for ENTERING dates onlyupdate mytableset newcolumn = oldcolumnBe One with the OptimizerTG |
 |
|
|
KidSQL
Yak Posting Veteran
88 Posts |
Posted - 2005-04-18 : 15:08:57
|
| Thanks for the suggestion. I've tried this, but somehow I keep getting a YYYY-MM-DD date format. In fact, I keep getting this format even when I use one of the pre-packaged codes (101, for instance). Could it be somethign to do with some default setting I have, I wonder? |
 |
|
|
TG
Master Smack Fu Yak Hacker
6065 Posts |
Posted - 2005-04-18 : 15:34:17
|
| Sorry, I thouht you were having trouble getting the dates in the table. If you're concerned about how the dates are stored, you really have no choice other than Datetime and SmallDateTime. Sql server doesn't store any date format just a pair of ints for datetime (or smallints for smalldatetime) When you say, "I keep getting the format..." you mean when you SELECT the values, that is how they are presented? If you have datetime values of something like: "4/18/2005 15:31:20.123" and you want to loose the time precision as "4/18/2005 0:00:00.000" there is a way to do that. But if you want to only store the date portion without anytime component, that is not possible for datetime or smalldatetime columns.Be One with the OptimizerTG |
 |
|
|
X002548
Not Just a Number
15586 Posts |
Posted - 2005-04-18 : 15:36:46
|
smalldatetime has nothing to do with not storing the time component...it just limits the range of what dates can be storedbolquote: RemarksValues with the datetime data type are stored internally by Microsoft SQL Server as two 4-byte integers. The first 4 bytes store the number of days before or after the base date, January 1, 1900. The base date is the system reference date. Values for datetime earlier than January 1, 1753, are not permitted. The other 4 bytes store the time of day represented as the number of milliseconds after midnight.The smalldatetime data type stores dates and times of day with less precision than datetime. SQL Server stores smalldatetime values as two 2-byte integers. The first 2 bytes store the number of days after January 1, 1900. The other 2 bytes store the number of minutes since midnight. Dates range from January 1, 1900, through June 6, 2079, with accuracy to the minute.
The dates will ALWAYS have a time component. And the date is stored internally as a number. If you want to have a particular look...you need to use convertYou can "lose" the time components thoughUSE NorthwindGOSET NOCOUNT ONSELECT CONVERT(smalldatetime,(LEFT(CONVERT(varchar(24),GetDate(),126),10))) AS NewDate INTO #myTemp99SELECT * FROM #myTemp99GOSET NOCOUNT OFFDROP TABLE #myTemp99GO Brett8-)EDIT: Actually it's simpler than thatUSE NorthwindGOSET NOCOUNT ONSELECT CONVERT(datetime,CONVERT(varchar(24),GetDate(),101)) AS NewDate INTO #myTemp99SELECT * FROM #myTemp99GOSET NOCOUNT OFFDROP TABLE #myTemp99GO |
 |
|
|
TG
Master Smack Fu Yak Hacker
6065 Posts |
Posted - 2005-04-18 : 15:52:20
|
| I believe this is actually more efficient to strip the time portion down to zeros: select dateAdd(day, datediff(day,0,getdate()), 0)However, I can't imagine why you'd want to deliberately loose precision. As Brett said, you are free to present the dates anyway you want to format them.Be One with the OptimizerTG |
 |
|
|
Michael Valentine Jones
Yak DBA Kernel (pronounced Colonel)
7020 Posts |
Posted - 2005-04-18 : 16:01:58
|
Are you trying to do something like this to change the format?select convert(datetime,getdate(),101) That will not work to change the format. You have to convert it to a string to get the new format:select convert(varchar(30),getdate(),101) quote: Originally posted by KidSQL Thanks for the suggestion. I've tried this, but somehow I keep getting a YYYY-MM-DD date format. In fact, I keep getting this format even when I use one of the pre-packaged codes (101, for instance). Could it be somethign to do with some default setting I have, I wonder?
CODO ERGO SUM |
 |
|
|
KidSQL
Yak Posting Veteran
88 Posts |
Posted - 2005-04-18 : 17:29:11
|
| Hi, thank you very much for your responses. I fear I may have been unclear in my original posting. However, after playing with things a little bit, this is what I got:convert(char(10), MonthlyDate,101)To give it precisely dates in the MM/DD/YYYY format (why this didn't work the first 50 times without the specification of the character length, I don't know - TSQL Help specifically states that format 101 is mm/dd/yy despite my continually getting YYYY/MM/DD.I really appreciate your suggestions and will keep them in mind for future use. Hope I haven't wasted anybody's time(!) |
 |
|
|
DonAtWork
Master Smack Fu Yak Hacker
2167 Posts |
Posted - 2005-04-19 : 09:20:56
|
| This looks familiar. It does not matter how you store the date. yyyymmdd or mmddyyyy. Let the client application worry about formatting the data.Data layer != Presentation layer |
 |
|
|
|