> But it does not explain for me (as a novice user) why NOT NULL must
> be removed from T_USER to work and why T_DATE even works with NOT
> NULL.

> I looked at all the triggers and found no difference which would
> explain it.

As you have discovered, the defaults declared at the database table
level are not very useful with client applications, because usually
they are specifically included in the insert/update statements and the
declared defaults are ignored.

They can be useful if your client will not update the columns. You
can achieve this by telling IBO that the columns are readonly (and so
prevent the insert/update statements from including the columns).

However if you want the user to be able to override the defaults at
the client then the values will be included in the insert/update
statements and you must make appropriate provision for this.

IMO one important provision is to write triggers that will enforce the
desired default values at the server. This helps protect against
problems when attempting to edit records directly using IB_SQL and
other applications. (See my earlier post.)

The next provision is at the client, and here you have choices
depending on your preferences/requirements...

You can simply leave the fields blank/null and let the triggers I
described above take care of assigning the default values - but when
the field is declared as NOT NULL (as above) you need to tell IBO not
to insist on a value at the client level. This can be done either by
setting the CheckRequired property of the dataset to false (effects
all fields) or by setting the NOTREQUIRED column attribute for the
specific columns.

Your other alternative is to provide defaults at the client itself,
using the DefaultValues property. However in the instance of the
username field this is not quite so easy. You can use the OnNewRecord
event to assign a default value (using Connection.Username), or you
can setup macros with similar results. The advantage of this approach
is that the user of the application gets to see the default values
before they post.


So the difference in Helen's example was that the user name was left
to the server-trigger to apply the default, whereas the timestamp was
defaulted at the client. Either could have been done either way, it
is just that a client default for the user name must be done in code
with OnNewRecord.

hth

--
Geoff Worboys - TeamIBO
Telesis Computing