Subject | RE: [IBO] Data Aware components - question |
---|---|
Author | Helen Borrie |
Post date | 2004-10-19T01:41:43Z |
At 11:10 AM 19/10/2004 +1000, you wrote:
provide custom xxxxSQL properties, you are indicating that you want a
"live" dataset, i.e. one that can be edited (or inserted to or deleted
from). If you set it to False, you are disabling this ability.
With RequestLive disabled by one means or another, you can still update
tables in the database. You can write DML statements directly into IB_DSL
or IB_Cursor components and Execute them. These statements can (and
should) be parameterised.
It's a perfectly valid application model to make all of your query
components NOT live and to use a button interface to kick off a procedure
to pick up param values from the current row of the query, pass them to the
ib_dsql statement and execute the update/insert/delete. I happen to like
this model a lot. It is very lightweight, both on the wire and in the
client, compared to the editable SELECT. We don't have to be slaves to the
editable grid.
Helen
>Hi,I don't understand the question. When you set RequestLive to true, or
>
> > Yes, under one special set of conditions. If you have a join
> > set and you only want to update one of the underlying tables,
> > you can set RequestLive true AND set the name of the table to
> > be updated in the KeyRelation property. Provide the KeyLinks
> > are perfect, IBO will then automatically construct the
> > correct XXXSQL statements for the DML.
> >
> > Helen
>
>Thank you, I was not aware of this.
>
>If I was to set the RequestLive to False. How do you modify the data via
>TIB_Edit components? As they become disable the moment the RequestLive is
>set to False.
provide custom xxxxSQL properties, you are indicating that you want a
"live" dataset, i.e. one that can be edited (or inserted to or deleted
from). If you set it to False, you are disabling this ability.
With RequestLive disabled by one means or another, you can still update
tables in the database. You can write DML statements directly into IB_DSL
or IB_Cursor components and Execute them. These statements can (and
should) be parameterised.
It's a perfectly valid application model to make all of your query
components NOT live and to use a button interface to kick off a procedure
to pick up param values from the current row of the query, pass them to the
ib_dsql statement and execute the update/insert/delete. I happen to like
this model a lot. It is very lightweight, both on the wire and in the
client, compared to the editable SELECT. We don't have to be slaves to the
editable grid.
Helen