December 26, 2007 at 10:59 am
I am trying to set a default contstraint on a varchar field to hold the date in the following format: MMMM dd, yyyy. SO the date appears January 15, 2009. In the past this is done in the DTS pacakge that imports the data because the app requires it in this format but I would like to have the field default to it. Any ideas?
Also it is SQL 7 so a function is not going to work.
December 26, 2007 at 11:59 am
You can use a default value like this:
datename(month,getdate())+' '+
convert(varchar(2),day(getdate()))+', '+
convert(varchar(4),year(getdate()))
December 26, 2007 at 12:06 pm
December 26, 2007 at 4:54 pm
Heh... to many conversions and concatenation for me... the following does the trick as well...
SELECT STUFF(CONVERT(VARCHAR(30),GETDATE(),107),1,3,DATENAME(mm,GETDATE()))
--Jeff Moden
Change is inevitable... Change for the better is not.
December 27, 2007 at 7:40 am
December 27, 2007 at 9:20 am
You bet...
Personally, what I'd rather see is a real DATETIME column and a CALCULATED column to provide the varchar version that the GUI needs. Somewhere down the line, varchar formatted columns with no real DATETIME column to back it up is going to cost you in performance somewhere.
--Jeff Moden
Change is inevitable... Change for the better is not.
December 27, 2007 at 9:39 am
December 27, 2007 at 10:01 am
I'd still be tempted to make the formatting in a calculated column for the app so I could easily create reports like "How many emails did we send today?". They may not have asked for such reports but wouldn't they be happy if you just happened to offer one up?
--Jeff Moden
Change is inevitable... Change for the better is not.
December 27, 2007 at 10:16 am
Oh , but we have those reports based on actual date fields. The app records the sent date as it sends the emails. This one holds the displayed respond by field and I guess if we wanted to know how many emails needed to be responded to on a certain date then I would want a true date field holding the data. I have the benefit (or detrement?) of being the "They" as well as the "We" so if I have not anticipated my own future desires I can only blame myself.
I do like the concept but I'm not sure the tradeoff of the extra column is worth it in this situation.
December 27, 2007 at 10:42 am
Heh... understood... I still kick myself for some of the things I've done to a database in past lives 😀
Wouldn't really be an extra column and no tradeoff that I can see... holds no data... it's just a marker for a calculation... formatted date is "auto-magically" updated when underlying data is changed... for example...
CREATE TABLE #CalcDateExample
(
RowNum INT IDENTITY(1,1),
SomeData VARCHAR(30),
RealDate DATETIME DEFAULT GETDATE(),
CalcDate AS STUFF(CONVERT(VARCHAR(30),RealDate,107),1,3,DATENAME(mm,RealDate))
)
--===== Known dates inserted
INSERT INTO #CalcDateExample
(SomeData, RealDate)
SELECT 'A','01/01/2007' UNION ALL
SELECT 'B','01/02/2007' UNION ALL
SELECT 'C','01/03/2007'
--===== Date but no dates... default date takes over
INSERT INTO #CalcDateExample
(SomeData)
SELECT 'E' UNION ALL
SELECT 'F' UNION ALL
SELECT 'G'
--===== Display the results including the calculated column
SELECT * FROM #CalcDateExample
--===== Do an update to the dates for "B" and "E"
UPDATE #CalcDateExample
SET RealDate = GETDATE()-5
WHERE SomeData IN ('A','E')
--===== Display the results including the calculated column
SELECT * FROM #CalcDateExample
See? No worries about the formatted date.
--Jeff Moden
Change is inevitable... Change for the better is not.
December 27, 2007 at 10:50 am
December 27, 2007 at 11:04 am
Always a pleasure, MrPoleCat... and thanks for the feedback.
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 12 posts - 1 through 11 (of 11 total)
You must be logged in to reply to this topic. Login to reply