On Thu, 2007-03-01 at 12:04 +0200, Graeme Geldenhuys wrote:
> 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. ;-)

In stored procedures you should only use the internal-date-format, and
not any string-like value.

> > 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.

Yes, this is handled by the database-server, so it's independent on the
used component.

Joost

_________________________________________________________________
     To unsubscribe: mail [EMAIL PROTECTED] with
                "unsubscribe" as the Subject
   archives at http://www.lazarus.freepascal.org/mailarchives

Reply via email to