Subject | Re: [ib-support] gbak error (2nd post) |
---|---|
Author | Ann W. Harrison |
Post date | 2002-02-07T22:38:25Z |
At 09:36 AM 2/7/2002 +0100, Duilio Foschi wrote:
stopping all of its transactions. Normally the transactions would
be rolled back as part of the unwind, but this particular error
doesn't follow the right path.
The original error is the "message length error" - that's one I'd
never seen until a couple of days ago. Seeing it a second time so
soon worries me a bit. Last time we tracked the problem down this
way.
First, we identified the table with the error by running gbak
with the -v switch.
Second, we used this query to find a numeric field with a bad length:
select rfr.rdb$field_name, t.rdb$type_name, f.rdb$field_length
from rdb$fields f, rdb$types t, rdb$relation_fields rfr
where f.rdb$field_type = t.rdb$type and
f.rdb$field_name = rfr.rdb$field_source and
rfr.rdb$relation_name = '<your table name here>' and
t.rdb$field_name = 'RDB$FIELD_TYPE';
Look for fields that have a type of LONG and a length of 2. Character
fields are unlikely to cause the problem because everyone depends on
their stated length. Most of the engine assumes it knows how long a
short or a long is. Gbak relies on the system tables to tell it.
fix the field this way:
update rdb$fields set rdb$field_length = <correct length>
where rdb$field_name = <value from previous query>
Regards,
Ann
www.ibphoenix.com
We have answers.
>\programs\firebird\gbak -b -user SYSDBA -pas masterkey foo.gdb foo.bkGbak has encountered a fatal error and tried to disconnect without
>
>I get the following error messages:
>
>"message length error (encountered 244 expected 246)"
>"gds_$ received failed"
>"exiting before completion due to errors"
>"cannot disconnect database with open transactions (1 active)"
stopping all of its transactions. Normally the transactions would
be rolled back as part of the unwind, but this particular error
doesn't follow the right path.
The original error is the "message length error" - that's one I'd
never seen until a couple of days ago. Seeing it a second time so
soon worries me a bit. Last time we tracked the problem down this
way.
First, we identified the table with the error by running gbak
with the -v switch.
Second, we used this query to find a numeric field with a bad length:
select rfr.rdb$field_name, t.rdb$type_name, f.rdb$field_length
from rdb$fields f, rdb$types t, rdb$relation_fields rfr
where f.rdb$field_type = t.rdb$type and
f.rdb$field_name = rfr.rdb$field_source and
rfr.rdb$relation_name = '<your table name here>' and
t.rdb$field_name = 'RDB$FIELD_TYPE';
Look for fields that have a type of LONG and a length of 2. Character
fields are unlikely to cause the problem because everyone depends on
their stated length. Most of the engine assumes it knows how long a
short or a long is. Gbak relies on the system tables to tell it.
fix the field this way:
update rdb$fields set rdb$field_length = <correct length>
where rdb$field_name = <value from previous query>
Regards,
Ann
www.ibphoenix.com
We have answers.