On 3/1/07, Joost van der Sluis <[EMAIL PROTECTED]> wrote:
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.
I clearly can't get my point across today. :-)
It was not a issue with the DB components we used at the time, but
rather with our complex stored procedures and the amount of people
that worked on the code. Doing a normal select statement and
displaying that date worked fine. It was when we had to write stored
procedures that generates dates based on special criteria and then use
those dates to query data. This happened often and trying to remember
that the date format must be in a format you normally don't use
obviously was a issue. ;-)
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...
Does this apply to code in stored procedures as well? I would think
it only works with whatever DB component you use.
--
Graeme Geldenhuys
There's no place like S34° 03.168' E018° 49.342'
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
