We just upgraded our bios and all calls to the vbscript version of CDate are
no longer working as expected. The date we pass is 06/02/04 but 02/06/04
gets returned and saved in the DB. If we save again, 06/02/04 is passed
back, so that each time we save this, the 6 and the 2 are switched. Any
clue as to where this might be coming from. Nothing else has changed and
setting the Session.LCID value has no effect (as well as changing our
regional settings).

Any help would be great!
Thanks
Kris

Bah...had the exact same problem more than a year ago, but it had nothing to
do with flashing the BIOS...below, please find an email I sent to the guy
who helped me identify the problem in the first place:


"Thank you so much for your reply. While I did not use your procedure to fix
the problem our customer had (notice the "had" , it did give me a clue as
to what was wrong. Indeed, perhaps your procedure can be pared down a bit,
if my solution fixes the problem you have.

"Basically, in the HKCU\Control Panel\International key, the iDate and
sShortDate values must be in sync (that is to say that the {iDate,
sShortDate} pairs are {0, MM/dd/yyyy}, {1, dd/MM/yyyy}, {2, yyyy/mm/dd}).
This goes for HKU\.Default\Control Panel\International as well.

"Our client had a short date format of dd/MM/yyyy, but iDate of 0 in
HKCU\Control Panel\International. I am not sure how this situation arose
(although I suspect that one value and not the other is being pushed down
from the domain controller) since every time you click "apply" in the
Regional Settings Control Panel applet, the values are synchronized.
Anyways, what I did was take the HKU\.Default\Control Panel\International
key and merged it into the HKCU\Control Panel\International (as your
procedure had suggested) and all of a sudden, the test application
(and -=our=- application) started to work properly. I took a copy of the
client's (original) HKCU\Control Panel\International key and merged it into
my registry, and our application started flipping months and days again.

"So I started playing around with the registry settings, and found that with
a short date format of dd/MM/yyyy, parsing dates from strings would fail to
obey the regional settings if the iDate was 0 (rather than 1). This is the
only change which needed to be made to a clean W2K install in order for the
odd behaviour to occur."



--
John Phillips
MVP - Windows SDK




"Kristina Nielsen" <(E-Mail Removed)> wrote in message
news:%(E-Mail Removed)...
> We just upgraded our bios and all calls to the vbscript version of CDate
are
> no longer working as expected. The date we pass is 06/02/04 but 02/06/04
> gets returned and saved in the DB. If we save again, 06/02/04 is passed
> back, so that each time we save this, the 6 and the 2 are switched. Any
> clue as to where this might be coming from. Nothing else has changed and
> setting the Session.LCID value has no effect (as well as changing our
> regional settings).
>
> Any help would be great!
> Thanks
> Kris
>
>