> That wasn't our experience with MS SQL Server 2000 which uses the US
> date/time format even though the server was installed in the UK with
> UK regional settings. We had similar issues (can't remember exactly
> what) with Firebird. Hence the reason we now store it as strings.
Ok, so there's a bug in the data-layer, db-component or database-server
regarding TDateTime fields, so you decided to store it as a string?
If there's a bug regarding numerical fields, do you also store them as
strings? Or do you fix the bug? (Use another database-server?)
MS SQL stores date/time fields in a TDateTime format. (That's why it's
such a strange format.) Firebird uses something similar. The client-
library has to convert that. If that conversion goes wrong, that's
simply a a bug. But understandable, since if you use a simple 'select
datefield from table', without using parameters, it'll return the field
in a string-format, depending on the database-server settings, the
client settings and the connection/transaction settings. The program
which retrieves the field, should be aware of that. If it doesn't that's
just a bug.
It's exactly the same as with your solution: the application has to know
in which format the string comes. (in your case some iso-standard)
Only the 'build-in'-system is more flexible. You can set the format you
want yourself. (including your ISO-standard.) So instead of rewriting
everything in string-based fields, you could do a 'set
dateformat=isoXXXX' or something similar when you open a connection...
And third-party software can set it to their own needs...
Joost.
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
