RE: [Firebird-devel] damn gbak Win32 error

[Claudio V. C. <cv...@us...>]

> -----Original Message-----
> From: fir...@li...
> [mailto:fir...@li...]On Behalf Of
> Dmitry Kuzmenko
>
> every build from 290 gives new surprises.

I thought you like surprises.
:-)

> 338 build have bug with RDB$FORMATS (non-uniqueness)

It has been always non-unique. Ann changed a system index and it began
complaining. The solution was to revert the index to its original
definition. Format works this way since ever. Let it create repeated
entries.

> 338 build have new version string, some tools won't work with it
> 35?

Which version string, the 1.0X thing or the later 6.2 hack?

> build, you have told that you will remove BREAK due it's instability

Instability means server trashes itself. Break doesn't produce that. I use
it. The problem is that I build a couple of procedures with a lot of breaks
in any place and some of them produce errors. But this is different than a
memory problem. The idea was "leave it uncommented in the rel docs."

> 441 build, rejects ambiguous queries. Very funny for developer.

Very funny if the developer doesn't know the crap he was getting before and
only became aware now. IB doesn't make any assurance of the results, this is
why a few days ago a post suggested in some list to reverse the order of the
table declarations. Do you think that this is magic? No, it's the result of
the server taking one or another table and doing distinct optimizations.
This is one of the "benefits" of the ambiguity you defend.

> 453 ... don't remember

Maybe you didn't find the new bug that I had crafted carefully for my
Russian friends... maybe the bug doesn't work.
:-)

> 493 problem with gbak-restore long filenames

I think it's almost resolved.

C.