At 04:08 PM 22/08/2006, you wrote:

>Hi all,
>we are upgrading our app to use the latest IB_Objects version, and
>stumbled over this problem.
>
>There have been a change in TIBODataset.GetCanModify that requires a
>dataset to either have set the property RequestLive or CachedUpdates
>to allow inserts.
>
>This conflicts with the following statement in the help description
>for the TIB_Query.RequestLive property "Even if a dataset is not
>"live" it can still be inserted into because in SQL there is no
>concept of a INSERT INTO CURSOR."

No, it doesn't conflict. That's just a statement of the facts, as
was, as is and ever shall be. There is no such thing as a "live
dataset" in SQL. Period.

IBO has always implemented the ability to make a dataset behave as
though it were live, and it can do it in more than one way. It can
do it automatically in the case of datasets that consist of real
output columns from a single table, provided you have the primary key
fields in the output. If RequestLive is true then, under the hood,
it uses the primary keys (KeyLinks) to construct XxxxSQL statements
automatically to insert, update and delete from the underlying table.

>The workaround is to set the RequestLive property.

It's not a workaround. It's what IBO requires (along with clean
KeyLinks) to know what statement it has to construct as the InsertSQL
property.

If you have a more complex output set that e.g. uses joins or derived
output fields, or your KeyLinks are wrong, IBO can't construct the
XxxxSQL statements itself. In that case, you provide your own and,
if they are correct, the dataset will be "live". A variation on this
is a joined set where you want to update/insert/delete records in
only one of the underlying tables. Then you can set the KeyRelation
property of the dataset, provide correct KeyLinks and (usually) IBO
can work out what it needs for the XxxxSQL statements.'

Cached updates is a red herring in this picture. It's virtually
redundant in IBO.

Helen