[AccessD] Date standardization

Hi Steve:

Yes, of course it is just that I think that for comment purposes 'dd Mon
yyyy' translates a little better... many of the other language just use that
display method.

The following is one of a number of errors that may come up: Run time error
3163; The field is too small to accept the amount of data you attempted to
add. Try inserting or pasting less data.

The information being provided are from unbound fields and the error is
initiated from a basic Select query. My development site of course works
perfectly and as it should. So the client's data file will be the key and as
Alice said, "Curiouser and Curiouser".

Jim


-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Steve Schapel
Sent: Wednesday, June 16, 2010 2:12 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Date standardization

Jim,

As an aside, I assume you mean 'dd mmm yyyy' not 'dd Mon yyyy'.

In any case, the point that I have been trying to make here is that it 
doesn't make any difference at all, none, what the format of the "entry 
points" is.  And it doesn't matter if the user is directly entering into the

tables (though of course in general you don't want users to have direct 
access to the tables).  If it's a Date/Time data type field, then the value 
stored in the table will be precisely the same, regardless of the format of 
how it's entered or displayed in one place or another.

Can you give any specific example of the type of anomaly that is occurring?

Regards
Steve


--------------------------------------------------
From: "Jim Lawrence" <accessd at shaw.ca>
Sent: Thursday, June 17, 2010 8:47 AM
To: "'Access Developers discussion and problem solving'" 
<accessd at databaseadvisors.com>
Subject: Re: [AccessD] Date standardization

> Hi Gustav:
>
> That is true but all the entry points that I could find in the original FE
> MDB, I set to 'dd Mon yyyy'. My fear is that the client has decided for
> expedience sake that direct entry into the tables was faster. 8-(
>
 

-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com