Hi Maciek,

Ok, to fill you in with some of the details.....

I have designed my various applications such that they have no idea
what type of database is being used as the datastore, it could be
ACT!/Foxpro, Paradox for example and now I am adding Firebird.

All database communication is done in a single DLL written in plain
vanilla 'C' and all data regardless of type is communicated to this
layer as strings (thus avoiding problems with languages that do not
support pointers).

This middleware builds an enquiry (which for firebird is an SQL
statement) based upon these string values and executes it. Now
because in Australia generally all input screens capture the date in
DD/MM/YYYY format - that is what is being passed through.

So you can see my problem, at the time of query execution I do not
know which fields are dates and which are not. This makes conversion
difficult. Given that I also support other databases such as Paradox
which *does* accept DD/MM/YYYY in QBE and Local SQL, doing the
conversion at the application side would then require introducing
knowledge about the actual datastore - a no go!

I could check for Data in the format dd/mm/yyyy and replace with
dd.mm.yyyy but what if an Alphafield happens to contain a date?
Really the problem is that firebird is not being flexible enough to
handle what is been a valid date format in the *real* world. I mean
dd.mm.yyyy is hardly if ever used. Even dd-mm-yyyy would be a better
choice.

Given that we already allow Set Dialect = 3 or similar at the
datebase level, why can't we have Set SQLDATEFORMAT = 'DD/MM/YYYY'?

Of course, this changes nothing right now so I will have to work out
how I am going to handle this issue.
Leslie.


--- In firebird-support@yahoogroups.com, "Maciek BOROWKA" <MBO@c...>
wrote:

> Wait a second...
> We are talking about the server acceptance of date in its string
> format.
>
> I don't know what you use for the development, but
> for example with delphi if you use parameters of type TDateTime,
> the local client takes care of translating the date automaticaly.
>
> I mean, if you have to execute a query:
> insert into table1(MyDate)
> values(:mydateParam)
> with the date given by the user, you just take the input *in your
> local format*, cast it into TDateTime format and put it directly
> to the parameter. You *don't care* about the format of date
> the server accepts.
> If the parameter mydateParam is of DateTime type, everything
> works automagicaly.
>
> Of course, if you create directly your SQL, without using

parameters,

> you must do the appropriate conversion on your own. However,
> you can still create your sql and use the parameters as described
> above.
> ./Maciek
>
> >>> lwm317_ebayaccount@b... 09/10/03 09h56 >>>
> Hi Sven,
>
> Thanks for the reply which is pretty bad news. Many many countries
> use DD/MM/YYYY as standard and I find it incredible that this is

not

> a valid format.
>
> Leslie.