Subject | external table filesystem layout changed? |
---|---|
Author | Christian Stengel |
Post date | 2007-06-05T16:11:11Z |
Hi,
did the layout of external files change from 1.5.x to 2.0?
I'm doing imports with external tables using the native datatypes. On
firebird 1.5 everything worked as expected (integers used 4 bytes,
bigints used 8 bytes). On firebird 2.0 it seems that integer fields
are filled with 8 byte instead of 4 byte if a integer field comes
after a bigint field.
Consider the following SQL:
SQL> create table b1 external file '/database/external/b1' (a bigint,
b integer, c bigint);
SQL> insert into b1 values (1,2,3);
Gives the following layout on a 1.5 engine:
e:~ chris$ hexdump -C /database/external/b1
00000000 01 00 00 00 00 00 00 00 02 00 00 00 30 00 00 00
|................|
00000010 00 00 00 00 |........|
00000014
and on a 2.0 engine:
e:~ chris$ hexdump -C /database/external/b1
00000000 01 00 00 00 00 00 00 00 02 00 00 00 00 00 00 00
|................|
00000010 03 00 00 00 00 00 00 00 |........|
00000018
Did I miss something?
If I add another integer field in 2.0 after the integer field, 2.0
does not add another 8 bytes to table - it reueses the space from the
first added integer.
Thanks,
Chris
did the layout of external files change from 1.5.x to 2.0?
I'm doing imports with external tables using the native datatypes. On
firebird 1.5 everything worked as expected (integers used 4 bytes,
bigints used 8 bytes). On firebird 2.0 it seems that integer fields
are filled with 8 byte instead of 4 byte if a integer field comes
after a bigint field.
Consider the following SQL:
SQL> create table b1 external file '/database/external/b1' (a bigint,
b integer, c bigint);
SQL> insert into b1 values (1,2,3);
Gives the following layout on a 1.5 engine:
e:~ chris$ hexdump -C /database/external/b1
00000000 01 00 00 00 00 00 00 00 02 00 00 00 30 00 00 00
|................|
00000010 00 00 00 00 |........|
00000014
and on a 2.0 engine:
e:~ chris$ hexdump -C /database/external/b1
00000000 01 00 00 00 00 00 00 00 02 00 00 00 00 00 00 00
|................|
00000010 03 00 00 00 00 00 00 00 |........|
00000018
Did I miss something?
If I add another integer field in 2.0 after the integer field, 2.0
does not add another 8 bytes to table - it reueses the space from the
first added integer.
Thanks,
Chris