Subject | Re: [ib-support] bug ? |
---|---|
Author | Martijn Tonies |
Post date | 2002-02-12T14:12:14Z |
Hi,
directly - one of them would be 'left-over' system domain entries, for
example.
InterBase Workbench does not 'routinely' change system tables - it uses
standard DDL for all of its operations except modifying the NULL
attribute of a field. And only after careful research and advise/notes from
the real IB/FB internals wizards :)
Martijn Tonies
InterBase Workbench - the developer tool for InterBase and Firebird
http://www.interbaseworkbench.com
Upscene Productions
http://www.upscene.com
"This is an object-oriented system.
If we change anything, the users object."
>>The proper way to change it is to create a temp field with the desiredThere are certain things that can happen when changing the system tables
>>properties...
>
>I am puzzled.
>
>There is a politically correct way to change a field attribute ?
>
>When doing it, can one dress causally or is a necktie de-rigour ? :)
>
>If fields attributes are stored in RDB$RELATION_FIELDS, I expect to get
>logic results when I change the table.
>
>Can you quote public documents that advice against touching system tables ?
>
>For what I know, Interbase WorkBench, Marathon and surely QuickDesk: all
>these tools routinely change fields in system tables in order to get quick
>results.
directly - one of them would be 'left-over' system domain entries, for
example.
InterBase Workbench does not 'routinely' change system tables - it uses
standard DDL for all of its operations except modifying the NULL
attribute of a field. And only after careful research and advise/notes from
the real IB/FB internals wizards :)
Martijn Tonies
InterBase Workbench - the developer tool for InterBase and Firebird
http://www.interbaseworkbench.com
Upscene Productions
http://www.upscene.com
"This is an object-oriented system.
If we change anything, the users object."