Base/New features in 3 3
- 1 New features in OOo 3.3 Base
- 1.1 Base in general
- 1.2 Forms
- 1.3 Report builder
- 1.4 Table design
New features in OOo 3.3 Base
Base in general
New features "under the hood"
Allow to overrule Base's heuristics for primary key support
There's a new option "Supports primary keys" in the Advanced Settings of a database, which is to overrule Base's heuristics used to detect whether the database it connects to supports primary keys.
This new option is available for database connections via ODBC, JDBC, and ADO.
When connecting to a database via a generic API like ODBC, JDBC, ADO, Base currently applies a heuristics to determine whether or not this database supports primary keys, because none of those APIs has dedicated support to retrieve this information.
Since the heuristics sometimes fails, there's now an explicit option (Edit / Database / Advanced Settings) named "Supports primary keys". It's implemented as a usual tri-state check box, where un/check mean "do (not) assume PK support", and the "undetermined" third state, which is the default, means "apply the heuristics".
Note that if this option is just for overruling the heuristics. If you check it for a database which actually does not support primary keys, you'll probably be slain with error messages as soon as Base attempts to actually use PK related features (like creating a PK in the table designer).
Base now supports updates on more than one table
Base now supports updates on more than one table.
Updates are only possible when the row can be fetched right after it was inserted/updated to get all default or changed values by the underlying database. To allow updates on a query on more then one table, all primary keys (all columns which are part of the primary keys) must be in the select list. Base now checks which prerequisite exists and then decide if the query is modifiable or not.
Base now supports database registrations configured as read-only
Base now supports database registrations which are declared as read-only.
Database registrations are normally maintained via Tools/Options/Databases. The registrations are stored in OpenOffice.org's configuration, which means it is also possible to deploy additional configuration fragments (e.g. via extensions) which contain additional registrations. If those configuration fragments are declared as read-only (by using the usual configuration mechanisms for this), then the UI now respects this, by disallowing modifications (editions, removal) of this registration entry.
Extending database drivers by extension
Detailed information can be found here:
From linked specification:
Extending existing SDBC drivers by extensions is described here, Most drivers miss to support special features like to alter view definitions or to add or drop key of a table. Therefor these interfaces
can be implemented by an extension.
To enable the needed feature the extension has to extend the properties entry of the configuration of the driver. The configuration entry below the properties entry will be checked and if the service name can be instantiated it will be used to do the job. Below you'll see a table of mapping from configuration entry to service name.
Configuration name Interface name which has to to be implemented
In favor to allow to get the definition of queries, forms and reports from other locations as the default file format specification, an extension may implement a service which implement the following named interfaces.
The configuration entries are named
which all have to implement the interfaces
Ctrl+F5 now toggles between the document and the nearest form control
Ctrl+F5, which used to focus the first (by a definition which is hard to understand by the average user) form control in a document, has changed its behavior: It now focuses the form control nearest to the current cursor position, if the focus is not within a form control currently. Otherwise, it gives the focus back to the document view.
Form controls use the same text rendering as the containing document
This new feature does not really belong to Base only.
The way how controls render their text has changed. Well, this applies to some controls, in some documents, at least.
In general, the OOo applications format their text on the screen using a so-called reference device, which might either be the printer selected for the document, or a virtual device (which one is controlled by a per-document option).
Form controls previously never participated in this game, they always formatted their text according to the screen they were displayed on. As a consequence, form controls which were embedded in the text flow of the containing document broke the document layout when viewed on different devices (print preview, printer, PDF export), or even only when viewed in different zoom levels on the screen.
Now, non-input form controls (radio buttons, fixed texts, check boxes, group boxes, command buttons) use the document's reference device for rendering their own text, thus providing a better integration into the surrounding document text.
This behavior can be enabled on a per-application level, more precise, on a per-module level. There's no UI for changing the behavior.
Instead, the existing configuration structure below the /org.openoffice.Office.Common/Forms/ControlLayout has been extended, so that now for instance the node .../ControlLayout/com.sun.star.sheet.SpreadsheetDocument/UseDocumentTextMetrics
controls whether the reference device text rendering for controls is enabled in spreadsheet documents.
By default, the usage of the document's reference device is enabled for text documents, drawings, and presentations, and disabled for all other document types (spreadsheets, database forms, database reports).
Text(-like) input form controls also support the "Vertical Alignment" property
Input form controls (text fields etc.) now also support the "Vertical Align" property known from non-input controls like fixed texts etc.
Add Field dialog now accessible via keyboard
In the Report Designer the Add Field dialog can be accessed via the shortcut ALT+F8.
New MetaData node for Database drivers to view column descriptions from the database
Now it is possible to define a new property in the drivers xcu file. Per default this is enabled for MySQL (JDBC) and Ado (including Access, Access only allows to view it, it can not be changed).
When this is enabled the table designer will display the column description, beside the former normal description which is used as help text. The column description is used has help text when the normal description is empty otherwise the normal description is used.