Discussion :

[AlainL]

Bonjour.

Question que je n'arrive pas à résoudre/comprendre:

Cas typique de facturation:
1 table Clients,
1 table Commandes (liée à Clients),
1 table DétailsCommande (liée à Clients et à Commandes).

Dans l'état souhaité:
1/ La section en-tête comporte les infos
- du client sélectionnée (c'est OK)
- de la commande sélectionnée (C'est OK)
2/ la section détail, les DétailsCommande

Le formulaire Client comprte un sous-formulaire Commande, comportant lui-même un sous-formulaire détails.

La requête pour l'état est (j'ai enlevé la liste des champs):

Code :

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

1
2
SELECT 'liste des champs à utiliser'
FROM (CLI INNER JOIN COM ON CLI.CLI_ID = COM.COM_Cli) INNER JOIN COMDET ON COM.COM_ID = COMDET.DET_Com;

Le résultat est que tous les détails de toutes les commandes sont imprimés, à la place d'uniquement les détails de la commande concerné.

Je n'arrive pas à touver comment le forcer à ne sélectionner QUE les détails de LA commande actuellement affichée dans le formulaire concerné.

Alors que dans mon esprit (de nul, désolé ) le second INNER JOIN devrait faire le boulot.

Quelqu'un a-t-il/elle une bonne solution ?

Merci à tous

[vodiem]

salut AlainL,

il te manque une clause "where"
un truc du genre:

Code SQL :

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

... WHERE COM.COM_Cli=Forms![monform]![moncontrol N°COM]

mais il faut que le formulaire concerné soit ouvert.
autrement on peut passer par un filtre il y a plusieurs façon de faire, mais par exemple dans le paramètre du DoCmd.OpenReport cf <F1>

[AlainL]

OK; merci Vodiem, je vais essayer cela.

[AlainL]

Désolé, mais cela ne fonctionne pas non plus.

Egalement essayé avec

Code :

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

Forms("FormulairePrincipal").Controls("FormulaireSecondaire").Form.MonChamp

Désolé, chuis à court d'idées !

[vodiem]

je n'utilise pas cette forme de syntaxe mais je n'y vois pas de pb à première vue. surtout si tu n'as pas de message d'erreur.
il y a un tuto ici qui pourrait t'aider.

si tu n'y parviens toujours pas préviens nous.

[AlainL]

Bonjour Vodiem

Je connais ce tuto, mais je n'arrive toujours pas à obtenir le résultat escompté, à savoir:
- imprimer la facture concernant CE client, pour CETTE commande.

Je me suis créé un mini-DB d'essai, ai passé en revue toutes les formes de sélection qui me venaient à l'esprit, sans résultat.

J'ai ensuite remis tous les filtres, etc zéro, et je joins la DB au cas où toi ou un autre auriez l'amabilité de me faire comprendre comment faire. Le formulaire à ouvrir est Tcli. Il comporte 2 boutons, l'un avec état simple, l'autre avec état comportant un sous-état. J'ai pensé que ce serait peut-être plus parlant qu'une longue explication.

Dans les formulaires, cela fonctionne parfaitement, j'obtiens bien la commande concernant le client choisi.

Mais dans l'état, je n'arrive pas à faire coincider l'impression à ce qui est dans les formulaires.

C'est probablement une question d'une rare bêtise, mais après un quinzaine d'heures passées là dessus... je tourne en rond, désolé.

Merci en tout cas pour votre aimable aide.

[Domi2]

Bonjour,

Si tu veux "toucher" plus de monde, il serait bien que tu convertisses ta base au format Access 2000.

Toutefois, deux de tes commentaires m'intrigue.

1 table DétailsCommande (liée à Clients et à Commandes).

imprimer la facture concernant CE client, pour CETTE commande.

Aurais-tu établi un lien directement entre Clients et DétailsCommandes ? Si oui, ce n'est pas nécessaire, des liens Clients ==> Commandes ==> DétailsCommandes sont suffisant.

Pour ta deuxième remarque, c'est peut-être une question de "mauvaise approche".

Une commande appartient à un client et un seul. Donc se poser la question de savoir comment imprimer CETTE commande suffit (les informations relatives au client suivront toutes seules).

Courage

Domi2

[mout1234]

Bonjour,

Je pense que le premier problème vient de ta structure relationnelle: tu as fait un lien entre la table client et la table détail.... Supprime ce lien et ajoute une relation entre Com_CliID et Det_CliID.


Edit: En fait, il ne devrait pas y avoir de champ Det_CliID...

Bon courage

[mout1234]

Pour t'aider, je te propose un peu de lecture:

La théorie, et notamment les formes normales qu'il est conseillé de respecter (au moins jusqu'à la trosième forme):
http://laurent-audibert.developpez.c...urs-BD014.html

Un peu moins théorique:
http://mhubiche.developpez.com/Acces...s/bases/#LII-3

Un sujet dérivé, les jointures:
http://mhubiche.developpez.com/Access/tutoJointures/

[AlainL]

Whaou... Il y a du monde pour un dimanche

Domi2:

Oui, j'ai cette relation, en fait pour usage ultérieur "qui a commandé quoi et quand". Mais en la supprimant, cela ne change pas le résultat au niveau de l'état.

Et tu as certainement raison: il y a à coup sûr un gros défaut dans mon raisonnement

Une commande appartient à un client et un seul. Donc se poser la question de savoir comment imprimer CETTE commande suffit (les informations relatives au client suivront toutes seules).

Eh oui... c'est bien là tout le (enfin, mon) problème...

Mout1234:

Supprime ce lien et ajoute une relation entre Com_CliID et Det_CliID.

La relation que tu me demandes d'ajouter n'est alors possible que sans intégrité.

Et merci pour ces liens... je ne les avais pas... j'ais avoir un mal de crâne ce soir, je le sens.....

Mais une chose est sûre: on se sent moins seul ici :0))))))

[AlainL]

En fait, mon raisonnement de base était:

A - si, dans les formulaires, le résultat est juste, appliquer la même méthode sur les états devrait donner le même résultat (dans ce cas, l'état appelé Tfact_2, comportant la même structure que les formulaires, devrait fonctionner comme un charme au lieu de me jeter un mauvais sort);

Ce qui est visiblement erroné

B - si, dans un formulaire, j'affiche après sélection manuelle tel enregistrement, lorsque je donne l'ordre d'imprimer ma facture, il va automatiquement sélectionner l'enregistrement présent actuellement sur le formulaire par défaut;

Ce qui semble encore plus faux que le A re-

Ah, le bon temps où l'on programmait en COBOL, RPG, et autres langages simple.......... (oui je sais, chuis un dynosaure, qui a même connu les "ficelles", pour ceux qui auraient un vague souvenir des tabulatrices - ils ne doivent pas être nombreux ici)

[Domi2]

Re,

Et un exemple de ta base au format Access 2000 ?

Domi2

[vodiem]

salut Domi2, mout1234 et AlainL,

je laisse nos amis érudits te dispenser de leur savoir et de leur précieux conseils.
j'ai regardé de façon superficielle la structure qui te concerne et voici le sql que tu dois je pense chercher:

code SQL pour la source de ton état:

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
11
12
SELECT
   Tcli.Cli_ID,
   Tcli.Cli_Nom,
   Tcom.Com_ID,
   Tcom.Com_CliID,
   Tcom.Com_Num,
   Tdet.Det_CliID,
   Tdet.Det_ComID,
   Tdet.Det_Det
FROM (Tcli INNER JOIN Tcom ON Tcli.Cli_ID=Tcom.Com_CliID)
   INNER JOIN Tdet ON Tcom.Com_ID=Tdet.Det_ComID
WHERE (((Tcom.Com_Num)=[Formulaires]![Tcli]![Tcom].[Form]![Com_Num]));

crée par le générateur d'expression.
sinon:

Code SQL :

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

WHERE Tcom.Com_Num=Forms![Tcli]![Tcom].Form![Com_Num]

est tout aussi correcte.

ton raisonnement:
.A est correcte sauf que l'état prend une référence dans le formulaire.
.B n'est pas correcte: l'impression n'est pas liée au formulaire actif (bien heureusement). il faut les comprendre comme ils sont: des fenêtres indépendantes.

Forms("FormulairePrincipal").Controls("FormulaireSecondaire").Form.MonChamp

cela m'avait échappé mais ce n'est pas accepeté par le SQL mais par VB.
le SQL est un langage à part et l'intégration de "Forms" ne fait pas parti de la normalisation de celui-ci, il est propre à access et doit respecter une certaine syntaxe. donc le mélange de VB (utilisation de méthodes d'objet) ne peut être interprété ainsi.

COBOL, RPG, et autres langages simple

tout est simple pour celui qui sait. ;p

oui je sais, chuis un dynosaure

he bien si on peut aider nos amis les reptiles en voie d'extinction, moi je suis pour...

he bien Domi2? on n'arrive pas à lire du 2007? les dinosaures seraient-ils plus avancés sur ton temps?

[Domi2]

Bonjour,

he bien Domi2? on n'arrive pas à lire du 2007? les dinosaures seraient-ils plus avancés sur ton temps?

Ah ! L'Adminisrtration n'étant pas aussi lente qu'on le dit, on peut espérer une migration avant la sortie de la prochaine version d'Office...

Quoi qu'il se murmure qu'on "sauterait" une version... Ce qui ferait deux, si je compte bien...

Et non, pas encore fait le pas au "privé"...

Peut-être le père Noël déposera-t-il une joli paquet dans mes petits souliers, qui sait ?

Domi2

[AlainL]

Merci beaucoup Vodiem, et tous les autres.

Ton exemple m'a permis de régler le problème, et surtout de piger où était l'erreur dans l'interprétation que j'avais de la méthodologie.

Domi2:
Désolé, ai pas pensé que tu souhaiterais en avoir une copie

D'autre part, vu que Office Entreprises 2007 est disponible pour moins de USD 90... cela ne vaut plus la peine de s'en priver

Encore un grand merci à tous, c'est sympa d'aider les pôv oisillon qu'en ont raz la coquille.