Free Lessons
Courses
Seminars
TechHelp
Fast Tips
Templates
Topic Index
Forum
ABCD
 
Home   Courses   TechHelp   Forums   Help   Contact   Merch   Join   Order   Logon  
 
Back to Access Forum    Comments List
Upload Images   @Reply   Bookmark    Link   Email   Next Unseen 
DLookup Date for the Brits
Dan Jackson 
            
3 years ago
Hi all, this is one for Kevin or Alex.

I'm going over Access Expert 10 and explains the double double quotes very well. Even better in my opinion than in Double Double Quotes. I'm finally starting to get it and bulding a help sheet for my use.

One question I have is the date format. In the past, I've had to use Kevins suggestion of ~"Format(DateField,"dd/mm/yyyy")

For Example, a simple Dlookup could be
Dlookup("OrderID","OrderT","Date=#" & OrderDate & "#")

But since we're british (and correct), if the table/query and form are using british values, it'll need to be formatted to
Dlookup("OrderID","OrderT","Date=#" & Format([OrderDate], "mm/dd/yyyy") & "#")

Does this seem correct? Other than working on an american DB, is there any situations where we wouldn't use this format trick?

Many Thanks. Will be amazing to get this achilles heel cured and will then be able to help others :)
Alex Hedley  @Reply  
           
3 years ago
I've had this pain for years
Kevin Yip  @Reply  
     
3 years ago
My understanding is that Access can use the British date format if it can be unequivocally and correctly be converted to the US date format.  For instance, #28/3/2023# unequivocally means March 28th since there is no 28th month; so Access can interpret it as March 28th even in the US version of Access -- and, in fact, all international versions:

     Dlookup("OrderID", "OrderT", "Date=#28/3/2023#")
     Dlookup("OrderID", "OrderT", "Date=#28-3-2023#")
     Dlookup("OrderID", "OrderT", "Date=#28-03-23#")

If the name of the month is spelled out, such as "Mar" below, Access can also interpret the date unequivocally and correctly:
    
     Dlookup("OrderID", "OrderT", "Date=#28/Mar/2023#")
     Dlookup("OrderID", "OrderT", "Date=#28-March-2023#")
    

But if a date is #8/3/23#, which is equivocal in appearance to British and Americans, then Access will interpret it, by default, the American way: August 3rd, 2023.  

(What doesn't it interpret it in the British format by default?  Because Access is an American product.  This may sound facetious, but that's how things work sometimes.  If you invent something, you make the rules.  American websites use ".com" while other countries' websites have to use their country codes (.uk, .dk, .cn, etc.) because the US invented this naming system.  There are elements called "noble" elements on the periodic table because the British discovered them, with funding from royalty at the time.)

If a date is invalid, Access may take it upon itself and "correct" it to a different date from what you intended.  For instance, if you write #29/02/01#, intending it to be 29th February, 2001, Access will not interpet "29" as the day because there was no 29th in February that year.  It will, in fact, interpret "29" as the YEAR in the ISO date format, because that is the only way that makes sense to Access.  So your date will be "corrected" to February 1st, 2029!

Access also can't use non-English names for months.  Another poster alerted me to this in a recent thread:

https://599cd.com/blog/display-article.asp?ID=2553&CommentID=66083#StartOfComments

If you use "Maart", the Dutch name for March, in a date, Access will return an error:

     Dlookup("OrderID", "OrderT", "Date=#28/Maart/2023#")
    
Access does accept non-English month names in textbox entries and the query designer.  If you enter #28/Maart/2023# as the criteria in the query designer, the SQL view will immediately convert it to the US date format.
Dan Jackson OP  @Reply  
            
3 years ago
That's an interesting perspective Kevin. While I do agree with you, i think the issue isn't so much following the american guidelines but rather the consistancy. Maybe too clever.

The smart thing to do would be to follow the regional settings on the computer but to follow the american rules 100% wouldn't be too bad either. It's the auto correction I think which makes the job much harder.

Ironically, Rick recently released a video on Access' auto correction of percentage data entry - Percent Bug. In it he shows how access will interpret 0.5 as 0.5% BUT .5 is interpreted as 50% due to starting with a non-numeric digit. In the video, he basically says the same as I have done - Choose a method, any method, and stick to it. Being partial of one and partial of another is just asking for trouble IMHO.

Daily rant over! Appreciate the response. I'm in work now so gonna go back to sleep 😴😜
Richard Rost  @Reply  
          
2 years ago
Hence why I switched to ISO dates

This thread is now CLOSED. If you wish to comment, start a NEW discussion in Access Forum.
 

Next Unseen

 
New Feature: Comment Live View
 
 

The following is a paid advertisement
Computer Learning Zone is not responsible for any content shown or offers made by these ads.
 

Learn
 
Access - index
Excel - index
Word - index
Windows - index
PowerPoint - index
Photoshop - index
Visual Basic - index
ASP - index
Seminars
More...
Customers
 
Login
My Account
My Courses
Lost Password
Memberships
Student Databases
Change Email
Info
 
Latest News
New Releases
User Forums
Topic Glossary
Tips & Tricks
Search The Site
Code Vault
Collapse Menus
Help
 
Customer Support
Web Site Tour
FAQs
TechHelp
Consulting Services
About
 
Background
Testimonials
Jobs
Affiliate Program
Richard Rost
Free Lessons
Mailing List
PCResale.NET
Order
 
Video Tutorials
Handbooks
Memberships
Learning Connection
Idiot's Guide to Excel
Volume Discounts
Payment Info
Shipping
Terms of Sale
Contact
 
Contact Info
Support Policy
Mailing Address
Phone Number
Fax Number
Course Survey
Email Richard
[email protected]
Blog RSS Feed    YouTube Channel

LinkedIn
Copyright 2026 by Computer Learning Zone, Amicron, and Richard Rost. All Rights Reserved. Current Time: 5/2/2026 7:09:33 AM. PLT: 0s