| Subject | Re: [firebird-support] internal gds software consistency check (index key too big (174)) |
|---|---|
| Author | Ann W. Harrison |
| Post date | 2006-07-25T15:01:24Z |
phil_hhn wrote:
a month or two (or deploy an RC version) is to use Firebird 2 which
greatly expands the length of index keys. Set the page size to 8KB
and everything will be fine.
Here is my code:
done is correct, but can lead to problems if there is any data in
the fields. The best way to shorten a field is to create a
a temporary field, copy the data, delete the original field,
create a new field with the old name, copy the data back, and
then delete the temporary field. Awkward, but fortunately rare,
and with Firebird 2 and longer index keys, shortening fields
will be even more rare.
DDL time check for index key length (which you have) and your
data produces a key that's longer than 252 bytes (or somewhat
less for compound keys). It says it's an internal error because
there are checks that should keep you from defining key that
could exceed the limits.
Regards,
Ann
> Hi, I'm using Firebird 1.5.3.4870.An alternative, if you can postpone correcting the problem for
> I had a column defined as:
> UTEXT varchar(250) CHARACTER SET NONE COLLATE NONE
>
> I need to convert it to a charset which handles accents (so chose
> ISO8859_1, EN_UK) and it must be indexed. Because an index cannot be
> applied to a column this size (with the new char set), I've reduced
> the column to 80 chars.
a month or two (or deploy an RC version) is to use Firebird 2 which
greatly expands the length of index keys. Set the page size to 8KB
and everything will be fine.
Here is my code:
>Err. Direct system table updates are discouraged. What you've
> update RDB$FIELDS
> set
> RDB$FIELD_LENGTH = 80,
> RDB$CHARACTER_LENGTH = 80,
> RDB$CHARACTER_SET_ID = 21,
> RDB$COLLATION_ID = 12
> where ....
> update RDB$RELATION_FIELDS
> set RDB$COLLATION_ID = 12
> where ...
>
> This has worked without a problem on several different databases
done is correct, but can lead to problems if there is any data in
the fields. The best way to shorten a field is to create a
a temporary field, copy the data, delete the original field,
create a new field with the old name, copy the data back, and
then delete the temporary field. Awkward, but fortunately rare,
and with Firebird 2 and longer index keys, shortening fields
will be even more rare.
> ... But I've just got a database off another machine andThat's the error you get when you somehow manage to avoid the
> after running the above 3 statements, when I commit I get:
> internal gds software consistency check (index key too big (174))
DDL time check for index key length (which you have) and your
data produces a key that's longer than 252 bytes (or somewhat
less for compound keys). It says it's an internal error because
there are checks that should keep you from defining key that
could exceed the limits.
>Could there be old data that hasn't been garbage collected?
> I thought maybe this error was occurring because there was data in the
> UTEXT column (which once the charset changes it will not fit), but
> this is not the case. Before running the above statements, there is no
> data in the UTEXT column (i.e all null).
Regards,
Ann