Discussion :

[jibeu]

hello,

je suis nouveau sur ce forum, et je viens vers vous car je cale là!
sachez aussi que je suis un novice en access (2010).

Voilà, comme vous pouvez le voir sur l'image au dessus, je gère des activités (définies par un numéro) et je peux télécharger d'un système d'inscription la table suivante.
dans cette table, on peux voir qu'un client fait plusieurs inscriptions pour différentes activités.
j'ai fait plusieurs requêtes où j'ai mes codes d'activités en première colonne suivis des détails sur les clients.
mais comme les clients font plusieurs choix dans leurs commandes, je dois créer autant de requêtes qu'il y a d'activités choisies dans chaque commandes des clients.
maintenant, il y a une colonne prévue pour chaque commandes qui me permet de confirmer que mes clients sont bien acceptés dans l'activité qu'ils ont demandé.
Quand j'encode à partir de mes requêtes, ça s'encode aussi sur ma table d'inscription, ce qui est super!
malheureusement j'aimerais bien avoir toutes mes requêtes sur un seul tableau (une requête ou une table, qu'importe) et que je puisse continuer d'encoder dessus pour que ceci puisse s'encoder sur la table principale.

Voilà, j'espère que je suis clair... j'ai eesayer de faire une requête union de toutes mes requêtes selections, mais apparement je ne peux rien y encoder...
voyez-vous une autre méthode (pas trop complexe plz!)

[jibeu]

personne?...

[madefemere]

Bonjour,

Une petite question pour bien appréhender le problème et le souci :
- Est-ce que l'importation de la table va se faire UNE SEULE FOIS et tout va être géré sous Access après ou il y aura d'autres importations ?
- Il y aura combien d'activités en gros (pour tous les clients)? 2,3,30,...

Parce que d'après ce que vous dites, vous avez des tables par rapport aux activités avec une nouvelle colonne où vous enregistrez la confirmation.

Parce que si l'importation est faite une bonne fois pour tout, on pourra créer une table à partir de la requête UNION, mais QUI ne récupèrera plus de nouvelles données.

Sinon, on pourrait créer la table qui va être utilisée sous Access et à chaque importation, recréer une nouvelle requête union et ajouter les données dans la table créée précédemment en filtrant les données (accepter les nouvelles mais refuser les existantes).

J'espère que je raconte vous dit quelque chose.

Cordialement,

[jibeu]

Merci pour votre réponse!

Avant tout, je vois que je n'ai pas expliqué jusqu'au bout mon soucis.

Donc:
Les tables que j'importe vienne d'un système d'enregistrement en ligne.
Ce que je souhaite faire c'est importer cette table des commandes ("T-inscription")pour encoder mes confirmations (dans le champs "pick" à droite de l'image) sur cette table. Ensuite, je dois exporter cette dernière sur le système d'enregistrement en ligne.
Celui-ci pourra ensuite envoyer un courriel automatique aux clients pour confirmer leurs commandes.

Là où ça se gâte c'est que j'aimerais faire mes confirmations sur une table, requête ou formulaire (peu importe!^^), qui puisse faire directement les changements sur la table des commandes.

Ce que j'ai fait jusqu'à maintenant pour faciliter mes confirmations, j'ai créé des requêtes classées par activités (ex: "Q-T-inscription-1"). ce qui fait que je me retrouve avec 8 requêtes pour le moment (les clients peuvent avoir 14 commandes possible mais le maximum est de 8 commandes par client pour le moment).
Voilà, au lieu de jongler avec mes 8 requêtes, j'avais essayer de faire une nouvelle requête union qui me permettrait d'avoir tout sur une page, mais le soucis c'est que cette requête n'accepte pas d'ajouts dans les champs "pick" de confirmations!
Et aussi, je dois envoyer ma table de commandes dans la même structure que celle que j'importe.

Voilà,

pour palier aux soucis d'éventuelles nouvelles inscriptions, j'ai crée une copie de cette table des commandes ("T-inscriptions-2"). car quand je fais les mises à jours sur ma table importée, la macro lance des requêtes suppression et des requêtes ajout et ainsi toutes les confirmations que j'aurais pu encoder se retrouveraient effacées vu que je dois d'abord exporter cette table avec les confirmations sur le système d'inscription.
donc pour le moment, j'encode mes confirmations sur "T-inscriptions-2"
j'ai créé une autre macro de mise à jour de "T-inscriptions-2" se calquant sur "T-inscriptions" sans effacer les confirmations "pick" que j' aurais pu faire entre-temps.

Maintenant, sincèrement... je cale

Sinon, pour répondre à vos questions:
- oui, il y aura plusieurs fois des importations car nous ouvrons les inscriptions toute l'année.
- il est prévu 14 activités max, mais pour le moment, la plus grosse commandes monte à 8 activités .

j'espère aussi que vous comprendrez mon explication

[madefemere]

Bonjour,

OK pour l'explication globale.
Dans le détail, est-ce à dire que :

Pour chaque Client (identifié dans la table importée par les champs User_id et student_id j'imagine) :
Ils peuvent s'inscrire sur les activités (caseXa,CaseXb, caseXc,...).
Et vous confirmez dans Access en cochant les champs pickX,... correspondants.

Si c'est le cas, Questions :
- Actuellement vous avez 12 champs caseXXX. Est-ce que ça veut dire que ça peut augmenter quand vous recevez les données de l'enregistrement enligne?
- Quelle est la relation entre les caseXa et pickX ?

Cordialement,

[jibeu]

Bonjour,

Pour chaque Client (identifié dans la table importée par les champs User_id et student_id j'imagine) :
Ils peuvent s'inscrire sur les activités (caseXa,CaseXb, caseXc,...).
Et vous confirmez dans Access en cochant les champs pickX,... correspondants.

c'est exact!

Par contre, il y a beaucoup plus de champs caseX que ceux visible sur le printscreen!

ex: le champs "Case1a" correspond à une commande. Le champs "case1b" correspond à une commande alternative si la première commande ne pourrait être satisfaite.
Le champs "case1c" n'est pas utilisé c'est une structure ancienne qui est resté sur la table mais que nous n'utilisons pas.
Ce qui fait qu'il y a 14 champs "caseXa", 14 champs "caseXb" et 14 champs "pick". ils ne sont tout simplement pas visible car la table est trop longue!

les codes repris dans les champs caseX et pick sont liés à une table qui reprend les infos propre à chaque activités (durée, lieu, prix, etc.).
Pour mes requêtes Q-T-inscriptionsX j'ai donc dû créer 3 tables: une pour le 1° choix, une pour le 2° choix alternatif et une pour la confirmation. elle se nomment T-activities-1 (2 et 3) (visible sur le printscreen).

Donc pour en revenir à votre dernière question: les champs "caseXa" sont reliés à la table T-activities-1, les champs "caseXb" sont reliés à la table T-activities-2 et les champs "pickX" sont reliés à la table T-activities-3.

voilà, sa ce gâte!