Subject | Re: [IBO] ColumnAttributes with BOOLEAN Domain |
---|---|
Author | Lucas Franzen |
Post date | 2003-02-18T19:24:19Z |
"mag_jung " schrieb:
TIB_Connection to true so that the domain informations will be retrieved
after connecting.
Then set the ColumnAttributes property of the TIB_Connection.
Now you can drop this property at your Queries (it should be obsolete
now).
Additionally:
you can make an entry in the TIB_Connection.DefaultValues like:
BOOLEAN=BOOLEAN=j,n
which will automatically assign new values the appropriate value on
inserting.
Note:
I think, naming a domain BOOLEAN is asking for trouble within the next
versions.
Think about finding a naming convenience, and name eg. domains
T_SOMETHING or D_STH.
If you follow that rule for triggers, procedures, constraint, indexess,
and.. and.. you'll notice that even a big database (in the meaning of
with lots of metadata, not data) is easy to maintain and understand.
Just my 2c
Luc.
>You have to set the FieldEntryTypes.fetDomainNames property of the
> Hi,
>
> I'm using the the TIBO_Query component.
> My Database has a Domain called BOOLEAN with values ("j", "n")
> When I set the Columnattributes to FIELDNAME=BOOLEAN=j,n everything
> works
> fine.
> I read in the tech sheet that I can use Domains instead of
> Fieldnames, which
> would reduce the efford to simulate boolean fields to zero.
> So I set TIB_Connection.Columnattributes to "BOOLEAN=BOOLEAN=j,n"
> But it doesn't work...
>
> what am I doing wrong ?
TIB_Connection to true so that the domain informations will be retrieved
after connecting.
Then set the ColumnAttributes property of the TIB_Connection.
Now you can drop this property at your Queries (it should be obsolete
now).
Additionally:
you can make an entry in the TIB_Connection.DefaultValues like:
BOOLEAN=BOOLEAN=j,n
which will automatically assign new values the appropriate value on
inserting.
Note:
I think, naming a domain BOOLEAN is asking for trouble within the next
versions.
Think about finding a naming convenience, and name eg. domains
T_SOMETHING or D_STH.
If you follow that rule for triggers, procedures, constraint, indexess,
and.. and.. you'll notice that even a big database (in the meaning of
with lots of metadata, not data) is easy to maintain and understand.
Just my 2c
Luc.