Submitted by: Ann Lynnworth (annfire)
This syntax for setting the description of a field works in Firebird 2.5 but not in 3.0 (note: this is using the SYSDBA account) :
UPDATE RDB$RELATION_FIELDS SET RDB$DESCRIPTION = 'autoincrement' WHERE (RDB$RELATION_NAME = 'INVOICEDET') AND (RDB$FIELD_NAME = 'INVOICEDETNO');
The exception is
ISC ERROR CODE:335545030
ISC ERROR MESSAGE:
UPDATE operation is not allowed for system table RDB$RELATIONS
While it seems reasonable to block general edits to the RELATIONS table, blocking access to the DESCRIPTION metadata seems counter productive.
This might be a documentation issue. There is a section in the docs, "User Privileges for Metadata Changes," which implies that there might be a way to enable changes to Metadata. It is unclear why any GRANT statement would be needed when operating as SYSDBA, and it is unclear which object(s) need to have extra permissions in order to set the Description property of a field. If there is a way to use a GRANT statement to override the readonly nature of the system tables, that would be well worth documenting as one of the example statements in that section.
Also in the docs, there is a link to Tracker item CORE735, which itself is confusing because that issue is marked as a duplicate of several other items.
Submitted by: Ann Lynnworth (annfire)
This syntax for setting the description of a field works in Firebird 2.5 but not in 3.0 (note: this is using the SYSDBA account) :
UPDATE RDB$RELATION_FIELDS SET RDB$DESCRIPTION = 'autoincrement' WHERE (RDB$RELATION_NAME = 'INVOICEDET') AND (RDB$FIELD_NAME = 'INVOICEDETNO');
The exception is
ISC ERROR CODE:335545030
ISC ERROR MESSAGE:
UPDATE operation is not allowed for system table RDB$RELATIONS
While it seems reasonable to block general edits to the RELATIONS table, blocking access to the DESCRIPTION metadata seems counter productive.
This might be a documentation issue. There is a section in the docs, "User Privileges for Metadata Changes," which implies that there might be a way to enable changes to Metadata. It is unclear why any GRANT statement would be needed when operating as SYSDBA, and it is unclear which object(s) need to have extra permissions in order to set the Description property of a field. If there is a way to use a GRANT statement to override the readonly nature of the system tables, that would be well worth documenting as one of the example statements in that section.
Also in the docs, there is a link to Tracker item CORE735, which itself is confusing because that issue is marked as a duplicate of several other items.