Hi Tim,

What is passed is executed. So doing something like

Select * from table where Field = 'DD/MM/YYYY'

will work on a text memo or char field without error as it is valid
for them to contain the value DD/MM/YYYY. However, if field is a
numeric then they will get an error, as expected - garbage in garbage
out.

Oh well, it was bound to happen one day. Thanks for all the replies.
I still think that set DateFormat = DD/MM/YYYY is a good idea.
Leslie.


--- In firebird-support@yahoogroups.com, Tim Ledgerwood <tim@s...>
wrote:

> Hi Leslie -
>
> Do you get individual fields into your DLL, or is it one long

string, or is

> it a delimited string? In other words, no matter what DB you are

using,

> somehow you have to have some idea of the field you are passing

through to

> whatever DB you are using. For example, I would expect that it

would cause

> you problems if you passed a date value to a field containing memo

data ...

> etc.
>
> My experience (Interbase, Paradox, dBase III, IV, Sybase, SQL

Server, DB2,

> Oracle) is that for access to a server DB, at some level you either

have to

> use a native class (a class providing APIs that you can call)

specific to

> each SQL (for example, the Borland BDE used to use the SQL Links

libraries,

> Crystal Reports has a different DLL for each server DB, that kind

of thing)

> or you have to use some kind of generic access method, like the

BDE - which

> simply wraps all the work. But there is, as far as I know, no way

of

> getting around the fact that different DBs use different SQLs -

even if

> they are all ANSI 92 standard ...
>
> What I would do in your case is check what the windows date format

is (if

> you are developing on the Windows platform) and decode the string

that way

> - then re - write the string into a format that is understood by

all SQLs -

> I believe that "DD-MMM-YYYY" is such a format. I.e., it doesn't

matter

> whether you are using Oracle or dBase III, date passed to the

database in

> the format "09-OCT-2003" will be understood by all of them.
>
> In my experience with client apps, your problem isn't with

Interbase /

> Firebird, by the way. If your users are using any of the Microsoft
> products, they are generally able to change the date format

themselves -

> and even make thier own date formats. In South Africa, as in

Australia, the

> "standard" date format is "dd/mm/yyyy".
>
> But I have often found users who will set thier own date format, or
> continue using the default US standard of mm/dd/yyyy. My solution

has been

> to either decode whatever date I am getting, using the Windows

short date

> format, and build the string I require, or in some cases, to

actually

> change the system settings every time the application runs.
>