Subject | Re: [IBO] TIBOQuery.insert() without open() ? |
---|---|
Author | Helen Borrie |
Post date | 2003-08-11T04:31:03Z |
At 10:21 AM 11/08/2003 +0700, you wrote:
the parameterised Insert/Edit/Delete statements that you wish to have
executed when the Insert/Edit/Delete methods are called, respectively. You
generally MUST do this, anyway, where your IBOQuery is a joined dataset.
So, for example, the InsertSQL property might be "Insert into Sometable
(list the columns) values :field1, :field2, etc. These parameters are
"described" automatically from the columns of the associated dataset.
can still use the same TDatasource to link to input fields for your data
entry form. In Edit mode, the columns that are specified as parameters in
your EditSQL become editable. In Insert mode, the columns that are
specified in the Values(..) list of parameters will be input-capable. In
either case, call Post to have the xxxSQL executed.
situation where you're "fetching" anything in order to do an edit or an
insert. Don't use Append at all, unless you genuinely *need* to hang a new
row off the bottom end of a dataset.
Helen
>Dear All,Indeed there is. Use the xxxxxSQL properties of the TIBOQuery to provide
>
>Is there a way to insert a record into a TIBOQuery without having to
>call 'open()' first? I'm asking because I'm trying to decouple a 'data
>browsing' form and a 'data entry' form in delphi.
the parameterised Insert/Edit/Delete statements that you wish to have
executed when the Insert/Edit/Delete methods are called, respectively. You
generally MUST do this, anyway, where your IBOQuery is a joined dataset.
So, for example, the InsertSQL property might be "Insert into Sometable
(list the columns) values :field1, :field2, etc. These parameters are
"described" automatically from the columns of the associated dataset.
>For a standard order table, for example, the 'data browsing' form willIt isn't necessary. Even if you display your "browse" set in a grid, you
>need some data from other tables, i.e. customer name, customer address,
>etc, so the sql will involve a join. OTOH, a 'data entry' form's sql is
>usually only 'select * from table', so I'm thinking of separating the
>sql into two TIBOQuery.
can still use the same TDatasource to link to input fields for your data
entry form. In Edit mode, the columns that are specified as parameters in
your EditSQL become editable. In Insert mode, the columns that are
specified in the Values(..) list of parameters will be input-capable. In
either case, call Post to have the xxxSQL executed.
>Now imagine a 'data entry' form connected to a 'select * from table'No. That's what you have to do in IBX, not in IBO.
>query. To do any inserts using data aware components I have (?) to call
>open() first, and then proceed with calling append() and post() later.
>The problem is that the 'data entry' form doesn't need to actuallyExactly. Use TIBOQuery's capabilities as designed and you won't have any
>'fetch' any data from the select statement, I'm just using the 'select'
>to let the TDataset sort out the metadata. I think this is a waste,
>hence my question above.
situation where you're "fetching" anything in order to do an edit or an
insert. Don't use Append at all, unless you genuinely *need* to hang a new
row off the bottom end of a dataset.
Helen