Subject Re: [IBO] Required Field problem
Author Helen Borrie
At 02:08 PM 4/03/2005 -0800, you wrote:

>I have a table whose primary key is generated via a BEFORE INSERT trigger,
>which calls a UDF.
>
>In my application, I have a TIBOTable object for this table. When I try to
>add a row by calling the TIBOTable's Insert() method, setting some fields
>(not the primary key), and try to post it, I get an exception, saying that
>the primary key field is a required field.
>
>I'm assuming that it's IBO that is generating this error, not Firebird,
>because I can otherwise insert rows (via DSQL) without setting the primary
>key, because the trigger and UDF take care of that. I'm also assuming that
>IBO thinks it's a required field because the field is the primary key and
>marked NOT NULL, and it doesn't know about the trigger.

Correct. If you want to overrule IBO's assumptions based on the metadata,
you must explicitly tell it not to treat the PK as a required field.


>I don't have all of the table's fields explicitly defined in my app as
>TField objects. I just have the TIBOTable object, and I let it figure out
>the fields at runtime. I've found that if I DO explicitly add a TField
>object for the primary key field, and set it's Required attribute to FALSE,
>then it works.

That's OK, fine.


>I'm trying to have this TIBOTable work with more than one "version" of this
>database, where this table's primary key may different, so I really want to
>avoid hard-coding the fields with TField objects. How can I otherwise stop
>IBO from making this a required field at the application level?

The "IBO way" is to set the ColumnAttributes property of your connection
object, by entering a line in that stringlist, as follows:

aTable.aField=REQUIRED=False

The syntax for setting ColumnAttributes at run-time is a tad less
straightforward. Pick up the TI Sheet from the IBO Website, "Working with
Fields and Params" for this.

Helen