> -----Original Message-----
> From: Fabricio Araujo [mailto:fabricioa@...]
> Sent: Lunes 1 de Mayo de 2000 0:50
>
> Hmmm... Mickey$oft is not able to do the conversion? Ahaaa, uhuuu
> ;-))) What
> a shame! :-)

The script does the conversion if you have patience to wait and you haven't
trashed the Master db as I had done (BTW, touching the Master is not
recommended, as you know). But it's much faster and reliable (and
recommended in the README) to backup/restore.

> I agree. Blind conversions of DBs works when the basic behavior
> of the host
> doesn't change anyway. IB dialect 3 does not fit this hypothesis,
> there are sig-
> nificant behavior change (specially on certain datatypes).

Biggest problems are IMHO:
- Change in arithmetic rules => check procedures and triggers that rely on
math operations. Now the math rules for multiplication/division are enforced
in the resulting number of decimal places. Can a tool do such check in a
reliable way? Maybe inspecting blr.
- Change in datatypes => date is no longer datetime. The cast in a procedure
changes its meaning.
- Numeric types now are exact. Even with backup/restore, your IB5's numeric
fields will remain stored as double precision in IB6, not as exact numerics.

> > A blind conversion is IMHO a direct call for disaster.
>
> I think that Dominique's request can be accomplished (in little
> DBs in HD that can support have 2
> copies of the DB) by an automagically call to gbak (a complete
> backup-restore cyles)..

Or simply a blind tool that makes the blind conversion to dialect 3, hoping
there're not much stored procedures.

C.