Subject | Re: RDB$DESCRIPTION missing: thanks for answer! |
---|---|
Author | Barton Bresnik |
Post date | 2008-03-07T03:34:13Z |
Helen,Thanks for the authoritative answer. On the unfounded assumption that Firebird 1.5.3 behaved like Oracle (in allowing persistent field descriptions), I wasted a bit of time. Thanks for those who included that feature in Fb 2.x, but, since I've inherited some existing projects, it might not be of immediate use. At least the comment DML can be easily converted to to load a user reference table.
Bart
Re: RDB$DESCRIPTION missing Posted by: "Helen Borrie"
helebor@...
helebor
Wed Mar 5, 2008 6:34 pm (PST) At 01:00 PM 6/03/2008, you wrote:
Obviously, from a database integrity POV, this is the right and properway to protect a database from stupidity. However, from aself-documentation POV, there's not really any harm to be done bymaking RDB$DESCRIPTION data changes persistent. So, from Fb 2.0onwards, you have to ability to enter a string into an RDB$DESCRIPTIONfield and it will become persistent. It is achieved by way of the newDDL statement COMMENT:
COMMENT ON COLUMN tblviewname. fieldname IS {'txt'|NULL} ;
AFAIK, the rule about doing your own custom changes to system tables via direct DML still applies and won't ever change.
./heLen
____________________________________________________________________________________
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs
[Non-text portions of this message have been removed]
Bart
Re: RDB$DESCRIPTION missing Posted by: "Helen Borrie"
helebor@...
helebor
Wed Mar 5, 2008 6:34 pm (PST) At 01:00 PM 6/03/2008, you wrote:
>All,It's not "loss of data", but loss of illicit changes to metadata.User-entered values in RDB$DESCRIPTION fields (or any other fields)won't survive backup/restore, and that is by design.
>In a number of different Firebird 1.5.3 databases, on differenthosts, I've recently noticed that all RDB$DESCRIPTION values inRDB$RELATIONS and RDB$RELATION_ FIELDS tables have been lost. As anexperiment, I updated those system tables directly for one database,and could query the new values, so it is not an issue of being unableto view data in those BLOB fields; they were null before the update.
>Is there anything that might cause that loss of data in Firebird1.5.3 databases that are otherwise functioning normally? Thanks for anyinsights.
Obviously, from a database integrity POV, this is the right and properway to protect a database from stupidity. However, from aself-documentation POV, there's not really any harm to be done bymaking RDB$DESCRIPTION data changes persistent. So, from Fb 2.0onwards, you have to ability to enter a string into an RDB$DESCRIPTIONfield and it will become persistent. It is achieved by way of the newDDL statement COMMENT:
COMMENT ON COLUMN tblviewname. fieldname IS {'txt'|NULL} ;
AFAIK, the rule about doing your own custom changes to system tables via direct DML still applies and won't ever change.
./heLen
____________________________________________________________________________________
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs
[Non-text portions of this message have been removed]