This service specifies a form which is connected to a database and
displays the results of SQL queries. It provides the possiblity of
adding new data records, modifying existing ones, or deleting them.
A database form is a special kind of enhanced database row set
which provides all information for displaying the data and has more
possibilities for configuring the data manipulation.
is a client side RowSet, which use retrieves is data based on a database table,
a query or a SQL command or by a rowset reader, who mustn't support SQL.
The connection of the rowset is typically a named DataSource or a DataAccess component
or a previous instanciated connection.
is a client side RowSet, which use retrieves is data based on a database table,
a query or a SQL command or by a rowset reader, who mustn't support SQL.
The connection of the rowset is typically a named DataSource or a DataAccess component
or a previous instanciated connection.
is used to reset controls belonging to the form, and to reset database fields to which the
controls are bound
A DataForm is reset either on explicit request, or after it is moved
to the insertion row.
The insertion row is a virtual row which is used to insert new records. It is reached
by calling ::com::sun::star::sdbc::XResultSetUpdate::moveToInsertRow.
The ::com::sun::star::sdb::RowSet service specifies exactly which notifications
happen in which order when calling ::com::sun::star::sdbc::XResultSetUpdate::moveToInsertRow,
and a DataForm implementation extends this with the following contract:
After all notifications as defined in the ::com::sun::star::sdb::RowSet
service have been sent, the DataForm resets itself, if all
com::sun::star::form::XResetListeners approve this.
After the reset happened, the ::com::sun::star::sdb::RowSet::IsModified
property is reset to false. This property might have been switched to true during listener
notifications, since listeners are allowed to change field values. Also, the
::com::sun::star::form::XReset::reset implementations of bound control
models might have modified the fields they're bound to (by filling them with default values).
The reset listeners are notified of the completed reset operation.
Loading a form is basically the same as executing the underlying row set. In fact, all the
functionality of this interface could be simulated by using setting some properties manually,
::com::sun::star::sdbc::XRowSet::execute, moving the row set cursor and so on.
One main difference between ::XLoadable::load and ::com::sun::star::sdbc::XRowSet::execute
is that if you use the former, the row set is positioned on the first record, while in the latter case
it is position before the it.
can be used to allow an interaction handler to supply missing data during a load process.
If data is needed during loading a form, then this is usually obtained via broadcaster-listener
mechanisms. An example for this (and currently the only one) are parameter values.
However, if you use this method, you can pass an interaction handler which should supply these
additional data.
You can add your component as
::com::sun::star::form::XDatabaseParameterListener
to a form to get notified whenever the form needs parameter values to be filled in
In a first approach, the form tries to fill any parameters from it's master-detail relation
(if any). All values which can't be filled are then passed to all listeners, which can
fill them by their own choice.
This is sligtly changed if the form is loaded using the
::com::sun::star::sdb::XCompletedExecution::connectWithCompletion method. In this case, the parameters
are obtained from the interaction handler, not from the listeners
is used for subforms and contains the names of columns of the parent form.
These columns are typically the foreign key fields of the parent form.
The values of theses columns are used to identify the data for the subform.
Each time the parent form changes it's current row, the subform requeries
it's data based on the values of the master fields.
If the form is no sub form (e.g. it's parent is not a form itself), this
property is not evaluated.
is used for subforms and contains the names of the columns of the subform
which are related to the master fields of the parent form.
Entries in this sequence can either denote column names in the sub form,
or paramater names.
For instance, you could base the form on the SQL statement
SELECT * FROM invoices WHERE cust_ref = :cid, and add cid
to the DetailFields property. In this case, the parameter will be filled from
the corresponding master field.
Alternatively, you could simply base your form on the table invoices,
and add the column name cust_ref to the DetailFields. In this case,
and implicit filter clause WHERE cust_ref = :<new_param_name> will
be created, and the artificial parameter will be filled from the corresponding
master field.
If a string in this property denotes both a column name and a parameter name, it
is undefined which way it is interpreted, but implementations of the service are required
to either decide for the paramter or the column, and proceed as usual.
The columns specified herein typically represent a part of the primary key
fields or their aliases of the detail form.
If the form is no sub form (e.g. it's parent is not a form itself), this
property is not evaluated.
determines if insertions into the form's row set are allowed.
Note that this is a recommendation for user interface components displaying the
form. Form implementations may decide to allow for insertions done via the API, even
if the property is set to false, but the user interface should respect the property
value.
determines if modifications of the current record of the form are allowed.
Note that this is a recommendation for user interface components displaying the
form. Form implementations may decide to allow for updates done via the API, even
if the property is set to false, but the user interface should respect the property
value.
determines if deletions of records of the form are allowed.
Note that this is a recommendation for user interface components displaying the
form. Form implementations may decide to allow for deletions done via the API, even
if the property is set to false, but the user interface should respect the property
value.
