Subject | Re: [firebird-support] Skipped internal numbers for rdb$relation_fields.rdb$field_position |
---|---|
Author | Ann W. Harrison |
Post date | 2010-07-14T14:47:19Z |
Venus Software Operations wrote:
no check that positions were dense - or even not duplicated.
query like
SELECT 'ALTER TABLE ' | rdb$relation_name | ' ALTER ' |
rdb$field_name | ' POSITION ' | rdb$field_position
FROM rdb$relation_field
WHERE rdb$system_flag is null or rdb$system_flag = 0
Run the script on the development table.
Good luck,
Ann
>Dropping fields has that effect. And at least originally, there was
> I noticed that there are skipped numbers for the series for a given
> table fields in the rdb$relation_fields.rdb$field_position
no check that positions were dense - or even not duplicated.
>You could generate an ISQL script on the production database using a
> How can I get the corresponding visual field numbers? So even though a
> table fields look the same in both the databases but internally the
> development version has skipped numbers whereas not in the production
> database. As I am trying to update a database remotely using script,
> these missing numbers are flagging false positives.
>
> Currently I can hack the system tables and force the numbers as on the
> dev. copy but I was hoping to detect field order changes if ever done on
> the dev. copy and the same reorder to do on the prod. copy using
> standard SQL command of ALTER TABLE aaa ALTER bbb POSITION 999
>
query like
SELECT 'ALTER TABLE ' | rdb$relation_name | ' ALTER ' |
rdb$field_name | ' POSITION ' | rdb$field_position
FROM rdb$relation_field
WHERE rdb$system_flag is null or rdb$system_flag = 0
Run the script on the development table.
Good luck,
Ann