Subject | Re: [IBO] Re: BDE to IBO Conversion |
---|---|
Author | Helen Borrie |
Post date | 2000-12-19T01:12:39Z |
At 12:57 AM 19-12-00 +0000, you wrote:
been found...
there is no bug in the area you describe, though.
Are you using Cached updates? If not, use the InsertSQL, DeleteSQL and
EditSQL properties for any custom DML. If you don't need custom DML, just
set RequestLive to true.
Hard to help when you don't post the SQL of the dataset, though.
Forget about joinlinks unless the main SQL is a confused join (i.e. SQL-89
syntax with WHERE and JOIN criteria mixed up together in the WHERE
clause). In this case we can't help in any way without seeing your SQL.
Forget about KeyRelation unless you need custom update SQL for a joined
dataset.
The important property is KeyLinks. For a select on one table, it should
be the column name(s) of the primary key. For a joined dataset it might be
a little less straightforward but again, we need to see your select statement.
Helen
InterBase Developer Initiative ยท http://www.interbase2000.org
_______________________________________________________
>Greetings,Using the latest version is a good idea as it tends to fix bugs that have
>
>I was wondering about the status of the TIBOUpdateSQL functionality.
>
>I am new to IBObjects and cannot seem to get TIBOQuery to use the
>TIBOUpdateSQL statements. (I cannot get TIBOQuery to use the its own
>insertSQL, deleteSQL or editSQL query either for that matter).
>
>I have tried various combinations of join links , keyrelations, etc.
>(as described in the help files) and tried with both liverequests
>true and false. The query object insists on providing its own SQL.
>
>
>My IBOObjects code was downloaded around 10/18/00. Any hints? Would a
>more recent download perhaps fix?
been found...
there is no bug in the area you describe, though.
Are you using Cached updates? If not, use the InsertSQL, DeleteSQL and
EditSQL properties for any custom DML. If you don't need custom DML, just
set RequestLive to true.
Hard to help when you don't post the SQL of the dataset, though.
Forget about joinlinks unless the main SQL is a confused join (i.e. SQL-89
syntax with WHERE and JOIN criteria mixed up together in the WHERE
clause). In this case we can't help in any way without seeing your SQL.
Forget about KeyRelation unless you need custom update SQL for a joined
dataset.
The important property is KeyLinks. For a select on one table, it should
be the column name(s) of the primary key. For a joined dataset it might be
a little less straightforward but again, we need to see your select statement.
Helen
>All for Open and Open for All
InterBase Developer Initiative ยท http://www.interbase2000.org
_______________________________________________________