Hola cdb4w,

IMHO the purpose of having a middleware y exactly to deal with those
things such as format conversion.

What do you have to store a numeric decimal value? Depending of the
client locale you could recibe a dot or a coma. I think your
middleware upon connection of client should negotiate some things such
as date format and decimal separator. That way you really abstract the
client from the underlying datastore.

El Jueves, 09 de Octubre de 2003 escribiste:

c> Hi Maciek,

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

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

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

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

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

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

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

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


c> --- In firebird-support@yahoogroups.com, "Maciek BOROWKA" <MBO@c...>
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

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

c> not

>> a valid format.
>>
>> Leslie.

c> To unsubscribe from this group, send an email to:
c> firebird-support-unsubscribe@yahoogroups.com



c> Your use of Yahoo! Groups is subject to
c> http://docs.yahoo.com/info/terms/





--
Saludos,
Daniel Berstein
dbz@...