Leyne, Sean wrote: >> The firebird rdb$fields stores nullability value of the domain/column. Then >> the rdb$relation_fields ALSO store the nullability value of the >> domain/column (this looks like the actual override). So firebird still >> doesn't >> support overriding the not null constraint on the domain??? > > You make it sound like this is a problem. It is completely expected and > appropriate. > > If you want to allow NULLs then define a new domain.
Completely agree. Imagine 2 people doing the development. One is data architect, responsible for overall schema and domains. He decides that some domain cannot be NULL and then architect the rest of the system (perhaps even applications) around this fact. Now, imagine the second developer using the system to code some little module. If we allow him to override something that was preset at the very start, it could have unforeseen consequences on the rest of the system. In short, you cannot and should not go from "more constrained" to "less constrained" when you are developing the system. If you need to do so, it most likely shows that you are not doing things the right way. OOP analogy to this would be creating a workaround function to get to private member of the class so that you can alter it without class knowing. It means you are either doing something that should not be done, or that the system was not designed well from the start. -- Milan Babuskov ================================== The easiest way to import XML, CSV and textual files into Firebird: http://www.guacosoft.com/xmlwizard ==================================
