I did not go that far because I did not think anyone would use an "open"
style of date entry any more. With the cool CF_Date tag you can find in the
tag gallery, you actually get three values so have do to exactly what Bert
is recommending. My syntax for date storage is always (using cf_date as my
method of data entry):
CreateODBCDate(CreateDate(year, month, year))
where year, month and day are variables send to me from the CF_Date tag,
CreateDate makes it into a real date, then CreateODBCDate formats the string
for an embedded ODBC sql {ts} date/time stamp that SQL will like. The real
power of this is that if I am suddenly using DB2 or Oracle, the date will
always be formatted the way the database needs, I simply retrieve it with a
DateFormat() command to get out of it what I need...and how I need to do my
date math.
I know this is OT but for some reason the spirit moved me to make sure I was
not being misunderstood and that Bert was absolutely correct in ammending my
statements.
Mike
-----Original Message-----
From: Bert Dawson [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 14, 2001 6:28 AM
To: Fusebox
Subject: RE: sql date functions
> -----Original Message-----
> From: Mike Craig [mailto:[EMAIL PROTECTED]]
> Sent: 14 February 2001 10:41
> To: Fusebox
> Subject: RE: sql date functions
>
>
> .... the most
> important thing is makeing sure you are using CreateODBCDate
> when storing
> your dates to the database so that they are always in the
> same format and
> more importantly, in a format with which your database is happy.
>
I would go further and say you need to use CreateDate first when a user has
the chance of entering a date manually - because the 'helpful'
CreateODBCDate will convert both '1/15/2001' and '15/1/2001' to {d
'2001-02-01'} (ie "1st of jan 2001"), and SQL server will do the same.
As a rule, whenever a user enters a date, then immediatley turn it into a
valid date object using CreateDate.
Never, ever, (IMHO), do <CFSET mydate = DateFormat(now(), "some format")>:
you should only use DateFormat when actually dumping stuff on the page:
eg the date is: #DateFormat(now(),"ddd, dd mmm yyyy")#
This way you _know_ that any date variables that are flying around are real
date objects, and not strings that will have unpredictable results when
using CreateODBCDate or IsDate functions.
This may sound like OTT ranting, but if you've ever had to tidy up a large
app written by someone who missused and abused the date functions liberally
then you'd understand - just the memory makes me <cf_stop_right_there>
<cf_and_another_thing> "it worked at end of december, when i built it, but
since the start of january strange things have happened"....hmmm, wonder
why...
Bert
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Structure your ColdFusion code with Fusebox. Get the official book at
http://www.fusionauthority.com/bkinfo.cfm
Archives: http://www.mail-archive.com/[email protected]/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
