> Try using a different date, i.e. 12/31 and see what happens
Actually, that probably won't help.
Access is too smart for your own good. When it sees a month number that is too large to *BE* a month, it just automatically assumes that you inverted the month and day.
So it will *ALWAYS* see
December 31, 2007
And it will *ALWAYS* see
31 December 2007
A better check, to find out what is *REALLY* STORED in the DB is to use something like
SELECT Day(datefield), MonthName(Month(datefield)), Year(datefield)
getting the three parts of the date separately.
On top of all of the above: When you use SQL to query an Access DB, you must *ALWAYS* use #MM/DD/YYYY#. SQL queries to Access simply do *NOT* understand the DD/MM/YYYY format. [But, again, if you give it #31/12/2007# *then* it will see the 31 as a day and act correctly.]
The safest way to be 100% sure that the dates you are giving Access via SQL are correct is to use ISO format: #YYYY/MM/DD#. When you use a 4-digit year as the first part of the date, Access *has* to assume you mean yyyy/mm/dd.
And finally, even if the date stored in the DB *is* "12 May 2007", how that gets displayed in ASP/VBScript depends upon the *LOCALE* where the IIS web server is running!!! If the web server is running in USA locale, then you *WILL* see the USA format of mm/dd/yyyy from VBScript.
Luckily, this is something you can easily change. Just do
Session.LCID = XXXX
at the top of your page, where XXXX is the appropriate value for your country and location. You can see a list of LCID values here:
(You'll have to copy/paste that to your browser address bar; this forum can't handle some characters in URLs.)
Last but not least... To understand a bit more about all this seeming arcane stuff, look here:
I wrote that 6 years ago, but it's amazing how many people still don't understand it, today. It even comes back to bite ASP.NET users.