> My impression was that this editor was registered for
> all components as is the case with TFieldDataLink
> (I guess). It saves the component writer the trouble
> of having to register the editor for each data aware
> component that uses the TIB_FieldDataLink.

There could be reasons why this was not done but I dont know them.

> 2- There seems to be a misunderstanding here. I do not
> need to retrieve defaults, NOT NULL, etc... at runtime,
> something which is possible, but might be expensive as
> you said. But rather at design time where I make sure
> that an IB_Query gets the latest defaults (for example
> by right clicking on it and choosing 'Retrieve Server
> Defaults') so that any INSERT would use these defaults
> until they are explicitly changed by another design-time
> manual 'Retrieve server defaults'.

Sounds like a good idea - perhaps a button on the designtime query
edit form which retrieves the values and inserts/updates the values in
DefaultValues property.

Beware though, the way defaults are designed to be implemented/used at
the server is somewhat different to the intention of defaults at the
client. Many (most?) times the desired default value is the same but
necessarily.

> 3- I have tried setting a default value for a column in
> the IB_Connection, but it does not seem to propagate to
> the query (at least in design time). But I did not
> understand the fetDomainName and fetSQLType. Could you
> shed more light on this issue pls?

There are some timing issues to be considered. If you alter the value
at the connection these are not always immediately reflected at the
query. Sometimes it is necessary to reprepare the query I think.
That is; The connection level properties are really supposed to be
installed and available before you start using queries. I think there
is some propogation of changes but I'm not certain of all the
implications.

Note that anything defined to the query property will override any
definitions at the TIB_Connection level. From memory the
domain/sqltype stuff only works with the TIB_Connection properties,
the TIB_Query properties only use table.field or field name entries.

Here is something I posted to the list back in February which may
help...


In Connection and Datasets Fields* and ColumnAttributes properties the
entries take the form

<Name>=<value>

where <value> is according to the actual property
and where <Name> can be one of...

tablename.fieldname
fieldname
domainname
sqltype


Where domainname and sqltype will only be used by IBO if the matching
flags in the TIB_Connection.FieldEntryTypes are true.

Also where the above list is provided in the order of distinction.
That is; if "tablename.fieldname" exists it will be matched first,
otherwise a search for just "fieldname" will matched, otherwise
domainname etc.


ColumnAttributes:

The only really confusing property is ColumnAttributes, and it is
particularly confusing because I had Jason add the "DefaultNoCase" and
"DefaultNoTrailing" attributes to TIB_Connection (see the online help
for explanations of these).

To look at columnattributes a bit more closely, it takes the form:

name=attrib[=value][;attrib[=value]]...

(or something like that, I have never been very good at syntax
diagrams :-)


The available attributes that can be assigned to "name=" (where name
is one of the values explained above) are (from IB_Contants.pas)...

BINARY Flag a CHAR or VARCHAR column as binary.

BLANKISNULL Used by TIB_Column class when assigning a
blank string to a Fields member.

BOOLEAN Used to tell what values are used to make
this a boolean column.

COMPUTED It tells that the column is actually a
COMPUTED BY derived column.

CURRENCY Flag to indicate a column contains currency.

NOCASE Flag to set a case insensitive search field
can take the form "NOCASE=fielda" to indicate
that "fielda" contains the case insensitive
duplication of the "name" field.

NODATE Indicates DATE field contains only time info

NOSOUNDEX Disable soundex processing in a dataset
(if it was enabled at the connection level)

NOTIME Indicates DATE field contains only date info

NOTRAILING Flag to use STARTING on literal strings

NOTREQUIRED Field is not required, whatever the attributes
may otherwise indicate. (Perhaps it is set
in a trigger at the server.)

REQUIRED Field is required.

SOUNDEX Flag to set a SoundEx search field
can take the form "SOUNDEX=fielda" to indicate
that "fielda" contains the soundex value
of the "name" field.

YESCASE Flag to override connection.DefaultNoCase

YESLIKE Flag to use LIKE on literal strings

YESTRAILING Flag to override connection.DefaultNoTrailing

NOROUNDERR These are used with IBOs ability to interpret
CURR double fields as 53bit integers. This is probably
COMP redundant now that IB6 has 64bit integers.



You will also find that some of the other properties use attribute
style definition - such as FieldsReadOnly. Mostly these are explained
in the online help.

One stringlist that been missed documentation is
TIB_Dataset.OrderingLinks that can take the form of either...

[tablename.]fieldname=n
OR
[tablename.]fieldname=ITEM=n[;POS=m]

It cannot use domainname/sqltype because it refers to particular
fields. The first form describes which item number in the
OrderingItems the link refers to (and so ITEM=n is the same
indication). POS=m is used to indicate how many characters should be
typed before starting an incremental search.


I hope this is of some help.

Geoff Worboys
Telesis Computing