hi Helen
"3.It is not written if the column name is supplied in the column list."

i think ibo written null value the coulmn name is supplied because
"select * from table"
this is automatic

here TIB_QUERY double click show the dialog box
in tab field display 3 grid column with gray color say :
last_update |(timestamp) timestamp /*dv-current_timestamp */ | DF
last_user |vartext) varchar(30) /*cs=none */ /*dv=current_user */ | null df

and the ddl
LAST_UPDATE TIMESTAMP_1 DEFAULT current_timestamp NOT NULL /* TIMESTAMP_1 = TIMESTAMP */,
LAST_USER VARCHAR30 DEFAULT CURRENT_USER /* VARCHAR30 = VARCHAR(30) */,

so if the ib_query.text=select * from
null value has write to last_user

last user has correct value if select field1,field2 from table and last_user not list in field1..field end

any sugestion?

--- In IBObjects@yahoogroups.com, Helen Borrie <helebor@...> wrote:
>
> At 12:00 PM 1/02/2012, ming wrote:
> >hi all
> >
> >my problem for default value still error in ibo even i use the newest ibo, any sugestion for my problem?
>
> I think you misunderstand how the Firebird/IB column default works...
> 1. It works ONLY for an insert; AND
> 2. It is not available until the record is written to disk; AND
> 3. It is not written if the column name is supplied in the column list.
>
>
> >because the trigger can be alternative but i think not eficient for every table i must add before insert for 1 field only type data varchar.
> >
> >Need solution, any body help me please...
>
> You could provide custom InsertSQL for your datasets, leaving the defaulted column out of the INSERT statement.
> *or*
> You could use the DefaultValue attribute of the field in the dataset. However, this is not ideal as it binds your application layer to the database too tightly.
> Along the same lines, if you are using domains for these columns, you can use IB_Connection.DefaultValues to provide domain_name=value strings for any application level. This still has the tight binding limitation.
>
> In my view, the Before Insert trigger is the only good solution from the point of view of data integrity. If you write it correctly, you will always get the value you want, regardless of the application. The SQL default is almost entirely useless.
>
> Why do you think it is too much work? Are you maintaining proper DDL scripts for your databases?
>
> Helen
>