Comparing Dates

[jeff]

hi gurus!

I struggle with this one repeatedly!

I am an Australian and our date format is normally "dd/mm/yyyy" ie
10/12/2007 is the 10th of December 2007 and not the 12th of October 2007.

The current situation I have is:-

ScheduledDates stored against courses in an Access Table
A form with a Date field (normal format is dd/mm/yyyy)
I want to do a comparison in VB SQL as follows:-

"....WHERE ScheduledDate >= #" & me.formcontrolDate & "# ..."

what I am getting is failing due to the fact that the ScheduledDate from the
table is being returned as 10/12/2007 (ie dd/mm/yyyy) but the # date #
interprets the 10/12/2007 in the form control as 12/10/2007.

Is there a surefire method of ALWAYS comparing date data whether from Access
Tables, SQL Server Tables, Access Date Controls and regardless of
international settings?

cheers
Jeff

 

[jeff]

jeff here again....

I have done some more research and it would appear that the most surefire
method would be to compare using the CLNG function turning the Date Control
value into a number.

eg

"....WHERE ScheduledDate >= " & Clng(me.formcontrolDate) & " ..."

and hey presto it worked! Using the Clng function as above, Access honours
the current international settings and treats the date in the control as
dd/mm/yyyy and hence returns a valid number for the date. the Date stored in
the Access table (and I believe even in SQL Server tables) is a number as
well.

I guess the thing to watch though is that :-
If the field in the database is a Date/Time field and not just a Date field
then the Date and Time are stored in as a Double, the integer portion is the
Date and the decimal portion is the Time.

If I am on the right track then I hope this helps others...if not....please
correct the error of my ways....

cheers
Jeff

 

[Aussie Jeff]

mmmmmm Veeeeeeerry interesting....it would appear that one should not rely
on CLng but use CDbl and strip off the Integer portion if only needing to
compare the Date?

I will explore it further...thanks for the alert Jamie!

Cheers
Jeff

 

[Douglas J. Steele]

Check what your fellow countryman Allen Browne has at
http://www.allenbrowne.com/ser-36.html, or what I wrote in my September,
2003 "Access Answers" column in Pinnacle Publication's "Smart Access". You
can download the column (and sample database) for free at
http://www.accessmvp.com/djsteele/SmartAccess.html`

 

[jeff]

Douglas

Thank you very much for the pointer to Allens article!! It is exactly what I
wanted and I suspect your article does the same!!

Thanks Jamie too..but the examples you were giving me may have been flying
over my head but all I am wanting to do is to take a date entered into a
text control on a form (in which it displays in correct australian format ie
dd/mm/yyyy) and compare it to entries in a table using SQL... exactly as
shown in Allens article!

Problem solvered....
cheers all
jeff

 

[jeff]

Jamie

Sorry if I sounded rude... hehe... I did understand your points but was
after something quite simple.

All my dates are stored in an Access table or SQL server table. I only store
the DATE() I dont use the NOW() so the dates only have the Date component
and the Time component is set to 00:00:00.

All I usually ever need to do is to interface between the interface (ie Form
fields) and the database doing lookups for courses being run on or after
certain dates. I am not doing any calculations on dates other than to
compare ie "WHERE SchedDate >= #" & Me.txtSchedDate & "#". <- this does not
work correctly of "us" australians due the differing formats ie dd/mm vs
mm/dd the user enters the date into the Me.txtSchedDate control in the
format of dd/mm/yyyy. This wonderfully interpreted by Microsoft using the ##
delimiters as being mm/dd/yyyy if that was valid for it do so...ie it wont
convert 30/12/2007 to 12/30/2007 as this is not valid but it will convert
07/05/2007 to 05/07/2007 which is wrong for me.

So by incorporating Allen Brownes function:-
'-------------------------------------------------------------------------------
Function SQLDate(varDate As Variant) As String
'-------------------------------------------------------------------------------
'Purpose: Return a delimited string in the date format used natively by
JET SQL.
'Argument: A date/time value.
'Note: Returns just the date format if the argument has no time
component,
' or a date/time format if it does.
'Author: Allen Browne. (e-mail address removed), June 2006.

If IsDate(varDate) Then
If DateValue(varDate) = varDate Then
SQLDate = Format$(varDate, "\#mm\/dd\/yyyy\#")
Else
SQLDate = Format$(varDate, "\#mm\/dd\/yyyy hh\:nn\:ss\#")
End If
End If

End Function

I am able to use "WHERE SchedDate >= " & SQLDate(Me.txtSchedDate) and get
the correct result.

But I do understand you reference to temporal functionality and will keep
that in mind if I ever need to do anything diferent.

regards
Aussie Jeff

Thanks Jamie too..but the examples you were giving me may have been
flying
over my head

Which part of "use temporal functionality for temporal data" did you

all I am wanting to do is to take a date entered into a
text control on a form (in which it displays in correct australian format
ie
dd/mm/yyyy) and compare it to entries in a table using SQL... exactly as
shown in Allens article!

Which part of the article? This:?

The solution is to explicitly typecast all calculated date fields,
e.g.:

DueDate: CVDate([InvoiceDate] + 30)

(Note: CDate() fails on Null values, so CVDate() has more uses than
the "compatibility" issue highlighted in the Access documentation.)

[Unquote]

My approach would be:

The solution is to retain DATETIME values as DATETIME by operating on
them using temporal functionality only e.g.

SELECT DATEADD('D', 30, InvoiceDate) AS DueDate

Note temporal functions such as DATEADD() handle the null value
appropriately, as one would expect.

Ditto converting a DATETIME/Date to a String i.e. don't do it unless
it's for display purposes in the 'front end'.

Jamie.

 

[jeff]

Jamie

Its just a wish...but of course I am not a fortune teller and cannot predict
the future...so of course you are right that I should not make these
assumptions and deal with it correctly in the first instance...I will spend
the time and do the job right...
thanks for all your advice mate!

I will be back!...if i have further issues....

Cheers
Jeff