At 07:56 AM 11/03/2004 +0900, you wrote:

>Hi,
>
>I am trying to migrate from IB6.0/IBX to Firebird1.5/IBO4 (WinXP,
>Win2000Server, BCB5). My application looks to TDataSet as an abstract
>interface for table and a tailor-made abstract interface for datamodule. By
>choosing TIBOQuery, table side is ok. I just implemented a derived class of
>datamodule interface with IBObjects (using TIB_Connection and
>TIB_Transaction for connection and transaction).
>
>My application is working fine with Firebird1.5/IBO for showing data. But
>somehow updating or modifying of data doesn't work. I'm getting "unable to
>initialize default EditDSQL" error message.

The cause of this message is that you do not have valid KeyLinks set for
the IBOQuery. IBO will try to set its xxxxSQL properties using the
KeyLinks. However, it can not "guess" which columns are the unique row
identifiers when you use joins. In all cases, you should always inspect
the KeyLinks to make sure they are a) present and b) correct.

KeyLinks are a very essential principle in IBO, because they are part of
the mechanism whereby IBO is able to provide "live" datasets, even with
joined sets. IBX doesn't support live datasets except through the medium
of the TClientDataset. IBO doesn't need it at all.

>I'm using SQL property of
>TIBOQuery but not EditSQL property. Instead I'm using
>ModifySQL/InsertSQL/DeleteSQL properties of TIBOUpdateSQL. I'm setting
>UpdateObject property of TIBOQuery to a corresponding TIBOUpdateSQL.

This should work OK, provided you have correct KeyLinks.

>In some
>situations where I need more than one TIBOUpdateSQL, I'm setting DataSet
>propery of TIBOUpdateSQL to a corresponding TIBOQuery for the second, third,
>... TIBOUpdateSQLs.

I don't understand the logic of this *at all*. If you need to update
multiple tables from an Edit or Delete call on the dataset, the only
healthy way to do this is to write an executable SP with (as a minimum) all
of the KeyLinks as input arguments, which you invoke via the appropriate
xxxxSQL EXECUTE statement. If the argument names match the dataset
columns, IBO will make that happen automatically. If not, you will need to
make assignment statements in BeforePost.

IBO can allow you to make a joined set "naturally live" (i.e. no need for
custom xxxxSQL) if you only want to update one table in the join. To
enable this, set RequestLive true and enter the name of the update table
into the KeyRelation property.

That aside, in any case where you need to use a separate query object to
perform EXECUTE, INSERT, UPDATE or DELETE, in IBO you should use a TIB_DSQL
or a TIB_Cursor and call the operation using Execute.

>This approach works with IBX but I'm a newbie to IBO and I must be making a
>simple mistake. Please help and enlighten me! (Help file for IBO4 seems very
>tacit. Where can I get the information on how to use each IBO component or
>on the background concept?)

The Help file is built on OO principles. If a help item is missing
information, the info will be found in the ancestor class - you can reach
the ancestors by clicking the green Hierarchy speedbutton on the toolbar.

However....for the TIBO* classes, the help file does not inherit the help
from the VCL help file. VCL properties that are exported to the TIBO*
component must be searched in the Delphi help.

Properties that the TIBO* components inherit from the native TIB* wrappers
are exposed in the help file and you should find that they are available
directly. Some TIB_* capabilities are not implemented in the TIBO*
classes; in some cases, they may be available through the InternalDataset
property (of the TDataset descendants).

As a comment, IBX-to-IBO conversions are not always easy; and not always a
good thing to try and emulate. IBX involves a lot of complicated practices
and workarounds to achieve what IBO has always done "naturally". The
IBX-derived architecture that you are trying to implement seems very
unnatural for IBO.

Helen