Date: prev next · Thread: first prev next last
2020 Archives by date, by thread · List index


Bonsoir à toutes et tous,

J'ai été confronté à ce problème il y a quelques temps pour répondre à une question sur la même liste. Voir mon post du 26/01/2020 à 16:47:08 +0100    -     Sujet :/  R/e: [fr-users] Liaison formulaire, sous-formulaires (et entre tables elles-mêmes).

Ce problème fait l'objet du bug 117 053, qui ne semble toujours pas résolu automatiquement lors de la migration, malgré le status VERIFIED – FIXED.
https://bugs.documentfoundation.org/show_bug.cgi?id=117053
_Lionel Elie Mamane __________2018-04-19 12:33:40 UTC     Comment 15_ , donne la solution 1 ci-dessous et renvoie au Comment 11 qui donne la méthode manuelle 2 (cf. ci-dessous)

Cela peut être résolu de deux manière soit :
    1 - par une macro que l’on installe (dans le fichier migré sous FIREBIRD) et que l’on déclenche une seule fois. Après on peut la supprimer le problème étant résolu.
        Sub Main
            ensureConnection()
ThisDatabaseDocument.DataSource.Settings.ParameterNameSubstitution = true
        End Sub

    Sub ensureConnection()
        Dim DBDocUI as Object
        on error resume next
        DBDocUI = ThisDatabaseDocument.currentController
        if not DBDocUI.isConnected then
            DBDocUI.connect
        end if
        on error goto 0
    End Sub

    2 - manuellement (le problème se trouvant dans le fichier content.xml).
         Pour cela, il faut :

 * ouvrir le fichier .odb migré depuis HSQLDB vers FIREBIRD avec un
   gestionnaire d’archive ; (Il ne faut pas qu'il soit simultanément
   ouvert sous LibreOffice).
 * extraire le content.xml ;
 * à l’aide d’un éditeur de texte rechercher la balise
   <db:driver-settings db:system-driver-settings="" db:base-dn=""
   db:parameter-name-substitution="false"/>, et remplacer le "false"
   par "true".
   On peut même supprimer toute la chaine :
   db:parameter-name-substitution="false" semble-t-il.
 * enregistrer le fichier content.xml ;
 * le remettre dans l’archive (xxx.odb) à la place de l’original.

On peut ensuite ouvrir le fichier xxxx.odb, le problème est résolu, il n’y a plus de message d’erreur qui s’affiche, et tout fonctionne parfaitement. Ouf !
Bien cordialement,
Patrick.

------------------------------------------------------------------
Lorsque tu arrives en haut de la montagne, continue de grimper. ;)

Le 02/03/2020 à 19:14, Thierry Jeanneret a écrit :
Bon, je me sens moins seul. Mais ça ne fait pas fonctionner les formulaires, malheureusement...

;-)


Le 2 mars 2020 à 18:01, jean trantecisse <jean.trantecisse@aliceadsl.fr> a écrit :

Je n'ai pas regardé le SQL et c'est bien pour cela que j'ai des craintes.
Comme Thierry, je parle des formulaires. J'ai fais une base pour gérer les postes de bénévoles sur 
une course.
Avant j'avais paramétré des champs maitre et esclaves entre plusieurs sous formulaires. Je cliquais 
sur une catégorie et dans la liste en dessous apparaissait les sous catégories. Je cliquais sur une 
sous catégorie et dans une autre liste apparaissait tous les postes concernés. Je cliquais sur un 
poste dans cette liste et toutes les caractéristiques du poste apparaissaient dans les champs du 
formulaire. Tout cela fonctionnait parfaitement. Maintenant j'ai l'erreur suivante.

Impossible de charger le contenu des données.
firebird_sdbc error:
*Dynamic SQL Error
*SQL error code = -206
*Column unknown
*LINK_FROM_CATEGORIE
*At line 1, column 109
caused by
'isc_dsql_prepare'

J'ai essayé de recréer un formulaire et un sous formulaire avec ou sans l'assistant, ça ne marche 
pas.
De plus dans mon ancienne version, j'ai toujours le message pour migrer la base, c'est saoulant et 
dangereux, un mauvais clic et c'est foutu..

La course approche et, au lieu de pouvoir me servir de mon outil, je suis en train de perdre mon 
temps à essayer de faire refonctionner tout ça.

D'une manière générale, j'ai mis plusieurs année pour arriver à faire des choses qui fonctionne 
correctement avec base et maintenant tout est en train de changer. J'avoue que, par moment, si 
j'avais sous la main ceux qui ont pris cette décision, ...

JT

Le 02/03/2020 à 17:39, J.M a écrit :
Il peut y avoir des codes SQL qui ne sont pas acceptés par Firebird, comme CONCAT à remplacer par ||
De même, Firebird acceptera des noms de champs plutôt raccourcis et sans espaces.
Dans mes récents tests, je n'ai pas rencontré les "plus rien fonctionne", mais sans doute parce que 
j'utilise les versions les plus à jour de LO, celles dont l'intégration de Firebird est la plus pertinente.

Jean-Michel PIERRE
Tél : 06.19.55.73.22

Le 2 mars 2020 à 14:12, jean trantecisse <jean.trantecisse@aliceadsl.fr> a écrit :

Je suis entièrement d'accord avec Thierry. Plus rien ne marche avec firebird. J'avais créé un 
formulaire avec 3 sous formulaires en cascade qui permettait de faire apparaitre les items dus 
choix1 puis du choix 2 et enfin du choix 3.
Plus rien ne marche. Je suis revenu à une ancienne version mais à chaque fois j'ai un message qui 
me demande de mettre à jour.
J'ai essayé de recréer le formulaire mais ça ne fonctionne pas non plus.
J'avais abandonné access pour soutenir le logiciel libre et à cause de ses changements de versions 
qui ne marchait pas.
Là, je dois reconnaitre que le libre arrive enfin au niveau de microsoft en remplaçant un truc qui 
marche par un qui ne marche pas :-)))
Plus sérieusement, on peut espérer une amélioration ?
J'ai réalisé plusieurs bases avec des macros python, je n'ai pas encore essayé mais j'ai des 
craintes.

JT

Le 02/03/2020 à 10:40, Thierry Jeanneret a écrit :
Merci de ta réponse,


Oui j'avais vu cette doc. Mais si elle documente champ par champ, elle ne dit rien de ce qui se 
passe au niveau des formulaires de LibreOffice, qui permettent d'établir des Join.

Lorsqu'on créé un formulaire maitre-esclave (p. ex. en-tête de commande - lignes de commande), on 
reste dans l'environnement de LibreOffice qui s'arrange pour que ça fonctionne. On lui fournit les 
deux champs clés, et quelque part le miracle se produit, le join est créé. Je postule que ça repose 
sur une requête SQL générée automatiquement, et qu'elle suit des règles de nommage standardisées 
qui ne fonctionnent plus avec Firebird. Ou quelque chose d'approchant.

Ca fonctionnait parfaitement avec HSQLDB, mais en essayant de porter la base à Firebird, j'obtiens 
l'erreur que j'ai mentionnée.  J'ai vérifié le nom des champs (mais ils peuvent être différents) et 
leur type, tous deux Integer. C'est donc pas ça…

Le plus surprenant reste que j'ai l'impression d'être le seul sur la planète à avoir utilisé 
vraiment les formulaires Base, en-dehors du FrugalComputerGuy qui me les a présentés sur YouTube. 
Pourtant c'est assez génial, et ça permet de créer une bureautique très proche de l'utilisateur, 
très efficace - quand ça marche.

C'est d'autant plus frustrant lorsque tout à coup la décision est prise de casser ce qui fonctionne 
(pas besoin de gérer des Tera bytes pour un petit bureau, HSQLDB me semble bien suffisant) et 
surtout de ne pas réparer les dégâts que ça entraine.

Encore une fois, j'espère avoir raté quelque chose, mais il me semble avoir plutôt bien cherché.

Dans tous les cas, encore merci, belle journée,

Thierry




--
Envoyez un mail à users+unsubscribe@fr.libreoffice.org pour vous désinscrire
Les archives de la liste sont disponibles à https://listarchives.libreoffice.org/fr/users/
Privacy Policy: https://www.documentfoundation.org/privacy

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.