Revision as of 13:56, 18 May 2009

Nouvelles fonctionnalités de base de données dans OOo 3.1

Compilé depuis les fonctionnalités de la liste de diffusion dba openoffice org et les applications référencés.

Base Général

Macros dans les fichiers de base de données

Les fichiers de base de données (.odb) permettent maintenant l'intégration de macros et de scripts, de la même manière que les autres types de documents.

Jusqu'à maintenant, les macros pouvaient être intégrées dans les sous-documents d'un document de base de données, c'est à dire les formulaires et rapports (qui techniquement sont des documents texte), elle n'auront dorénavant qu'un emplacement, le document de base de données.

Ce qui signifie que quand toutes les macros seront déplacées des formulaires dans la partie principale de la base de données, l'assignation de macros à des éléments d'un formulaire ne sera possible que depuis le document de base de données, et pas avec les macros du formulaire. Les macros peuvent être exécutées soit du document lui-même, ou de chacun de ses sous-composants : Formulaires, rapports, ébauche de table, ébauche de requête, ébauche de relation, vue. Une macro peut-être affectée à une barre d'outils, un menu, ou tout sous-composant. Lors de l'enregistrement d'une macro dans un formulaire ou un rapport, la boîte de dialogue finale qui vous permet de choisir ou stocker la macro ne listera plus les formulaires et rapports, mais le document de base de données.

Migration

Les documents de base de données créés avec des versions antérieures à Apache OpenOffice 3.1 peuvent contenir des formulaires ou rapports avec des macros ou scripts intégrés. Maintenant que c'est interdit, un chemin de migration est nécessaire.

Le but est de transformer les documents pour que tous les scripts et macros soient dans le fichier de base de données, et ceci ne peut-être réalisé automatiquement.

Précautions de compatibilité

Si l'utilisateur ouvre simplement un "vieux" document contenant des macros et/ou des scripts dans ses sous-documents, il n'aura qu'une boîte d'avertissement de compatibilité, à la première ouverture de ce fichier. Jusqu'à ce que l'utilisateur ait migré les macros, le document de base de données, et tous les sous-documents se comporteront comme si la fonctionnalité n'avait jamais été implémentée. En particulier, l'utilisateur est libre de créer des macros supplémentaires ou de modifier les macros existantes dans ses formulaires et rapports, de personnaliser les macros des sous-documents dans les menus et barres d'outils, de lier ces macros à des evénements dans les sous-documents, et ainsi de suite.

Assistant de migration

Ajout d'une nouvelle entrée de menu, appelée "Migrer les macros...", située dans la section supérieure du menu "Outils", immédiatement sous l'entrée "SQL..." existante.

Quand l'utilisateur sélectionne cette entrée de menu, un assistant le guide dans le processus de migration, qui suit concrètement les étapes suivantes :

Fermer tous les sous-composants du document de base de données, formulaires, rapports, et tout autre objet en mode modification.
Copie de sauvegarde du fichier de base de données
Migration des scripts et des macros avec affichage d'une jauge de progression
Affiche un sommaire

Pour une description détaillée de la fonctionnalité, vous ête encouragé à lire cette spécification :

http://wiki.services.openoffice.org/wiki/Macros_in_Database_Documents

Accès facilité aux documents formulaires/rapports par programmation

L'accès par programmation aux formulaires et rapports contenus dans les documents de base de données est plus facile qu'auparavant :

ThisDatabaseDocument.FormDocuments.getByName( "NomFormulaire" ).open

ThisDatabaseDocument.ReportDocuments.getByName( "NomRapport" ).open

Ouvrira le formulaire "NomFormulaire", ou le rapport "NomRapport", tout à fait de la même manière qu'un double clic sur le formulaire dans l'interface graphique le ferait, par exemple en appliquant les changement appropriés dans l'interface graphique.

Nouveaux réglages de configuration pour les chemins des pilotes pré spécifiés

(New configuration setting for pre-specifying per-driver classpaths)

Il y a un nouveau réglage dans le module de configuration org.openoffice.Office.DataAccess qui permet de spécifier, sur la base d'un pilote donné, un chemin de classe à utiliser lors de la recherche d'un pilote JDBC.

Un administrateur d'une installation partagée d'OOo peut utiliser ce réglage pour pré-configurer l'installation, sans que tous les utilisateurs aient besoin d'ajouter l'archive .JAR respective à leurs propres options Java.

Le chemin complet du nouveau noeud de configuration est

/org.openoffice.Office.DataAccess/JDBC/DriverClassPaths.

Un extrait d'exemple de configuration :

</prop>

</node>

L'ébauche de relation est notifiée quand la structure de la base de données change

L'ébauche de relation détecte maintenant quand une nouvelle table ou de nouvelles colonnes sont ajoutées. La boîte de dialogue "Ajouter une table" est également notifiée quand une nouvelle table a été ajoutée.

L'ébauche de relations supporte maintenant l'auto-référencement des relations des tables

La fenêtre d'ébauche de relation prend maintenant en charge la création de relations "réflexives", ou la table de référence est également la table référencée.

Table

Chemin relatif pour les bases de données fichiers

Jusqu'alors, quand vous créiez une base de données "fichiers" (comme le format dBase ou une feuille de calcul), l'URL des fichiers (appelons là "URL des données") était stocké de manière absolue - quelque chose comme "[../../../foo/bar file:///c:/foo/bar]".

Le résultat quand vous déplaciez le document de base de données (le fichier .odb) avec les données sur une autre machine, vous deviez soit dupliquer la structure de fichiers sur la machine cible, ou ajuster les réglages pour la base de données.

Il est maintenant possible que ce chemin soit stocké relativement en cochant l'option "Enregistrer les URL relatifs au système de fichier" accessible via "Outils > Options > Chargement/enregistrement > Général".

L'ébauche de table manipule la clé primaire différemment de hsqldb

Ceci concerne uniquement le mteur hsqldb.

Quand l'utilisateur ajoute une clé primaire auto-incrémentée cette dernière devient automatiquement la cle primaire de la table. Si l'utilisateur supprime après coup le drapeau de la clé primaire, le drapeau d'autoincrémentation sera également supprimé.

Hsqldb ne supporte qu'une seule colonne autoincrémentée qui doit donc être aussi l'unique colonne clé primaire.

PS: Une clé primaire peut consister en plus d'une colonne, ce qui n'est pas le cas pour hsqldb quand une colonne autoincrémentée est utilisée.

Les vues ouvertes pour édition sont automatiquement dans le mode "SQL direct"

Quand vous ouvrez une vue de table pour éditer sa commande SQL (fonctionnalité actuellement prise en charge seulement pour les bases HSQLDB intégrées), l'éditeur de requête passe automatiquement dans le mode "Exécution directe de commande SQL".

Requête

Paramètres reconnus dans les listes d'arguments de fonctions

Le parser d'OOo a la possibilité de reconnaître les paramètres dans les listes d'arguments de fonctions. Autrement dit, une requête comme :

SELECT CONCAT( :C, "nom" ) FROM "nom" présentera maintenant correctement la boîte de dialogue demandant à l'utilisateur la valeur du paramètre.

Édition de requête : Syntaxe SQL étendue

Le parser SQL reconnait maintenant la commande TRIM correctement.

Il prend également en charge

TRIM( FROM <NOM_COLONNE> )

comme une forme abrégée de

TRIM( BOTH FROM <NOM_COLONNE> )

Ces fonctions suppriment les blancs en tête et en fin d'une chaîne de caractères.

Surlignage de la syntaxe SQL

Prise en charge du surlignage de la syntaxe SQL pour les vues SQL dans Base, y compris la commande Outils > SQL...

La police utilisée pour la vue SQL respectera les mêmes réglages que pour le HTML et BASIC IDE ; toutes les couleurs utilisées peuvent être configurées.

Spécification:

http://wiki.services.openoffice.org/wiki/SQL_Syntax_Highlighting

Formulaire

Contrôles de formulaire : Nouvelle propriété : "Direction du texte"

Tous les contrôles de formulaires possèdent une nouvelle propriété "Direction du texte", qui... contrôle le sens du texte. Pour les langues écrivant de droite à gauche, Arabe, Hébreu, Hindou etc., les formulaires auraient l'air étrange s'ils devaient se plier à l'unique sens de gauche à droite.

Cette nouvelle propriété se trouve dans la boîte correspondante, onglet Général sous "Champ d'étiquette" si l'option "Activer pour les scripts complexes" est cochée dans Outils > Options > Paramètres linguistiques > Langue.

Voir les spécifications pour plus de détails :

http://specs.openoffice.org/g11n/Right-to-left_control_forms/R2L-enabled_control_forms.sxw

Contrôles de formulaire : Nouvelle propriété "Saisie requise"

Tous les contrôles de formulaire qui peuvent être attachés à une colonne de base de données (ayant la propriété "Champ de données") ont maintenant une nouvelle propriété appelée "Saisie requise". Elle se situe dans la fenêtre des propriétés, onglet Données, sous la propriété : "Espace vide égale NULL"

Cette propriété vérifie si oui ou non ce champ interdit les entrées vides (NULL). Elle est évaluée pour les contrôles qui sont liés à un champ de base de données défini comme requis (auquel il n'est pas permis d'avoir la valeur spéciale NULL), immédiatement avant que l'enregistrement en cours dans le formulaire ne soit enregistré dans la base de données.

Si la propriété est définie à "Oui", et que le champ ne contient aucune donnée quand l'enregistrement en cours est sur le point d'être enregistré, un message d'erreur est envoyé à l'utilisateur, et le contrôle concerné est sélectionné.

If the property is set to "Yes", and the field contains no input when the current record is to be written to the database, then an error message will be shown to the user, and the respective control will be focused afterwards. Note that this is the known behaviour so far Ã¢ÂÂ the property defaults to "Yes" so that newly created controls behave as they would do in previous OOo versions.

If the property is set to "No", and the field contains no input when the current record is to be written to the database, then this is ignored. It's up to the underlying database to either reject the update, or fill the respective column with a server-side default value.

If the "Form data input checks for required fields" option in the advanced settings of the database document (Edit / Database / Advanced Settings ...) is *not* checked, then the "Input required" property for all controls in all forms in this database document does not have any effect, since the document-wide setting overrules the per-control settings.

If the "Data field" is not set (i.e. empty), then "Input required" is disabled, since it would be evaluated for bound controls only, anyway.

If the "Empty string is NULL" is set to "No", then "Input required" is also disabled, since "Empty string is NULL" being "no" implies that when the user does not enter any value in the control, then an empty string, instead of the dedicated value NULL, is written, so there's always a non-NULL value no matter the user's action.

"Empty string is NULL" behavior refined

The behavior of form controls whose "Empty string is NULL" property is set to "Yes" has been refined. This change might make existing forms behave slightly different than before, but certainly more expectation-conformant now.

First, the property is now also respected when you never touched the respective control before saving the record. That is, imagine a control which has this property set to "Yes", this way declaring that if the control contains an empty string, then this should be propagated to the database as (the dedicated) NULL value.

Formerly, when you moved to the insertion row of the form, so the control was initially empty, entered some data into other controls of the current record, and saved the record without actually touching the first control, then it actually updated an empty string. Now, with the change, it updates NULL, as this is what "Empty String is NULL" = "Yes" requests.

Second, when a control was bound to a database column which was declared as NOT NULL, then the control *always* updated an empty string instead of NULL, no matter what its "Empty string is NULL" property requested. Effectively, this killed server-side defaults of database fields, as such defaults are only applied when the field is NULL. Now, with the change, controls always update NULL in such a setup, this way enabling server-side defaults.

Check box: modified property

Check box columns in grid controls now have the "Tristate" property, which controls whether or not the "indetermined" state is allowed for the check box, as known from ordinary check box form controls.

Image controls: scaling the image by keeping the ratio

Image form controls in documents got an additional mode for scaling the image they display.

Previously, you could control the scaling by setting the "Scale" property to "Yes" or "No" only, where "Yes" implied an anisotropic scaling, i.e. one which distorted the image's dimensions.

Now, the "Scale" property allows the values "No" (same as before), "Keep Ratio" and "Fit to Size" (equivalent to the old "Yes"). When "Keep Ratio" is selected, the image is still scaled up or down to match the control dimensions, but it's ratio is aspect kept constant.

This is especially useful for controls where the designer of the document does not know, at time of designing the document/control, the dimensions of the to-be-displayed images. In particular, this is useful for image controls in database forms, displaying images obtained from the database.

Image controls: support for document-embedded images

Image controls can now be bound to images which are embedded in the document where the control lives in.

More precise, when you select an image to be displayed at an image control, the "Link" option in the file picker is not disabled anymore.

When you uncheck the option (the default is "checked", to mimic the legacy behavior), then the image is displayed in the control, and upon saving the document, it's embedded in the document itself.

This way, you can create documents with image controls which are exchangeable with other people/installations/platforms, which formerly was much more difficult due to the need to also copy the images, and place them in exactly the same location as on the originating machine (which often is simply impossible).

Image controls: can be bound to text database columns, interpreting their content as relative link to the image

Image controls in database forms can now be bound to text columns. Formerly, you could only bind them to columns whose content could reasonably be interpreted as binary (BLOB etc.). Now, when you select a text database column as source for the image control, then it will interpret the content of the respective column's content as URL, and load and display the image pointed to by this URL. Also, the URL might be relative to the document which the image control is embedded into.

Navigation Toolbar: new item "Refresh Control"

In the Form Navigation Toolbar (the one used as soon as you have an alive form filled from a database), there's a new item, called "Refresh Control", located right after the "Refresh" item.

This new item is enabled if and only if a list or combo box control has the focus. When pressed, the item list of the control is refreshed.

This is particular interesting for lists based on the content of a table (or query) of the database, when some instance outside the form did changes to this table/query's data. In this case, you can reflect those changes in the control's item list by using the "Refresh Control" function.

Report

New short cuts for Sun Report Builder

The Edit menu now contains a "Select All" entry.

Which contains:

Edit>Select All -> Select All (CTRL+A)

                  Select all Labels
                  Select all Formatted Fields 
                  Select Report

Automatic binding of first table when opening a new Report

When creating a new report in a database, the report will be bound to the first table from the database. Additionally the Add Field dialog will open with all available fields.

Report output format now also available in the property browser

The property browser now shows the selected output format for a report on the Data page, last item under Filter, when it is selected in the SRB.

Currently available formats are:

- ODF Text Document

- ODF Spreadsheet

Add Field dialog supports sorting and insert toolbar

The Add Field dialog now has a toolbar above the listbox for the fields. The toolbar allows to sort the fields ascending and descending as well to remove the sort order and restore origin order from the source (table,query). Additional the toolbar contains an "Insert" entry which allows to insert the selected fields into a report section. Multi selection of fields is also supported.

Function Autopilot from inside the SRB

The Function Autopilot which is used in the spreadsheet can now be used inside the Sun Report Builder.

The Autopilot can be started from:

- the data field ( formatted field and image control)

- the conditional print expression, on general tab.

http://wiki.services.openoffice.org/wiki/SUN_Report_Builder/Documentation#Report_Navigator_-.3E_Report_-.3E_Functions_-.3E_Function_-.3E_Properties_of_General_Tab

- the formula

- the initial value

The Autopilot shows all functions which are supported by the report engine.

The documentation for the SRB can be found here:

http://wiki.services.openoffice.org/wiki/SUN_Report_Builder/Documentation

The functions description can be found here:

http://wiki.services.openoffice.org/wiki/Base/Reports/Functions

@@ Line 150: / Line 150: @@
 == Contrôles de formulaire : Nouvelle propriété "Saisie requise" ==
-All form controls which can be bound to a database column (i.e. have the "Data field" property) now have a new property called "Input required". New property can be found on Properties, Data tab, below the "Empty string is NULL"
+Tous les contrôles de formulaire qui peuvent être attachés à une colonne de base de données (ayant la propriété "Champ de données") ont maintenant une nouvelle propriété appelée "Saisie requise". Elle se situe dans la fenêtre des propriétés, onglet Données, sous la propriété : "Espace vide égale NULL"
-This property controls whether or not the input of this field is checked against being empty (NULL). It is evaluated for controls which are bound to a database field which is defined as required (i.e. Which is not allowed to contain the special NULL value), immediately before the current record of the form is to be written into the database.
+Cette propriété vérifie si oui ou non ce champ interdit les entrées vides (NULL). Elle est évaluée pour les contrôles qui sont liés à un champ de base de données défini comme requis (auquel il n'est pas permis d'avoir la valeur spéciale NULL), immédiatement avant que l'enregistrement en cours dans le formulaire ne soit enregistré dans la base de données.
+Si la propriété est définie à "Oui", et que le champ ne contient aucune donnée quand l'enregistrement en cours est sur le point d'être enregistré, un message d'erreur est envoyé à l'utilisateur, et le contrôle concerné est sélectionné.

Difference between revisions of "FR/Documentation/Base/Nouvelles Fonctions 3 1"