Gotcha! I
learn something new every day! That's why it's worth getting out of bed
in the morning. :)
This has been an informative thread, thanks for starting it Mark. :)
Chris
David L. Penton wrote:
Since
Mark said he is using MSSQL 7, then he unfortunately doesn't have
access to a DATE or TIME datatype.
SQL Server:
datetime *
smalldatetime
Oracle:
date
timestamp
interval
DB2:
date
time
timestamp
Of course, the (*) indicates the likely candidate for this.
Christopher Jordan wrote:
Unless time of day is important to me, I
typically use Date and not DateTime. Others may disagree and I've no
idea if this is a best practice, but it's what I do. There are times
when the time of day is important to me. I for instance I'm writing a
scheduling program (which I am... :) ), and I need to know if two
shifts overlap, then time is crucial, and I would store shifts as
DateTime (aka TimeStamp... if theres a difference between DateTime and
Timestamp I'm not aware of it). In my situation, when shifts can cross
midnight, it's great to know that the shift started on 06/06/2006 at
8PM and ended on 06/07/2006 at 8AM, you know?
Hope this helps.
Chris
Mark Armstrong wrote:
should I be using datetime? I only need the
date, so not sure, looks like there is datetime, timestamp,
smalldatetime...
too confusing.
Mark
On Jun 6, 2006, at 2:01 PM, Christopher Jordan wrote:
Also, using the proper
Date/Timestamp/etc. data type eliminates problems with consistency
across tables. One table might hold a date as MM/DD/YY while another as
MM/DD/YYYY and another as YYYY/MM/DD or YY-MM-DD or MM-DD-YYYY or...
etc... you get the idea. :)
Chris
Christopher Jordan wrote:
Mark,
As a general rule, I always store dates as date types (or timestamps)
rather than as string representations of dates (YYYY-MM-DD) or even as
numeric representations of dates (YYYYMMDD)... it's helpful when you
want to do date comparisons and such that your dates will already be
formatted correctly, and ColdFusion will already be able to understand
them properly.
That is, of course, just my opinion. :)
Chris
Dave Shuck wrote:
Mark, have you tried:
WHERE .... duedate=#CreateODBCDate(duedate)#
or even better...
WHERE .... duedate = <cfqueryparam type="cf_sql_date"
value=#CreateODBCDate(duedate)# />
~d
On 6/6/06, Mark Armstrong <[EMAIL PROTECTED]> wrote: Sorry, MSSQL
7. table, meaning the "tasks" table that I am storing
the data.
On Jun 6, 2006, at 1:27 PM, Matt Woodward wrote:
> When you say "in the table" what specifically do you mean? What
> database are you using?
>
> On 6/6/06, Mark Armstrong <[EMAIL PROTECTED]> wrote:
>> OK,
>>
>> I give up!!! I cannot seem to get the date to work correctly.
(to
>> insert, modify or output the data in the table).
>>
>> I am CF formatting the date, properly, but its not showing up
in the
>> table anything other than 01/01/01.
>>
>> When I modify the form to insert the new values, its still the
>> same... what can I be doing wrong?
>>
>> The output page is this: #DateFormat(duedate,"MM-DD-YY")#
>>
>> the modify page looks like this:
>>
>> <cfset duedate1 = DateFormat(#duedate#, "mm/dd/yy")>
>>
>> <input name="duedate" type="text" value="#duedate1#"
>> cfsqltype="CF_SQL_DATE" />
>>
>> and the modify page posts to the update processing page:
>>
>> UPDATE tasks
>> SET taskname = '#taskname#', taskdescription =
'#taskdescription#',
>> first_name='#first_name#', weburl='#weburl#', test='#test#',
>> visual='#visual#', comments='#comments#', duedate=#duedate#
>> WHERE taskID = #form.taskID#
>>
>> Any help is appreciated!
>>
>> Mark
_______________________________________________
Reply to DFWCFUG: [email protected]
Subscribe/Unsubscribe:
http://lists1.safesecureweb.com/mailman/listinfo/list
List Archives:
http://www.mail-archive.com/list%40list.dfwcfug.org/
http://www.mail-archive.com/list%40dfwcfug.org/
DFWCFUG Sponsors: www.HostMySite.com www.teksystems.com/
|
