[Résolu][Base] Listes liées multi filtres

[gaelviller]

Bonjour à tous,

Je tenais tout d'abord à remercier les responsables pour ce site et pour la mine d’or qu’il contient en terme de conseils, tutos, aides, etc. Merci aussi à vous tous, les contributeurs, qui l'alimentez par l'aide que vous apportez au fil du temps. Grâce à nombre d’entre vous, j’ai pu me lancer dans la mise en place de différents projets autour de moi. Débutant avec l’outils LibreOffice Base, je ne suis pas un habitué des bases de données (ni de SQL ou code de programmation basic).

Je mets en place une base de données pour une association qui collabore avec des [Structures] avec lesquelles elle réalise des [Captations]. Chaque [Année], des [Actions] sont mises en place avec chacune de ces [Structures] et des [Séries] de [Productions] découlent des [Captations].

Afin de faciliter la lisibilité et le suivi des actions menées, j’ai logiquement pensé à utiliser Base pour mettre en oeuvre tout cela avec les tables que vous devinez dans le paragraphe précédent.

Dans ma base de données, j’ai créé des formulaires pour aider les différents utilisateurs à y enregistrer l'ensemble des éléments. Le tout semble opérationnel. À l’usage, une partie me semble perfectible, mais cela dépasse mes connaissances. J’aimerais que dans mes formulaires, les zones de liste puissent être utilisées pour filtrer le contenu des suivantes. C'est le cas dans mon formulaire consacré aux productions "Form-Production". Afin qu'il soit un peu plus élaboré, j'ai commencé à y travailler.
Selon les relations de table, chaque production est liée à :
- une action,
- une série,
- une année,
- une structure
- une captation (également appelée par endroit "enregistrement", désolé pour cette erreur de débutant)

Grâce à votre site, j'ai pu mettre en oeuvre des listes déroulantes pour faciliter la démarche. Et, grâce au travail de Pierre-Yves Samyn ici, j’ai été en mesure de configurer, dans mon formulaire Form-Production, des listes liées à la table T_Structures, afin filtrer les autres listes déroulantes qui suivent. Cependant, j’aimerais ajouter un deuxième critère de filtrage lié, cette fois-ci, à la table T_Annees (à laquelle sont liées les actions, les séries, les captations et les productions, mais pas les structures).
En clair, dans l’exemple ci-dessous (cf PJ), je lance le formulaire MENU et je clique sur le bouton « Production » qui lance l’ouverture du formulaire Form-Production sur un nouvel enregistrement (merci à ceux qui m'ont aidé à programmer cela). Je remplis ou modifie les données d’une [Production], puis je choisis la [Structure] à laquelle elle est liée dans la liste déroulante. Alors, le filtrage s’effectue dans [Actions], [Séries] et [Captations] selon la structure choisie. Ensuite, je choisis l’[Année] qui concerne la production, et j’aimerais que cela puisse ajouter un filtre aux [Actions], [Séries] et [Captations] pour que n’apparaissent dans ces listes déroulantes que les ‘enregistrements de table’ qui concernent à la fois la structure et l'année choisies.

Comment me recommandez-vous procéder ? Est-il possible d’adapter le code de Pierre-Yves Samyn pour y parvenir ?

J’ai recherché sur différents supports, mais il ne me semble pas que cela ait été demandé. Évidemment, si le sujet a déjà été évoqué, et que j’ai manqué ça, merci de m’indiquer les mots-clés pour que je le retrouve.
(EDIT : Il y a bien cela, mais la 'solution' n'est pas apportée et je ne peux pas adapter cela à ma situation.)

Pour mieux comprendre, j’ai recréé une base de données (ci-dessous) utilisant les éléments mentionnés plus haut et qui peut servir à faire des tests.

J’ai essayé d’être aussi clair que possible et espère que vous comprendrez ma demande. J’espère pouvoir lire vos conseils et recommandations.

Merci d’avoir lu et bonne continuation à chacun.

DB_Test.odb

SOLUTION
Afin de faire gagner du temps aux autres utilisateurs qui chercheront des informations sur les listes déroulantes en cascade ou les listes liées, voici la solution apportée par Rafkus_pl, merci à lui !
En ajoutant à vos macros et en adaptant le code ci-après à votre table :

Code : Tout sélectionner

Sub Liaison_Structures_Annees 'd'après le code partagé ici : https://forum.openoffice.org/fr/forum/viewtopic.php?p=383695#p383695
 DIM oForms As Object
 DIM lst_SourceA As Object, lst_SourceB As Object
 DIM lst_DestA As Object, lst_DestB As Object, lst_DestC As Object
 DIM sFiltre As string
 
	oForms = ThisComponent.DrawPage.Forms.GetByName("MainForm")
	lst_SourceA = oForms.getByName("lstStructure")
	lst_SourceB = oForms.getByName("lstAnnee")	
	
	sFiltre = condition_listbox(lst_SourceA, "", """ID_Structure"" = ")
	sFiltre = condition_listbox(lst_SourceB, sFiltre, """ID_Annee"" = ")

	lst_DestA = oForms.getByName("lstAction")
	lst_DestA.ListSource() = array("SELECT ""NomAction"", ""ID"" FROM ""T_Actions"" " & sFiltre & " ORDER BY ""NomAction"" ASC")
	lst_DestA.Refresh
	
	lst_DestB = oForms.getByName("lstSerie")
	lst_DestB.ListSource() = array("SELECT ""NomSerie"", ""ID"" FROM ""T_Series"" " & sFiltre & " ORDER BY ""NomSerie"" ASC")
	lst_DestB.Refresh
	
	lst_DestC = oForms.getByName("lstCaptation")
	lst_DestC.ListSource() = array("SELECT ""NomCaptation"", ""ID"" FROM ""T_Enregistrements"" " & sFiltre & " ORDER BY ""NomCaptation"" ASC")
	lst_DestC.Refresh
	
End Sub

Function condition_listbox(oListBox as Object, sFiltr as string, sCondition as string)as string
dim var_Id as string
	if oListBox.SelectedItems(0) > 0 then		
		var_Id = oListBox.valueItemList(oListBox.SelectedItems(0))
		if sFiltr = "" then sFiltr = " WHERE " else sFiltr = sFiltr & " AND "
		condition_listbox = sFiltr & sCondition & Var_Id
	else
		condition_listbox = sFiltr
	end if
end Function

NB: Ce code contient une fonction qui peut être appelée par différentes macros qui en auraient besoin sans avoir besoin de saisir à nouveau la fonction.

Désignez ensuite cette macro dans votre formulaire aux fonctions ci-dessous :
- le formulaire lui-même : dans les "Propriétés du formulaire" -> choisir l'onglet "Événements" -> affectez la macro à l'événement "Après le changement d'enregistrement" ;
- la/les liste(s) "source" : en passant par exemple par le "Navigateur de formulaire" -> choisir la liste concernée -> clic-droit "Propriétés" -> dans les "Propriétés : Zone de liste" -> choisir l'onglet "Événements" -> affectez la macro à l'événement "Modifié(es)" (reproduire ces étapes pour toutes les listes sources concernées).

Ci-joint, une base dans laquelle le formulaire utilise le code donné plus haut avec deux listes "source" et trois listes "de destination" (qui seront impactées par les listes "source".

DB_Test_v7b.odb

En espérant que ça sera utile à d'autres !
À bientôt !

[Dude]

Salut,

Je te l'ai déjà dit : il faut penser à ceux qui tentent de t'aider.
Il faut donc fournir un exemple limité à la seule problématique.
A savoir un ODB avec un seul formulaire et uniquement les tables et les macros concernées.

ajouter un filtre aux [Actions], [Séries] et [Captations] pour que n’apparaissent dans ces listes déroulantes que les ‘enregistrements de table’ qui concernent à la fois la structure et l'année choisies

Déjà, arrives-tu à tes fins avec une requête SQL qui fait ce filtrage ?
Parce que je sens comme un problème de modèle relationnel.

[gaelviller]

Bonjour Dude,
Merci d'avoir pris le temps de te pencher sur ma question.
J'ai testé rapidement des requêtes en SQL, et elles semblent fonctionner...

Cependant, j'ai un peu avancé, de mon côté.

J'ai tordu le problème dans tous les sens et je pense approcher d'un résultat valable.

J'ai modifié différents aspects du code que j'avais trouvé ici pour y intégrer une deuxième liste de source (sur le même principe que j'avais ajouté des listes de destination). Ensuite, j'ai renomé la macro PysMajListeStructure en PysMajListes et l'ai adaptée de la façon indiquée dans le code ci-dessous. Ainsi, la macro consulte ainsi les deux listes déroulantes sources à la fois : lstStructure et lstAnnee. Ensuite, j'ai paramétré cette même macro comme événement 'Statut de l'élément modifié', pour les deux listes.
J'ai dû ajouter des lignes de code pour distinguer les deux variables de source et les incrémenter dans le mécanisme.
Ainsi, si je modifie l'une des deux listes déroulantes, la macro consulte le résultat des deux sources pour filtrer toutes les différentes destinations.

Voici donc le code modifié.

Code : Tout sélectionner

Option Explicit
' Détecter toute variable mal ou non déclarée

' Source : https://forum.openoffice.org/fr/forum/viewtopic.php?p=81396#p81396
' PysLstSourceN indiquent les zone de liste de Source qui servent de source, 
' PysLstDestinationN indiquent les zones de liste de Destination qui seront actualisées en conséquence
dim PysLstSource1 as Object, PysLstSource2 as Object
dim PysLstDestination1 AS Object, PysLstDestination2 AS Object, PysLstDestination3 AS Object


Sub PysOpenStruct(PysEvent)
	dim PysContainer  as object, PysConnection as object
	dim PysProp(1) as New com.sun.star.beans.PropertyValue 
		PysContainer =  PysEvent.Source.Model.Parent.ActiveConnection.Parent.DatabaseDocument.FormDocuments
		PysConnection = PysEvent.Source.Model.Parent.ActiveConnection
		PysProp(0).Name = "ActiveConnection"
		PysProp(0).Value = PysConnection
		PysProp(1).Name = "OpenMode"
		PysProp(1).Value = "open"
		' Form-Structure désigne le formulaire à ouvrir en vue d'ajouter/modifier des données
		PysContainer.loadComponentFromURL("Form-Structure","_blank",0,PysProp())
end sub

sub PysRefreshStructure
	' adapter les variables ci-après selon ce qui se trouve dans le Navigateur de formulaire
	' lstStructure désigne la zone de liste source du formulaire
	ThisComponent.DrawPage.Forms.getByName("MainForm").getByName("lstStructure").refresh
end sub

'************************************************************************************************
sub PysMajListes
'************************************************************************************************
'Lancée sur modification des deux listes de Sources pour mettre à jour les différentes listes de Destination
'************************************************************************************************
	' var_id_Source1 est la variable liée à la clé primaire id_Source1 de la table de source ici liée à la liste déroulante lstStructure
	' var_id_Source2 est la variable liée à la clé primaire id_Source2 de la table de source ici liée à la liste déroulante lstAnnee
	DIM var_id_Source1 as integer
	DIM var_id_Source2 as integer
	'Recupere les composants liste
		PysLstSource1 = ThisComponent.DrawPage.Forms.getByName("MainForm").getByName("lstStructure")
		PysLstSource2 = ThisComponent.DrawPage.Forms.getByName("MainForm").getByName("lstAnnee")
		PysLstDestination1 = ThisComponent.DrawPage.Forms.getByName("MainForm").getByName("lstAction")
		PysLstDestination2 = ThisComponent.DrawPage.Forms.getByName("MainForm").getByName("lstSerie")
		PysLstDestination3 = ThisComponent.DrawPage.Forms.getByName("MainForm").getByName("lstCaptation")
		'Recupere les id des Sources selectionnées
		'Syntaxe si le champ n'est pas lié à un champ de la base
		'var_id_Source = PysLstSource1.SelectedItems(0) 
		'var_id_Source = PysLstSource2.SelectedItems(0)
		'Syntaxe si le champ est lié à un champ de la base
		var_id_Source1 = PysLstSource1.valueItemList(PysLstSource1.SelectedItems(0))
		var_id_Source2 = PysLstSource2.valueItemList(PysLstSource2.SelectedItems(0))
		'Modifie la requête SQL des listes de Destination : 
		' [NomAction] désigne le champ qui sera ‘rafraichi’ et affiché ; [ID] désignant la clé primaire ; [T_Actions] indique la table liée à la liste de Destination
		' [ID_Structure] et [ID_Annee] désignent les champs liés par relations de table ; enfin on trie les listes [NomAction] dans l'ordre croissant
		PysLstDestination1.ListSource() = array("SELECT NomAction, ID FROM T_Actions WHERE ID_Structure =" & var_id_Source1 & "AND  ID_Annee =" & var_id_Source2 & " ORDER BY NomAction ASC")
		PysLstDestination1.refresh 
		' [NomSerie] désigne le champ qui sera ‘rafraichi’ et affiché ; [ID] désignant la clé primaire ; [T_Series] indique la table liée à la liste de Destination
		' [ID_Structure] et [ID_Annee] désignent les champs liés par relations de table ; enfin on trie les listes [NomSerie] dans l'ordre croissant
		PysLstDestination2.ListSource() = array("SELECT NomSerie, ID FROM T_Series WHERE ID_Structure =" & var_id_Source1 & "AND  ID_Annee =" & var_id_Source2 & " ORDER BY NomSerie ASC")
		PysLstDestination2.refresh 
		' [NomCaptation] désigne le champ qui sera ‘rafraichi’ et affiché ; [ID] désignant la clé primaire ; [T_Enregistrements] indique la table liée à la liste de Destination
		' [ID_Structure] et [ID_Annee] désignent les champs liés par relations de table ; enfin on trie les listes [NomCaptation] dans l'ordre croissant
		PysLstDestination3.ListSource() = array("SELECT NomCaptation, ID FROM T_Enregistrements WHERE ID_Structure =" & var_id_Source1 & "AND  ID_Annee =" & var_id_Source2 & " ORDER BY NomCaptation ASC")
		PysLstDestination3.refresh 
end sub

'************************************************************************************************
sub PysActualisation
'************************************************************************************************
'Lancée après changement d'enregistrement pour sélectionner dans la liste la valeur contenue
'dans le champ
'************************************************************************************************
dim ExoTrav1
	PysMajListeStructure  
	ExoTrav1= ExoRechercheDansTableau1(PysLstDestination1.ValueItemList, PysLstDestination1.boundField.Value)
	if ExoTrav1 <> "#N/A" then
		PysLstDestination1.SelectedItems = array(ExoTrav1)
	else
		PysLstDestination1.SelectedItems = array(0)
end if
dim ExoTrav2
	PysMajListeStructure  
	ExoTrav2= ExoRechercheDansTableau2(PysLstDestination2.ValueItemList, PysLstDestination2.boundField.Value)
	if ExoTrav2 <> "#N/A" then
		PysLstDestination2.SelectedItems = array(ExoTrav2)
	else
		PysLstDestination2.SelectedItems = array(0)
end if
dim ExoTrav3
	PysMajListeStructure  
	ExoTrav3= ExoRechercheDansTableau3(PysLstDestination3.ValueItemList, PysLstDestination3.boundField.Value)
	if ExoTrav3 <> "#N/A" then
		PysLstDestination3.SelectedItems = array(ExoTrav3)
	else
		PysLstDestination3.SelectedItems = array(0)
end if
end sub

'******************************************************************************************************
Function ExoRechercheDansTableau1(ExoTablo1, ExoRech1)
'******************************************************************************************************
dim i as integer
	ExoRechercheDansTableau1 = "#N/A"
	for i = lbound(ExoTablo1) to ubound(ExoTablo1)
	if ExoTablo1(i)= ExoRech1 then
		ExoRechercheDansTableau1 = i
	exit for
	end if
next i

end function

'******************************************************************************************************
Function ExoRechercheDansTableau2(ExoTablo2, ExoRech2)
'******************************************************************************************************
dim j as integer
	ExoRechercheDansTableau2 = "#N/A"
	for j = lbound(ExoTablo2) to ubound(ExoTablo2)
	if ExoTablo2(j)= ExoRech2 then
		ExoRechercheDansTableau2 = j
	exit for
	end if
next j

end function

'******************************************************************************************************
Function ExoRechercheDansTableau3(ExoTablo3, ExoRech3)
'******************************************************************************************************
dim k as integer
	ExoRechercheDansTableau3 = "#N/A"
	for k = lbound(ExoTablo3) to ubound(ExoTablo3)
	if ExoTablo3(k)= ExoRech3 then
		ExoRechercheDansTableau3 = k
	exit for
	end if
next k

end function

ça semble fonctionner ainsi , mais, comme je code au petit bonheur la chance, je ne suis pas certain du code que j'ai écrit... Si vous avez une idée de ce qui peut/doit être optimisé, je suis preneur.

Je remets aussi la base actualisée (après plusieurs tests) désolé, jai laissé les formulaires et les tables et les macros en cours de test.

DB_Testv2.odb

[gaelviller]

Bon, alors, ça n'est pas encore ça... Le code indiqué plus haut est valable pour la création (voire la modification) d'un enregistrement dans la table. Cependant, si on circule dans les enregistrements de la table, le fait de changer d'enregistrement fait disparaître le "contenu" des listes de destination dès lors que les valeurs sources ne sont pas les même entre les deux enregistrements... Alors que sur la table les champs contiennent bien les valeurs saisies...
Là, je sèche un peu... Que faire ?
Faudrait-il préciser dans la macro que l'actualisation des données n'est à faire que lorsqu'on effectue une modification de la valeur dans la table (par la sélection dans la liste déroulante) ? Et si oui, comment procéder ?
De toute façon, je n'étais déjà pas certain du code... Donc il y a très certainement des erreurs !

[Dolev]

Bonjour,

Perso, je ne suis pas fan des encapsulations de propriétés tels que :

Code : Tout sélectionner

PysContainer =  PysEvent.Source.Model.Parent.ActiveConnection.Parent.DatabaseDocument.FormDocuments
PysConnection = PysEvent.Source.Model.Parent.ActiveConnection

Il serait plus fluide de faire :

Code : Tout sélectionner

PysConnection = PysEvent.Source.Model.Parent.ActiveConnection
PysContainer =  PysConnection.Parent.DatabaseDocument.FormDocuments

J'ai testé rapidement des requêtes en SQL, et elles semblent fonctionner...

Il n'y a pas de requêtes dans le dernier ODB proposé.
Comme le dit Dude, joindre un fichier plus simple facilite l'aide qu'on peut apporter ici.

[gaelviller]

Bonjour,

Perso, je ne suis pas fan des encapsulations de propriétés tels que :

Code : Tout sélectionner

PysContainer =  PysEvent.Source.Model.Parent.ActiveConnection.Parent.DatabaseDocument.FormDocuments
PysConnection = PysEvent.Source.Model.Parent.ActiveConnection

Il serait plus fluide de faire :

Code : Tout sélectionner

PysConnection = PysEvent.Source.Model.Parent.ActiveConnection
PysContainer =  PysConnection.Parent.DatabaseDocument.FormDocuments

Bonjour,
Merci d'avoir étudié mon cas.
Et merci pour ces conseils.
N'étant pas habitué aux macros, je n'ai fait que reprendre un code partagé (comme dit plus haut) dont j'ai adapté les variables et que j'ai essayé, avec ma petite compréhension, de modifier pour permettre que plusieurs listes déroulantes puissent être la source filtrante d'autres listes déroulantes.
Je vais tenter de mettre cette proposition en place pour partager quelque chose de plus "clair".

J'ai testé rapidement des requêtes en SQL, et elles semblent fonctionner...

Il n'y a pas de requêtes dans le dernier ODB proposé.
Comme le dit Dude, joindre un fichier plus simple facilite l'aide qu'on peut apporter ici.

Oui, désolé, je pensais qu'il fallait juste que j'essaie de vérifier si les requêtes que je sollicitais dans la macro fonctionneraient en SQL... Je tâcherai de les mettre, mais je ne suis pas très familier des requêtes non plus (je débute à peine !). Cependant, je prends tous les bons conseils que vous auriez à me partager.
Bref, je teste tout ça et je reviens avec un ODB contenant le code simplifié comme proposé et les (essais de) requêtes.

[EDIT] Voici le fichier ODB réactualisé. J'ai fais les corrections sur le code des macros. Et j'ai mis quelques requêtes en place que j'ai testées (inspirées des codes inscrits dans les macros). Je ne sais pas si c'est ce que vous souhaitiez voir.

DB_Test.odb

Par ailleurs, j'avais testé (via le formulaire Form-Production) la modification des 94 premiers enregistrements (avec le codage précédent) et ça fonctionnait plutôt bien, sauf lorsque, après avoir changé d'année, je termine la sélection dans les différentes listes déroulantes, puis (après sauvegarde), je reviens (toujours dans le formulaire Form-Production), sur les enregistrements concernant une autre année (enregistrement 91 ou précédents), les données des listes déroulantes "captation", "Action" et "Série" ont disparu alors qu'elles sont bien présentes dans la table T_Productions.

[Dolev]

Re,

Le fichier est toujours trop compliqué à étudier (trop de formulaires, de macros).
Merci de vous mettre à notre place.

[gaelviller]

Re,
Je comprends bien... Pour les macros, les modèles List_Prod_Action et List_Production sont nécessaires (actuellement) pour mettre en oeuvre les listes déroulantes liées/en cascade. Je n'ai fait que copier le code proposé sur ce post du site pour l'adapter à mes besoins. J'ai bien conscience qu'il doit y avoir du code qui n'est pas utile, mais je ne m'y connais pas suffisamment pour le faire (ça fait aussi partie de ma demande d'aide, d'ailleurs).
Donc, pour continuer dans une démarche positive, voici une autre version du fichier ODB, allégé de certaines macros et de formulaires.

DB_Testv4.odb

Si d'autres choses semblent superflues, merci de me les indiquer pour que je les retire.

[jeanmimi]

Bonjour,
Lorsque je regarde le modèle

Selon les relations de table, chaque production est liée à :
- une action,
- une série,
- une année,
- une structure
- une captation

le principal me semble être la production, dont il vaut mieux mettre la date de la commande que l'année, puisqu'une requête pourra extraire l'année.
Cette production entrainera plusieurs actions, et elles-mêmes plusieurs captations ou enregistrements. Si j'ai bien compris cette structure, il y aura des Tables en relation 1 à 1 et d'autres 1 à n.

[gaelviller]

Bonjour,
Merci encore de m'apporter des conseils.
En fait, la "production" est la finalité qui servira aux rapports. L'association collabore avec des structures avec lesquelles elle met chaque année en place une action (cette action devant faire l'objet d'un bilan, etc.).
Chaque action peut donner lieu à la mise en place d'une ou plusieurs séries répartie(s) sur l'année.
Tout au long de l'année, l'association réalise donc un certain nombre de captations (pour plus de lisibilité, je préfère garder ce terme même si l'autre traine encore dans l'écriture et le codage de ma base...).
Ces captations servant à produire des productions qui seront partagées et serviront à réaliser le bilan de l'activité annuelle de l'association.

Pour les relations de table (certaines existantes dans le fichier ODB actuel seront sans doute retirées si elles sont redondantes ou impertinentes) :
- une structure n'est pas liée au temps (l'association peut collaborer avec elle un an, comme elle peut le faire durant plus de dix ans) ;
- l'action est le nom donné à cette collaboration annuelle (ce peut être un partenariat, une convention, ou une simple collaboration) et on en fait un bilan pour la structure chaque année où une collaboration a lieu afin de valoriser ce qu'a mis en oeuvre l'association (elle est donc liée à la structure et à l'année) ;
- la série (ou les séries) est le contenu de la collaboration, elle peut être formalisée dans le partenariat ou la convention, ou alors elle peut se construire tout au long de l'année sans avoir été programmée au préalable (elle peut ne pas être liée à l'année, mais reste liée à l'action) ;
- la captation est l'un des moments durant lesquels la structure et l'association collaborent, l'association se met alors "au service" de la structure pour l'accompagner, il y a donc plusieurs captations durant l'année (elle a lieu a une date précise et peut être liée à une action ou plus spécifiquement à une série, mais est liée à l'année [qui peut être tirée de la date, mais je ne sais pas encore gérer cet aspect-là!]) ;
- la production est le "produit fini" que l'association produit et partage (chaque semaine, chaque mois ou de façon plus ponctuelle) tant avec la structure que sur ses propres supports, il est fait un bilan du nombre de production de chaque structure, chaque année (elle est liée à la captation dont elle provient et à la série liée à l'action, la lier à l'année m'a surtout aidé pour la préparation des requêtes et en vue des rapports).
C'est le bilan de tout cela qui est nécessaire à l'association pour continuer de jouer son rôle chaque année.

J'espère que cela éclairera sur l'objectif à atteindre. C'est de l'objectif que je suis parti sur les conseils d'un pro qui m'a aidé à analyser les données dont j'avais besoin et dans les grandes lignes, les tables nécessaires et les principales relations. L'ODB partagé n'est qu'une partie de ce projet sur lequel je teste des fonctions que je souhaiterais intégrer. La base principale est en test d'intégration de données courantes actuellement et elle se remplit progressivement par les membres de l'association. Cela me permettra de savoir :
- si elle est opérationnelle pour faire un suivi des actions en cours (et donc de l'améliorer et d'y intégrer de nouvelles fonctionnalités souhaitées par l'équipe),
- si elle est assez complète pour contenir l'ensemble des données nécessaires, chaque année, aux différents bilans.

Je n'en suis donc qu'au début de la mise en oeuvre de ce système de gestion de base de données et je ne sais pas encore jusqu'où cela va me mener, même si je sais ce qui doit ressortir. C'est pourquoi, cet outil me semble correspondre aux besoins de l'association, et j'avance dans sa mise en oeuvre en venant chercher des idées et des conseils ici, même si je cherche aussi sur le reste du net.

[jeanmimi]

Si j'ai bien compris l'articulation que tu décris, les Relations entre les Tables ont ce schéma :

Relations entre Tables.png

Dans ce cas, il y a des champs d'enregistrement dans les Tables qui deviennent inutiles puisque dans la requête, ils seront liés, par exemple le champ ID_Structure que tu répètes dans chaque Table.
Quant à l'Année, elle s'extrait dans la requête à partir d'une date. Donc, tu peux remplacer tes ID_Année par une date de début de l'action ou du début de l'enregistrement (ou captation).

[gaelviller]

Bonjour,
Merci jeanmimi ! Je vais regarder ta proposition.
En revanche, sur le modèle partagé, je ne vois pas de listes déroulantes. Est-ce que ta proposition est justement d'essayer de contourner le problème en ayant des relations de table "simplifiées" ?
Je pose la question car la base partagée ici est une version allégée de la base complète (tant en terme de tables que de champs et relation).

[jeanmimi]

Est-ce que ta proposition est justement d'essayer de contourner le problème en ayant des relations de table "simplifiées" ?

Oui, c'est le résultat attendu dans le formulaire proposé dans l'exemple.

[gaelviller]

Bonjour,
Merci jeanmimi
Avec cette formule, il est possible de voir, pour une structure indiquée dans le "champ", les actions qui existent, les séries qui en découlent, etc. Ce qui est plus simple pour la préparation des bilans.
Cependant, comment mettre en oeuvre un formulaire pour créer une production (ajouter à la table de la base de données) et choisir la captation d'où elle provient, sans avoir à choisir parmi les nombreuses captations ? Je trouvais intéressant/important aussi de pouvoir "filtrer" les éléments auxquels la production était liée.
Si je reprends ta proposition, il ne reste que les captations qui soient liées par relation de table aux productions. Donc côté filtrage, ça me semble un peu limité comme possibilité, non ? Je veux dire qu'au moment de choisir la captation à laquelle est liée la production, il faudra choisir parmi la liste complète de l'ensemble des captations (sans pouvoir filtrer les captations par un/plusieurs critère(s) complémentaire(s)... [Année, structure, etc.] Comment faire, dès lors ?

[jeanmimi]

comment mettre en oeuvre un formulaire pour créer une production

En ajoutant un autre sous-formulaire pour afficher la Table T_Productions, selon cette relation si j'ai bien compris.

Relation entre Tables avec T_Production.png

Si ça te convient, peux-tu expliquer comment tu chiffres ton devis ?

pouvoir "filtrer" les éléments auxquels la production était liée

Ce que tu appelles filtrer se fait dans une requête, soit par l'instruction simple ?, soit par une Macro qui va mettre à jour une requête pour le seul enregistrement affiché.
Tu peux regarder le résultat de la requête dans cette version.

[gaelviller]

Salut,
Merci pour tes lumières. Je pense que je comprends un peu mieux le principe, mais je ne sais pas trop comment le mettre à exécution. Voici ma problématique : admettons que je veuille ajouter une production. Outre l'ID (qui s'ajoute automatiquement) et le nom de la production (qui est défini par ailleurs), c'est pour retrouver l'enregistrement que je ne sais pas comment faciliter les choses. J'avais pensé mettre des éléments qui permettrait de filtrer (par des listes déroulantes) les résultats proposés par la base, comme, selon moi, la structure et l'année : cela réduirait le nombre d'actions et de série, et donc de captations dans les choix qui se présenteraient devant moi. Ensuite, il serait possible de choisir une action (ce qui réduirait le nombre de séries) et après, il pourrait aussi être possible de limiter encore le choix en spécifiant la série (il ne resterait alors que les captations concernées). C'est pourquoi j'avais pensé à des listes liées (ou en cascade, il me semble avoir lu ça également), ça me semblait être un bon choix pour l'expérience des utilisateurs finaux. Mais je fais peut-être fausse piste ? (auquel cas, je pourrais ouvrir un autre fil dans la partie Base, si les macros sont moins concernées)

Si je pense à ça, c'est parce qu'avec le très grand nombre de productions à saisir chaque année et le grand nombre de captations, le tout saisi localement par des personnes différentes, il devient vite compliqué de chercher à filtrer en entrant un ID (qu'on oublie vite) ou le nom exact de la captation... D'autant plus que les membres de l'association n'ont pas forcément la "fibre informatique", voire même la "fibre concernant les bases de données" (moi-même n'étant pas un bon connaisseur dans le domaine).

Pour ce qui est de l'image des relations de tables que tu as partagée, elle est globalement bonne (exception faite de la table T_Annees dont la relation doit se faire avec la table T_Actions plutôt que T_Series).

Concernant les sous-formulaires, je n'ai pas encore bien compris comment les exploiter au mieux et comment ils interagissent les un avec les autres... J'essaie de décrypter les bases que tu m'as transmises pour mieux comprendre. Mais il me semble évident que la solution la plus simple consiste à passer par là (ça limitera d'autant l'utilisation de macros, on est d'accord ?).

Je pense avoir également compris ce que tu propose avec le formulaire : il est possible de créer des structures, des actions, des séries, des enregistrements et des productions directement dedans. Ce formulaire devient une sorte de plaque tournante. L'idée est intéressante. Mais je trouve assez complexe de devoir indiquer les ID des relations de table dans celles qui sont concernées (après je me trompe sans doute, mais je ne vois pas trop comment faire autrement !)

Par ailleurs, dans ma base finale, j'ai plus de champs à saisir dans l'ensemble de ces tables (indiquer des infos pour la structures qui seront nécessaires pour le bilan, de même pour les actions, les séries et les captations...) et j'ai encore d'autres tables liées (une pour intégrer les coordonnées des intervenants de chaque structure, une autre concernant les type d'actions qui existent, une autre encore pour les type de série, etc.). Cela risque de prendre beaucoup de place sur un seul formulaire. C'est pourquoi j'avais 'segmenté' l'ajout de données de façon à avoir un formulaire pour chaque table. Chacun étant "appelé" depuis un formulaire de départ nommé "MENU".

Alors j'ai bien conscience que ça donne l'impression d'en demander beaucoup d'un coup, mais ce que je voulais surtout, au départ, c'était de créer des listes déroulantes filtrantes les unes avec les autres tout en les liant (grâce aux relations de table, forcément) et en faisant usage des sous-formulaires si cela était nécessaire ainsi qu'avec des requêtes (mais je ne sais pas comment faire des requête qu'on peut mettre à jour avec une Macro, il faudra que je fouille ça également !)

[Oups, désolé pour le pavé ! ]

[jeanmimi]

C'est pourquoi j'avais 'segmenté' l'ajout de données de façon à avoir un formulaire pour chaque table. Chacun étant "appelé" depuis un formulaire de départ nommé "MENU".

Tu as raison, il est possible depuis un formulaire de lancer l'ouverture, par Macro, d'un autre formulaire pour saisir ou choisir des données complémentaires.

Base Gestion participants course.odb

Il est possible aussi de saisir quelques lettres d'une donnée et d'avoir l'affichage de la totalité.

Sélection d'enregistrement par saisie de lettres.odb

En regardant les Tables, j'avais l'impression que la variété des captations est relativement limitée, ce qui fait que c'est toujours à peu près les mêmes qui reviennent dans les séries.

[gaelviller]

En regardant les Tables, j'avais l'impression que la variété des captations est relativement limitée, ce qui fait que c'est toujours à peu près les mêmes qui reviennent dans les séries.

Je comprends bien que ça soit ce qui ressorte. Cependant dans l'exemple, je n'ai pas utilisé les données réelles de ma base, j'ai "anonymisé" à ma façon les informations privées. Du coup, j'ai pensé que ce serait plus clair si je choisissais une nomenclature commune pour m'assurer que tout est bien paramétré et que tout fonctionne. Afin de "filtrer" les données des captations, je pensais que le mieux était de faire des listes liées filtrantes. Mais en faisant cela, j'ai "alourdi la base". Cependant cette fonctionnalité (les listes liées filtrantes ou listes en cascade) me semble utile dans de nombreux cas que d'autres pourraient avoir. C'est pourquoi je voudrais tout de même creuser cela pour que ça soit opérationnel.
Dans mon dernier projet, ça fonctionne : cependant, le formulaire de saisie ne peut pas servir de formulaire de consultation (sans modification), car si, lors du passage d'un enregistrement à l'autre, la valeur d'une des listes source change (pas la même année ou structure différente), dès lors, les données (pourtant enregistrée dans la table n'apparaisse plus.
Je me dis qu'il faudrait sans doute adapter le code de la macro pour que celle-ci n'agisse que si l'utilisateur fais une modification de la valeur, mais pas parce qu'il est simplement passé d'un enregistrement à un autre. Mais je ne sais pas comment faire (si toutefois c'est possible de faire comme cela). Ou alors il faut procéder différemment, mais je ne vois pas comment ? Faudrait-il dire à la macro qu'elle ne s'active que si valeurs des les listes cibles sont "vide" ? Et si oui, comment procéder ? "IF", "THEN" et "ELSE" ? autre chose ?

[gaelviller]

Bonjour,
Grâce au code simplifié proposé par Rafkus_pl sur ce fil, j'ai corrigé le code de ma base qui semble toujours opérationnel. (cf fichier ci-dessous)

DB_Test_v7.odb

ça a grandement simplifié le codage des macros car les précédents étaient assez cryptiques pour moi...

Cependant, le problème précédent persiste :

le formulaire de saisie ne peut pas servir de formulaire de consultation (sans modification), car si, lors du passage d'un enregistrement à l'autre, la valeur d'une des listes source change (pas la même année ou structure différente), dès lors, les données (pourtant enregistrées dans la table n'apparaissent plus.

Je sèche complètement sur ce point qui me semble important. Car même si cela n'empêche pas d'utiliser la table, à terme, ça va amener les utilisateurs à commettre des erreurs en pensant que les données qu'ils ont insérées n'ont pas été enregistrées dans la base.
Comment y remédier ?

[Rafkus_pl]

Avez-vous remarqué cette phrase :

J'ai attribué la macro ci-dessus à deux événements : Modifié (valeur du champ) et Quand l'enregistrement a été modifié.

Zrzut ekranu 2024-06-11 154936.png

Vous avez affecté la macro uniquement à la zone de liste, vous devez également l'affecter au "formulaire entier".
Lancer le navigateur de formulaire
Appelez la propriété "MainForm"
Sous l'onglet Événements, attribuez une macro à une action : Lorsqu'un enregistrement change...
C'était ça?
J'écris avec GOOGLE TRANSLATORE...

[gaelviller]

Avez-vous remarqué cette phrase :

J'ai attribué la macro ci-dessus à deux événements : Modifié (valeur du champ) et Quand l'enregistrement a été modifié.

Vous avez affecté la macro uniquement à la zone de liste, vous devez également l'affecter au "formulaire entier".
Lancer le navigateur de formulaire
Appelez la propriété "MainForm"
Sous l'onglet Événements, attribuez une macro à une action : Lorsqu'un enregistrement change...
C'était ça?
J'écris avec GOOGLE TRANSLATORE...

Bonjour,
Merci pour votre réponse (Google a fait son travail de traduction). J'essaie ça ! (même si ça fonctionnait déjà sans cela)
En revanche, je ne sais pas si le code que j'ai utilisé pour ma macro est bon. Je souhaite avoir deux listes "sources" qui filtrent d'autres listes "de destination". Du coup, j'ai adapté le code comme cela :

Code : Tout sélectionner

Sub Liaison_Structures_Annees 'd'après le code partagé ici : https://forum.openoffice.org/fr/forum/viewtopic.php?p=383695#p383695
 DIM sFiltreA As string,  sFiltreB As string
 DIM oForms As Object
 DIM lst_SourceA As Object, lst_SourceB As Object
 DIM lst_DestA As Object, lst_DestB As Object, lst_DestC As Object
 DIM Var_Id_SrcA As Integer, Var_Id_SrcB As Integer

	sFiltreA = ""
	sFiltreB = ""
	oForms = ThisComponent.DrawPage.Forms.GetByName("MainForm")
	lst_SourceA = oForms.getByName("lstStructure")
	lst_SourceB = oForms.getByName("lstAnnee")
	
	if lst_SourceA.SelectedItems(0) > 0 then	
		var_Id_SrcA = lst_SourceA.valueItemList(lst_SourceA.SelectedItems(0))	
		sFiltreA = " WHERE ""ID_Structure"" = " & Var_Id_SrcA
	end if
	if lst_SourceB.SelectedItems(0) > 0 then	
		var_Id_SrcB = lst_SourceB.valueItemList(lst_SourceB.SelectedItems(0))	
		sFiltreB = " AND ""ID_Annee"" = " & Var_Id_SrcB
	end if

	lst_DestA = oForms.getByName("lstAction")
	lst_DestA.ListSource() = array("SELECT ""NomAction"", ""ID"" FROM ""T_Actions"" " & sFiltreA & sFiltreB & " ORDER BY ""NomAction"" ASC")
	lst_DestA.Refresh
	
	lst_DestB = oForms.getByName("lstSerie")
	lst_DestB.ListSource() = array("SELECT ""NomSerie"", ""ID"" FROM ""T_Series"" " & sFiltreA & sFiltreB & " ORDER BY ""NomSerie"" ASC")
	lst_DestB.Refresh
	
	lst_DestC = oForms.getByName("lstCaptation")
	lst_DestC.ListSource() = array("SELECT ""NomCaptation"", ""ID"" FROM ""T_Enregistrements"" " & sFiltreA & sFiltreB & " ORDER BY ""NomCaptation"" ASC")
	lst_DestC.Refresh
	
End Sub

Car il m'indique des messages d'erreur sur la fonction "AND" utilisée pour la commande SQL... Je ne sais pas si vous avez aussi ce problème ?

[EDIT] Pour la traduction, je vous recommande : Deepl , la version gratuite fait un très bon travail.

[Rafkus_pl]

Je suppose que vous avez laissé le champ "lstStructure" vide et donc à la place de l'expression sql sous la forme :

Code : Tout sélectionner

SELECT...WHERE...AND...ORDER BY... 

vous avez reçu :

Code : Tout sélectionner

 SELECT...AND... ORDER BY....

Et c'est mauvais.

[gaelviller]

Ok, merci, je vais regarder cela !

[jeanmimi]

Comment y remédier ?

L'affichage des enregistrements effectués se fait dans une Requête. Le résultat de cette requête peut être visualisé dans un formulaire.
Je ne comprends pas à nouveau cette redondance de champs Année et Structure dans les différentes Tables.

[Rafkus_pl]

Eh bien, passons maintenant à une auto-école légèrement supérieure...
Extrayez une partie du code dans une fonction distincte qui peut choisir d'utiliser la commande WHERE ou AND.

Code : Tout sélectionner

Sub Liaison_Structures_Annees 'd'après le code partagé ici : https://forum.openoffice.org/fr/forum/viewtopic.php?p=383695#p383695
 DIM oForms As Object
 DIM lst_SourceA As Object, lst_SourceB As Object
 DIM lst_DestA As Object, lst_DestB As Object, lst_DestC As Object
 DIM sFiltre As string
 
	oForms = ThisComponent.DrawPage.Forms.GetByName("MainForm")
	lst_SourceA = oForms.getByName("lstStructure")
	lst_SourceB = oForms.getByName("lstAnnee")	
	
	sFiltre = condition_listbox(lst_SourceA, "", """ID_Structure"" = ")
	sFiltre = condition_listbox(lst_SourceB, sFiltre, """ID_Annee"" = ")

	lst_DestA = oForms.getByName("lstAction")
	lst_DestA.ListSource() = array("SELECT ""NomAction"", ""ID"" FROM ""T_Actions"" " & sFiltre & " ORDER BY ""NomAction"" ASC")
	lst_DestA.Refresh
	
	lst_DestB = oForms.getByName("lstSerie")
	lst_DestB.ListSource() = array("SELECT ""NomSerie"", ""ID"" FROM ""T_Series"" " & sFiltre & " ORDER BY ""NomSerie"" ASC")
	lst_DestB.Refresh
	
	lst_DestC = oForms.getByName("lstCaptation")
	lst_DestC.ListSource() = array("SELECT ""NomCaptation"", ""ID"" FROM ""T_Enregistrements"" " & sFiltre & " ORDER BY ""NomCaptation"" ASC")
	lst_DestC.Refresh
	
End Sub

Function condition_listbox(oListBox as Object, sFiltr as string, sCondition as string)as string
dim var_Id as string
	if oListBox.SelectedItems(0) > 0 then		
		var_Id = oListBox.valueItemList(oListBox.SelectedItems(0))
		if sFiltr = "" then sFiltr = " WHERE " else sFiltr = sFiltr & " AND "
		condition_listbox = sFiltr & sCondition & Var_Id
	else
		condition_listbox = sFiltr
	end if
end Function

[gaelviller]

Je ne comprends pas à nouveau cette redondance de champs Année et Structure dans les différentes Tables.

C'est parce que j'ai d'autres formulaires dans ma base "complète" (on m'a demandé de simplifier, j'ai simplifié) et, par exemple, dans celui dans lequel on ajoute des séries, le fait d'avoir le champ année, cela permet de filtrer parmi toutes les actions existantes, celles qui sont liées à cette année-là.
Je comprends bien qu'avec une base ainsi tronquée, il y ait plein de questions sans réponses ! J'espère avoir apporté une explication satisfaisante...

Eh bien, passons maintenant à une auto-école légèrement supérieure...
Extrayez une partie du code dans une fonction distincte qui peut choisir d'utiliser la commande WHERE ou AND.

Code : Tout sélectionner

Sub Liaison_Structures_Annees 'd'après le code partagé ici : https://forum.openoffice.org/fr/forum/viewtopic.php?p=383695#p383695
 DIM oForms As Object
 DIM lst_SourceA As Object, lst_SourceB As Object
 DIM lst_DestA As Object, lst_DestB As Object, lst_DestC As Object
 DIM sFiltre As string
 
	oForms = ThisComponent.DrawPage.Forms.GetByName("MainForm")
	lst_SourceA = oForms.getByName("lstStructure")
	lst_SourceB = oForms.getByName("lstAnnee")	
	
	sFiltre = condition_listbox(lst_SourceA, "", """ID_Structure"" = ")
	sFiltre = condition_listbox(lst_SourceB, sFiltre, """ID_Annee"" = ")

	lst_DestA = oForms.getByName("lstAction")
	lst_DestA.ListSource() = array("SELECT ""NomAction"", ""ID"" FROM ""T_Actions"" " & sFiltre & " ORDER BY ""NomAction"" ASC")
	lst_DestA.Refresh
	
	lst_DestB = oForms.getByName("lstSerie")
	lst_DestB.ListSource() = array("SELECT ""NomSerie"", ""ID"" FROM ""T_Series"" " & sFiltre & " ORDER BY ""NomSerie"" ASC")
	lst_DestB.Refresh
	
	lst_DestC = oForms.getByName("lstCaptation")
	lst_DestC.ListSource() = array("SELECT ""NomCaptation"", ""ID"" FROM ""T_Enregistrements"" " & sFiltre & " ORDER BY ""NomCaptation"" ASC")
	lst_DestC.Refresh
	
End Sub

Function condition_listbox(oListBox as Object, sFiltr as string, sCondition as string)as string
dim var_Id as string
	if oListBox.SelectedItems(0) > 0 then		
		var_Id = oListBox.valueItemList(oListBox.SelectedItems(0))
		if sFiltr = "" then sFiltr = " WHERE " else sFiltr = sFiltr & " AND "
		condition_listbox = sFiltr & sCondition & Var_Id
	else
		condition_listbox = sFiltr
	end if
end Function

Et bien voilà quelque chose que je ne sais pas du tout faire. Alors un grand MERCI ! pour ton aide. Le "bug" lié au "AND" est résolu.
Si je n'ai pas compris l'entièreté du code, j'en ai compris le principe de base. J'espère être capable de l'appliquer à d'autres situations de ma base, à l'avenir !

Reste plus qu'à résoudre ce problème d'affichage quand on change d'enregistrement et qu'il y a une variation d'une des valeurs source entre les deux enregistrements de la table...

[Rafkus_pl]

Reste plus qu'à résoudre ce problème d'affichage quand on change d'enregistrement et qu'il y a une variation d'une des valeurs source entre les deux enregistrements de la table...

Pourriez-vous me dire où dans le fichier joint cela se produit ? Ou préparer un tel exemple ?

[gaelviller]

Bonjour,
Merci de continuer à vous intéresser à ma demande.

Pourriez-vous me dire où dans le fichier joint cela se produit ? Ou préparer un tel exemple ?

Le "problème" existe déjà dans la base actuelle. Il se produit dans l'unique formulaire présent. On ne s'en aperçoit que si on fait une création ou une modification d'un enregistrement à partir du formulaire en faisant varier la valeur d'une des deux listes déroulantes "sources" (sur lesquelles la macro s'active au "changement"). Une fois la modification effectuée et l'enregistrement sauvegardé, si l'on reste sur le formulaire pour visualiser les précédents enregistrements, lorsque l'un de ceux-ci contient une autre de ces valeurs des listes "sources", alors les listes déroulantes apparaissent vides. Pourtant, si l'on va regarder dans la table, les valeurs enregistrées sont bien présentes. ça semble donc être un problème d'affichage lié à l'utilisation des macros. Cependant, un autre utilisateur voulant bien faire pensera (à tort) qu'il faut remettre les bonnes valeurs dans les champs et il faut alors recommencer par les listes "sources" afin de filtrer les listes de destination et cela pour l'ensemble des enregistrements !
Je ne sais pas si mon explication est assez clair une fois traduite.
En tout cas, encore merci d'accepter de vous pencher sur ce questionnement.

[Rafkus_pl]

Et pourquoi souhaitez-vous modifier un enregistrement existant ? La modification d'une zone de liste permet de réduire le nombre d'éléments affichés, ce qui vous aide à saisir de NOUVEAUX enregistrements.
Un exemple légèrement différent : vous avez un tableau avec l'année et le produit. En 2020, vous avez produit des chaussettes. Vous avez trouvé cet enregistrement et changé l'année (et pourquoi ?) pour celle actuelle - 2024. Vous ne produisez plus de chaussettes cette année, alors que faut-il afficher dans le champ produit ? Vous ne produisez pas de chaussettes cette année, la zone de liste apparaîtra donc vide, mais une valeur existera dans la table source. A moins que vous souhaitiez qu'il soit également supprimé automatiquement...

Ou peut-être souhaitez-vous rechercher un enregistrement dans la table Production (filtrer la table) ? Si tel est le cas, cela se fait à l’aide de sous-formulaires.
Consultez la base de données ci-dessous. J'y ai fait quelque chose que j'ai décrit ici. Est-ce ce que vous vouliez réaliser ?

[gaelviller]

Je vous rassure, je ne souhaite pas modifier des enregistrements. Mes formulaires ont pour vocation de créer les enregistrements des tables et de pouvoir visualiser (à droite) une partie du contenu de la table pour ensuite en afficher le détail dans la partie de gauche.

J'ai évoqué le fait de "modifier ou de créer" un enregistrement parce que lors de mes tests cela se produisait à la création d'un enregistrement. J'ai voulu savoir si cela se produisait aussi suite à la modification d'un enregistrement. Et cela s'est produit dans les deux cas.

Avec le code réactualisé que vous avez proposé (où chaque macro s'appuie sur la fonction que vous avez écrite), cela semble plus stable !
Est-ce lié uniquement à la modification du code ? Ou alors, est-ce dû à l'ajout de cette même macro à l'événement "après le changement d'enregistrement" du formulaire lui-même ?

En tout cas, merci beaucoup pour tous les codes que vous m'avez apportés ! ils sont très efficaces !
Je fais les dernières vérifications avant de repartager la dernière version de la base opérationnelle sur mon premier post et basculer le sujet en [Résolu]