--- In ib-support@y..., "Gerhard Knapp" <prometheus@a...> wrote:

> > 1. The client lib is finally changed over
> > 2. Most (if not all) third party connection components have had a

chance

> to
> > move over to the new 'gds' lib

Hi, All. Personally I don't understand why gds32 should be dialect
sensitive. Perhaps it's ignorance, but why client lib should take care
about does underlying database understand some types or not, if not -
really, shouldn't exception be raised by server? And possibility to
force dialect for some API statement execution overlappind dialect of
the database is a store of rakes to step on. Well, API calls format
shouldn't be changed for compatibility with existing applications, but
why not ignore dialect parameter from client and set it accordingly
dialect of database internally?

> i see no reasons to have a much of lost time, to update a lot of

sourcecode,

> because
> the "date" doens't longer exist .... in dialect 3
> escpecially the type DATE is the hammer!

Gerhard, I'm afraid DATE is'nt the main problem. At least it
does'nt require client code modification, TIMESTAMP columns are mapped
to the same field type as old DATE. Migration of our server-side code
can relatively easy be made by context replace in the metadata
creation script and subsequent data pumping. Need some time but at
least it is made one time and you can forget problem after it.
IMHO main problem are NUMERICs and 18 decimal digits. It doesn't
looks enough for many applications, especially in the sense of
intermediate results in expressions. So some columns and some CASTings
should be changed to double (BTW, who in SQL committee had hitted upon
an idea to force us spend our time for endlessly typing of
"precision"? ;)) and this can bring unpredictable results in some
cases. It restrain me from migration into dialect 3 having complex
database which data costs sufficient money.

Beat regards, Alexander V.Nevsky.