Forum OpenOffice LibreOffice NeoOffice

Bonjour,

Solution proposée pour contourner une absence de mise à jour d'un formulaire et son contrôle table dont la source est une requête.

Base de données MySQL avec LO Base comme interface utilisateur.
J'ai un formulaire comprenant :

Une liste déroulante dans laquelle l'utilisateur choisit un item

un contrôle table dont le contenu est lié à la source du formulaire, en l’occurrence une requête SQL. Elle est mise à jour selon le choix fait dans la liste déroulante grâce à une macro qui modifie la requête SQL selon le choix dans la première liste et utilise l'instruction .reload pour actualiser le formulaire et le contrôle table. Classique ! Cf copies écran ci-dessous.

Ecran choix 1.png

Ecran choix 2.png

Dans un premier temps, la requête SQL source était unique, écrite dans une variable de la macro et la commande form.reload mettait à jour le contrôle table sans problème.

Mais la demande étant plus complexe, j'ai dû créer 2 requêtes successives enregistrées avec les autres requêtes de Base. La première est actualisée à la volée par la macro, la 2e (source du formulaire) est basée sur la première. A partir de ce moment-là, la commande .reload ne met plus à jour le contrôle table (alors que les requêtes sont bien mises à jour) sans que je comprenne pourquoi.

Solution (qui est un contournement) :
dans le code, j'ai fait 2 étapes où je change chaque fois la source du formulaire plutôt que seulement mettre à jour les requêtes SQL. Le fait de changer la source du formulaire semble « obliger » à une actualisation et ça marche.
Extrait de code ci-dessous.

Code : Tout sélectionner

'****1ere étape : on donne une nouvelle source au formulaire (qui n'affichera rien). Passage obligatoire pour que le formulaire prenne en compte la phase suivante.

StrSql = "SELECT `Herbier micromycètes`.`CodEspM`, `Herbier micromycètes`.`Stade`, `Herbier micromycètes`.`Etat`, `Herbier micromycètes`.`N°Her` `Herbier`, `Espèces`.`NomEsp` `Hôte`, `Espèces`.`NomSsp` `Ssp Hôte`, `Genres`.`NomGen` `Genre hôte`, `Herbier micromycètes`.`Date`, `Stations`.`Lieudit`, `Communes`.`NomCom` FROM `botamyco`.`Espèces` `Espèces`, `botamyco`.`Herbier micromycètes` `Herbier micromycètes`, `botamyco`.`Communes` `Communes`, `botamyco`.`Stations` `Stations`, `botamyco`.`Espèces micromycètes` `Espèces micromycètes`, `botamyco`.`Genres` `Genres` WHERE `Espèces`.`CodHot` = `Herbier micromycètes`.`HotEsp` AND `Communes`.`CodCom` = `Stations`.`CodCom` AND `Stations`.`CodSta` = `Herbier micromycètes`.`CodSta` AND `Espèces micromycètes`.`CodEspM` = `Herbier micromycètes`.`CodEspM` AND `Genres`.`CodGen` = `Espèces`.`CodGen` AND `Herbier micromycètes`.`CodEspM` = 0"

vForm1.command = StrSql  'attribution de la requête SQL
vForm1.reload  'rechargement du formulaire

'*****2e étape : on revient aux requêtes source qui nous intéressent.
'1ere requête pour agréger différentes valeur avec une requête UNION

StrSql = "SELECT `CodEspM` FROM `botamyco`.`Espèces micromycètes` `Espèces micromycètes` WHERE `CodEspM` = " & ctlval & " UNION DISTINCT SELECT `CodValM` FROM `botamyco`.`Espèces micromycètes` `Espèces micromycètes` WHERE `CodEspM` = " & ctlval & " UNION DISTINCT SELECT `Espèces micromycètes_1`.`CodEspM` FROM { oj `botamyco`.`Espèces micromycètes` `Espèces micromycètes_1` LEFT OUTER JOIN `botamyco`.`Espèces micromycètes` `Espèces micromycètes` ON `Espèces micromycètes_1`.`CodValM` = `Espèces micromycètes`.`CodEspM` } WHERE `Espèces micromycètes`.`CodEspM` = " & ctlval

'Mise à jour de la requête enregistrée spécifiquement pour cette instruction à partir de la formule SQL ci-dessus
oConnexion.queries.getByName("Rqtunionrechµm").Command = StrSql

'Prise en compte d'une 2e requête « ResultrechµM » qui dépend de la 1ere que l'on récupère par une phrase SQL simple :
StrSql = "SELECT * FROM `ResultrechµM`"

vForm1.command = StrSql    'attribution de la 2e requête SQL au formulaire
vForm1.reload    'rechargement du formulaire

Ceci à toutes fins utiles si d'autres sont confrontés à ce blocage.
Et je suis bien-sûr très intéressé par les remarques qui permettrait de comprendre et d'avoir une actualisation sans cet artifice (seulement la 2e étape du code).

Salut,

Principe générale des listes déroulantes

Bonjour,
J'ai regardé ce lien mais je ne vois pas la relation précise avec ce que j'énonce. En tout cas, je n'ai pas de problème avec ma liste déroulante.
C'est le résultat, c'est à dire le contrôle table qui ne se met pas à jour. Et chaque ligne du contrôle table correspond à 1 ligne de la requête sous-jacente, bien-sûr. Veux-tu dire qu'il faudrait modifier chaque colonne du contrôle table et les actualiser avec du code 1 par 1 ?

arverne73 a écrit : ↑06 août 2022 14:31 C'est le résultat, c'est à dire le contrôle table qui ne se met pas à jour.

Joins un ODB en utilisant le format natif intégré HSQLDB.
Ceci afin qu'on puisse tester et reproduire.
Et cela permettra aussi d'écarter un problème avec MySQL.

Galère, galère !
Transposer MySQL vers la base intégré : très laborieux, pour les tables, pour le code SQL, pour les fonctions CONCAT qui ne sont pas acceptés… Après des heures et des heures, j'y suis parvenu ! Je voulais exporter une partie réelle de la base avec sa complexité.
Pour info, désormais LO affiche un message d'alerte chaque fois que l'on utilise une base HSQLDB pour dire que ce système est obsolète et qu'il faut employer une base Firebird intégré.

Et donc, résultat : le problème est le même avec une base intégrée. Cf Lien (poids > 500 Ko donc lien externe)
J'ai mis 2 formulaires :

classique, c'est à dire celui où j'ai mis du code de "contournement" qui change la source du formulaire : fonctionne

sans contournement comme je l'ai indiqué dans son nom : ne se met pas à jour, sauf la première fois !

Bonsoir,

arverne73 a écrit : ↑08 août 2022 12:21 Pour info, désormais LO affiche un message d'alerte chaque fois que l'on utilise une base HSQLDB pour dire que ce système est obsolète et qu'il faut employer une base Firebird intégré.

Outils>Options>Avancé désactiver les fonctions expérimentales
Surtout ne pas utiliser Firebird (mal) intégré !! C'est encore pire.
Bonne journée,

Merci pour l'info sur Firebird. J'ai essayé la conversion : ce n'était pas mieux et les 2 se révèlent lentes, plus que MySQL sur une machine virtuelle. Firebird peut aussi être utilisé en base externe indépendante.

Je viens de regarder sommairement ton formulaire "Recherche Micromycètes sans contournement" et je vois que tu ne respectes pas le tutoriel.
Le contrôle table devrait être dans un sous-formulaire.

capture.png

J'ai mis le contrôle table dans un sous-formulaire, ce qui ne paraît pas changer la situation. Un nouveau fichier modifié pour le formulaire sans contournement. lien
A+

Si je tente de faire une sélection avec ta liste, j'ai une erreur dans la requête SQL :

capture.png

Curieux !
Je n'ai absolument pas cette erreur en sélectionnant exactement la même espèce…

Capture d’écran du 2022-08-21 15-39-39.png

J'avais compris que tu utilisais OpenOffice : une différence de comportement ? En tout cas, je remarque dans ta copie d'écran que la condition WHERE a un problème : il est écrit quelque chose comme CodEspM = 'acetosae', comme si c'est le champ nom de l'espèce qui est pris en compte (1er champ de la requête de la liste déroulante) et non pas le code de l'espère (correspondant au 2e champ de la liste déroulante).
Alors que la requête UNION enregistrée dans les requêtes donne bien, chez moi, comme condition WHERE CodEspM = 241 pour cette même espèce (2e copie d'écran).

Capture d’écran du 2022-08-21 15-58-00.png

Non, le message d'erreur indique clairement que la requête exécutée est mal formée.
Regarde la syntaxe, tu passes tes variables sans les encadrer par des apostrophes :

capture.png

Elles sont donc interprétées comme une opération mathématique de division avec des noms de colonnes introuvables.

J’explicite un peu mieux : effectivement dans ton message d’erreur, on voit que la condition WHERE indique comme critère la chaîne de texte de la liste déroulante (elle même composée avec un /). La requête en question est écrite dans le code et enregistrée en dur comme une des 2 requêtes de la section du même nom.
C’est cette même requête dont je faisais copie dans mon message précédent.
Et pour comprendre la différence entre ce qu’il se passe sur mon poste et sur le tien : la liste déroulante en haut est basée sur une requête comprenant 2 champs : 1 - un chaîne de texte avec une concaténation 2- un champ numérique correspondant au code de l’espèce micromycète dans la table du même nom.
Or, si je comprends bien, quand mon code récupère la valeur (currentvalue) de cette liste, chez moi, c’est ce 2e champ de la requête qui est récupéré (comme attendu) alors que chez toi, c’est le premier champ qui est récupéré ! Il y a donc un problème de compatibilité entre les versions. Je n’ai pas la base sous la main à l’instant, mais je me souviens que dans les paramètres de la liste déroulante, il est indiqué que le champ lié a l’index 1, le premier ayant l’index 0, si je ne me trompe pas.
En tout cas, je n’obtiens pas l’erreur que tu as et la requête sous-jacente s’écrit correctement chez moi, comme le montre ma copie d’écran.

Forum OpenOffice LibreOffice NeoOffice

[Résolu][Base] Absence d'actualisation formulaire form.reload

[Résolu][Base] Absence d'actualisation formulaire form.reload

Re: [Base] Absence d'actualisation formulaire form.reload

Re: [Base] Absence d'actualisation formulaire form.reload

Re: [Base] Absence d'actualisation formulaire form.reload

Re: [Base] Absence d'actualisation formulaire form.reload

Re: [Base] Absence d'actualisation formulaire form.reload

Re: [Base] Absence d'actualisation formulaire form.reload

Re: [Base] Absence d'actualisation formulaire form.reload

Re: [Base] Absence d'actualisation formulaire form.reload

Re: [Base] Absence d'actualisation formulaire form.reload

Re: [Base] Absence d'actualisation formulaire form.reload

Re: [Base] Absence d'actualisation formulaire form.reload

Re: [Base] Absence d'actualisation formulaire form.reload