[AccessD] New thrd: dates

Bill Benson bensonforums at gmail.com
Thu Aug 21 10:12:52 CDT 2014


Please forgive my lack of experience, also I thought since this is a deeper
discussion on dates I would retain some but not all of the former posts.

GUI. What is meant by GUI date? Is this a bound textbox reading a date from
the back end?

Example, my backend had Aug 4th 2014 stored as 08/04/2014. In the local
environment with no local formatting, would that display as
04/08/2014 In Europe?

Now supposed unbound forms (which are what primarily work with)

If I populate a text box with

TXTLastChange = DLOOKUP ("Max(Change_dt)","MyTable","")

And the max date in the table is 08/10/2014, what will show in the local
(Europe) text box?, I assume based on what has been said, 10/08/2014, no?

If suppose I have another text box called TxtEffective_dt.  The user wants
to enter Aug 12th, 2014 so thwy, being in Europe, enter 12/08/2014 or
12/08/14.

When I take that value to enter it into the database (remember backend is
US) would I write

Sql = "Insert into myTable (name, address, effective_dt) values ('" &
txtname & "','" & txtaddress & "', #" & txteffectivedate & "#)"

Or
Sql = "Insert into myTable (name, address, effective_dt) values ('" &
txtname & "','" & txtaddress & "', #" & cdate(txteffectivedate) & "#)"

Or something else that will have to convert the text property of
txteffectivedate to the US format?

>
> On Aug 21, 2014 10:43 AM, "Gustav Brock" <gustav at cactus.dk> wrote:
>>
>> Hi Bill
>>
>> The workaround in SQL code is always to use the ISO format: yyyy-mm-dd.
>> It will never fail.
>>
>> As for the GUI, it never fails as long as you follow the simple rules
mentioned.
>>
>> /gustav
>>
>> -----Oprindelig meddelelse-----
>> Fra: accessd-bounces at databaseadvisors.com [mailto:
accessd-bounces at databaseadvisors.com] På vegne af Bill Benson
>> Sendt: 21. august 2014 16:36
>> Til: Access Developers discussion and problem solving
>> Emne: Re: [AccessD] Most common problems/situations
>>
>> I have always worked in US so I don't think I have ever run into this.
But, if there is SQL looking for 08/04/2014 and in the data there is no
08/04/2014, but there happens to be a 04/08/2014, and the user's local date
format is Europe, will a match on  04/08/2014 be returned? What would the
workaround be if your US database BE has an Access FE being used in
European environment?
>> On Aug 21, 2014 9:29 AM, "Gustav Brock" <gustav at cactus.dk> wrote:
>>
>> > Hi Jack
>> >
>> > There is no "sometimes". In the GUI, the date format is always
>> > localized except if you specify another format in the Format property.
>> > In VBA and SQL, date string expressions are always read in US, then
>> > local, then ISO format until a match.
>> > For CDate and DateValue, however, the sequence is local, US, ISO.
>> > For ADO and FindFirst, only the ISO format is reliable.
>> >
>> > /gustav
>> >
>> > -----Oprindelig meddelelse-----
>> > Fra: accessd-bounces at databaseadvisors.com [mailto:
>> > accessd-bounces at databaseadvisors.com] På vegne af jack drawbridge
>> > Sendt: 21. august 2014 14:30
>> > Til: Access Developers discussion and problem solving
>> > Emne: Re: [AccessD] Most common problems/situations
>> >
>> > Arthur,
>> >
>> > Thought I'd pass this on since it came by today and seems to fit your
>> > request.
>> >
>> > " In the user interface - forms, query criteria, - where users enter
>> > dates, MS assumes the format is the system setting, even if the date
>> > is enclosed in # tags, as it might be in query criteria. I have always
>> > been led to believe that any date between # marks had to be MDY
>> > (regardless of system setting), but no. Only sometimes.
>> >
>> > You'd think MS could enable users to set the date format that Access
>> > uses everywhere, including SQL and VBA, regardless of the system date
>> > format setting.
>> >
>> > I wonder how many non-USA users have been caught by this, without
>> > realizing it? "
>>


More information about the AccessD mailing list