Re: [Firebird-devel] non-transportable backup using without "-seservice_mgr" results in an backup file ~50% larger than the source database

[Alex P. <pes...@ma...>]

 After more careful analysis I've found the following.

My first impression that files differ only in the end was wrong.
Actually, I've overwritten file with backup done over network by backup,
done using embedded access. Size did not change - but this is due ti the
fact that gbak does not trancate backup files. And if you backup
something small overwriting old big  file, it will anyway remain big.
This is a bug itself and should be fixed.

Embedded access produces file with exactly same size as service_mgr
does. This is as expected. But I was working with overwritten by
embedded access and not truncated file, therefore it seemed to me that
files differ in the end.

Actually the reason is as follows. gbak when used in none-transportable
mode compresses message as it was received by isc_receive(). And
sometimes in varchar fields with zero length there arrives some garbage
- values of fields transfered some times before. Length is OK - it's
zero - but some non-null data is present after it. In transportable mode
length of varchar is taken into an account and therefore this data does
not affect something. In none-transportable - it makes RLE compression
work worse, causing therefore bigger backup file.

The question is - are there any requirements in our API to what is
placed in the message buffer as a data for varchar field with zero
length? Should it be NULLs or may it be garbage?