Discussion :

[Blunet]

Bonjour tout le monde, je voudrais créer une procédure qui me permette de mettre à jour des recorsets des contrôles Data.
J'ai une feuille avec plusieurs contrôles Data (ctrlDataA, ctrlDataB, etc. par exemple) chaune reliée à une table spécifique (TableA, TableB, etc.). Seulement dans ma base de donnée toutes ces tables reliées aux contrôles Data ont une partie de la clé en commun (Nom, Modèle, Entité, Année) et l'autre partie des clés des tables varie (Couleur pour TableA, Taille pour TableB, etc.).
Alors pour ne pas avoir à répéter le même code, j'ai créé une procédure, mais elle ne marche pas:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
Sub MAJ()
  KeyTables (ctrlDataA)
  KeyTables (ctrlDataB)
End Sub

Public Sub KeyTables(ctrlData As Data)
'Mets tous les ctrlData en mode Ajout et donne les clés des tables
'pour permettre les enregistrements sans doublons dans les Recorsets
With ctrlData.Recordset
    If .EditMode = dbEditNone Then
        .AddNew
        !Nom = "Paul"
        !Modèle = "Test"
        !Entite = Combo1.ListIndex + 1
        !Num_Periode = 2006
  End If
End With
End Sub

Je n 'y arrive pas et je suis donc oblige de réécrire sensiblement le même code comme ci-dessous

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
With ctrlDataA.Recordset
    If .EditMode = dbEditNone Then
        .AddNew
        !Nom = "Paul"
        !Modèle = "Test"
        !Entite = Combo1.ListIndex + 1
        !Num_Periode = 2006
    End If
End With

With ctrlDataB.Recordset
    If .EditMode = dbEditNone Then
        .AddNew
        !Nom = "Paul"
        !Modèle = "Test"
        !Entite = Combo1.ListIndex + 1
        !Num_Periode = 2006
    End If
End With

Merci pour votre coup de main…

[jacma]

Bonjour

Il me semble que tu es dans un cas de figure assimilable à un recordset hiérarchique, même si tu ne le traites pas comme tel. Tu devrais donc envisager de créer un recordset hiérarchique, avec une table Dans laquelle tu as des enregistrements avec les noms (table parent), et une (ou des) autre table (table enfant) dans laquelle tu as tes autres données. Le champ de liaison entre les tables est bien entendu le nom.

Tu peux créer un tel recordset hiérarchique avec un DataEnvironment, presque tout aussi simplement qu'avec les contrôle data. Tout est graphique et la démarche en est similaire, sauf que tu aura un seul DataEnvironment doté de plusieurs objets Command (une commande par table enfant).

Ceci étant, je t'invite également à bien penser la structure de ta base de données. Pourquoi toutes ces tables avec les mêmes informations?

[Blunet]

Bonjour,
Je te remercie, c'est vrai que j'ai pas envisagé les recordsets hiérarchiques. En fait je suis complètement débutant en VB6, d'ailleurs toute la documentation dont je dispose et qui m'a aidé à faire ce que je peux aujourd'hui provient des praticiels dispoinibles sur ce site.
Bravo car non seulement ils sont super bien rédigés, l'explication est claire.

C'est vrai que dans l'un des praticiels, on explique la méthode d'accès aux données par DataEnvironment avec les objets Command. Mais on y parle pas de table parent/enfant du moins dans le praticiel praticielinitdb.pdf
P R E M I E R S P A S A C C È S A U X D O N N É E S
A C C É D E R A U X D O N N É E S D ' U N E B A S E A C C E S S E T L E S U T I L I S E R
Je vais faire une nouvelle recherche sur le site.

Concernant la structure de la Base de Donnée, c'est vrai que je ma suis arrêté pour le moment au MLD (Modèle Logique de Donnée) mais je crois que les informations ne sont pas redondantes.
Il s'agit enfait d'une clé composée : la partie commune de cette clé est Nom,Modèle,Entite,Num_Periode et la partie variable qui concerne les tables en question peut être Couleur pour une table, Taille pour une autre.
Ce qui fait que les tables ont de clés du style :Nom,Modèle,Entite,Num_Periode,Couleur pour une ou :Nom,Modèle,Entite,Num_PeriodeTaille pour une autre.
C'est à cause une association multiple mais nécessaire que j'ai cette configuration.

[ouskel'n'or]

Hello Blunet,
Mets le tag [VB6] sur la discussion (bouton Editer). Et la prochaîne fois, vas sur le bon forum. VB6 et antérieurs Je déplace ta question.

[jacma]

C'est vrai que dans l'un des praticiels, on explique la méthode d'accès aux données par DataEnvironment avec les objets Command. Mais on y parle pas de table parent/enfant du moins dans le praticiel.

Pour les recordsets hiérarchiques, consultes le praticiel "Grille et recordset hiérarchique". Une des form utilise un DataEnvironment et deux objets Command.

Concernant la structure de la Base de Donnée, c'est vrai que je ma suis arrêté pour le moment au MLD (Modèle Logique de Donnée) mais je crois que les informations ne sont pas redondantes.

Il y a bien redondance puisque Nom,Modèle,Entite,Num_Periode sont dans toutes les tables et pour chaque couleur et chaque table...

Il s'agit enfait d'une clé composée : la partie commune de cette clé est Nom,Modèle,Entite,Num_Periode et la partie variable qui concerne les tables en question peut être Couleur pour une table, Taille pour une autre.
Ce qui fait que les tables ont de clés du style :Nom,Modèle,Entite,Num_Periode,Couleur pour une ou :Nom,Modèle,Entite,Num_PeriodeTaille pour une autre.
C'est à cause une association multiple mais nécessaire que j'ai cette configuration.

Il me semble qu'ainsi tu utilises une table comme tu utiliserais un champ... Une seule table devrait te suffire avec ta clé composée. Tu y rajoutes tes deux champs Couleur et Taille. La saisie des valeurs de ces deux dernier champs peut se traiter au niveau de la form pour laquelle diverses méthodes sont possibles pour n'afficher et donc ne saisir que celle du champ ad hoc (couleur ou taille). Idem pour la consultation. Ensuite, tu peux éventuellement utiliser des filtres et/ou une recherche avec la méthode Find.

D'ailleurs, pour ce qui concerne la clé, je ne suis pas sûr qu'une clé composée soit nécessaire. Si je comprend bien, tu as un "article" identifié par un nom. Les autres champs concernent des caractéristiques de l'article. C'est à ce niveau probablement que devrait servir un recordset hiérarchique.

J'espère avoir compris ce que tu cherches à obtenir. Si ce n'est pas le cas, je te conseille de détailler en bon français ce que tu traites et ce que tu veux obtenir à l'utilisation (ce que l'utilsateur doit faire) et non comment l'obtenir. C'est beaucoup plus important à ce stade que MLD, MLC... Ensuite, on se préocupera du comment en ayant la même vision de l'attente et des besoins de l'utilisateur.

[Blunet]

Salut, Jacques
J'essaye de créer pour mes besoins de recherche en Gestion d'entreprise (Master en Gestion quantitative) une petite de simulation de l'interaction des entreprises sur un marché concurentiel. Il s'agit de les évaluer en amont sur la production, le commercial, et les états financiers. Les évaluations sont simples, il s'agit de traduire leurs choix en pourcentage de part de marché de coûts (ou de poids) sur le CA.

Chaque simulation a un nom (Nom), un modèle Concurrence Pure et Parfaite CPP (Modèle), plusieurs entreprises (Entite), plusieurs années d'exercice (Num_Periode). Donc a priori tout ces éléments sont des tables.
Une entreprise a plusieurs type de personnel (Cadre, etc.), de produits (haut de gamme, etc.) donc la encore à priori des tables.

Je veux enregistrer les informations précédentes sur un seul formulaire dans les tables concernées.
Je parviens à le faire mais avec la répétition du code comme j'ai indiqué dans mon premier post. c'est pour cette raison que j'ai voulu créer une procédure qui a pour arguments soit les contrôles Data soit en argument DataBaseName
La résolution de ce problème me permettra de savoir comment programmer la recherche des informations d'une entreprise.

Alors l'utilisateur en occurence moi ou tout autre simulateur, peut enregistrer (méthode AddNew) les choix des entreprises (Type de produit, qté, type de personnel, qté, type de matériel, qté) pour une année donnée (NumPeriode).
L'utilisateur peut aussi (s'il y'a erreur de saisie ou pour des besoins de simulation d'une variable particulière) retrouver un enregistrement (choix) d'une entreprise et la modifier (méthode Update)

Je ne sais pas si j'ai été clair... De toute les façons merci...

[jacma]

Bonjour

Donc, si je comprends bien, à la base tu as une simulation dotée des caractèristiques Nom, Modèle, Entité et NumPeriode.
Les entités (entreprises) sont dotées des caractéristiques Personnel, Produits..., et ceci par annéee je présume?

Dans ces conditions, il y a une simulation dont on précise l'ID (je suppose qu'il y en a plusieurs) et ses caractéristiques. Il faut saisir les entreprises et les années concernées. Disons que c'est le premier niveau.

Au second niveau, tu as des entreprises (Entité), dotées elles aussi de caractéristiques multiples, dont le personnel et les produits. Là, il convient de préciser les information relatives à ces deux caractéristiques. Pour le personnel: Type, Nombre, Salaires (moyen)... Pour les produits: Type, Quantité, Prix, Coût...
Comme je présume (là aussi) que les types de personnel sont semblables, de même que les type de produits, ces deux caractèristiques sont de troisième niveau, mais peuvent être intégrées au second.

Détaillons maintenant ce que fait l'utilisateur et ce que celà implique.

1er niveau: Saisie d'une nouvelle simulation.
L'utilisateur défini le modèle de simulation. Comme ily a plusieurs modèles, il peut en sélectionner un dans une liste. Et, il y a un fichier derrière.
Il indique également les entreprises concernées, soit dans une liste, soit dans de zones de texte si le nombre d'entreprises est limité.
Chaque nouvelle simulation est dotée d'un ID (code, numérotation automatique...) et éventuellement d'information complémentaires à définir.

2ème niveau: saisie des informations des entreprises.
Les informations sont très probablement différentes d'année en année. Donc l'année est à définir, et il y aura une fiche par année/entreprise. Le nom d'une entreprise peut être sélectionné dans une liste.
Concernant le personnel et les produits, ont peut les intégrer à ce niveau, comme dit précédemment, ce si ces caractèristiques sont identiques et n'évoluent pas dans leur nombre et leur structure (pas de nouvelle caractéristique par exemple). Dans ce cas, pour ces deux caractéristiques, on aurait un tableau avec les valeurs pour chacun de leurs éléments (Type, Prix, Quantité... pour les produits et Type, Salaire, Nombre pour le personnel).

3éme niveau: les informations détaillées
Ce niveau est à considérer surtout si la nature et la quantité de ces informations est destinées à évoluer et/ou si elles ne sont pas identiques. Sinon on les intégrera au niveau deux, comme précisé précédemment.

Compte tenu de tout celà, il existe plusieurs possibilités pour la structure de la base de données. La plus évidente me semble être:
- une table pour les fiches simulation, table qui sera une table parent dans le cadre d'un recordset hiérarchique.
- une table pour les fiches des entreprises, table fille de la prémière.

Pour la saisie, il faut dissocier la saisies des informations pour chacune des tables. Il me semble impossible de tout saisir dans un seul formulaire si on tient compte qu'une simulation peut porter sur n entreprises et x années. Il sera toujours possible d'accéder pour consultation et/ou modification, directement à une fiche pour une simulation donnée, ou à une fiche pour une paire Simulation /Entreprise.

Qu'en penses-tu?