OVH Cloud OVH Cloud

ajout ou mise à jour ou union ?

9 réponses
Avatar
zarbout
Bonjour,
je suis confronté à une question que je pense simple pour beaucoup d'entre
vous mais l'autodidacte que je suis peine à trouver son chemin.
Pour bien exposer mon problème, un novice comme moi risque d'être bavard.

Voilà : je travaill avec une BDD contenant table dont les données doivent
actualisées tout les jours à partir d'un fichier DBF utilisé par une autre
appli : qui est l'appli principale dans laquelle toutes les données sont
saisies (GEP pour les administratifs de l'éducation nationale). Je ne peux
pas travailler directement avec le fichier DBF car il ne prend pas de Clé
Primaire alors que j'en ai besoin dans ma BDD.
Ma table "cible" a donc la même structure que le fichier DBF "source" sauf
que l'un des champ me sert de Clé Primaire.
L'actualisation quotidienne consiste à comparer la "cible" et la "source" et
faire en sorte que la cible contient les les mêmes enregistrements que la
source ( virer quelques enregistrements, ajouter d'autres ou modifier les
infos relatives à d'autres).
Dois-je faire 2 requetes (Suppression de tous les enregistrements de la
cible et ajout de tous les enregistrements de la "source") ce qui est lourd
ou
faire une requete Mise à jour (que j'arrive pas à mettre en place)
ou une requete Union (que j'arrive pas à mettre enplace aussi faute de
connaitre la syntaxe) ?
Merci pour votre patience et votre aide.
zarbout

9 réponses

Avatar
Damien Mermoz
Salut,

si j'ai bien compris : tu a une table source et une table cible. La table
cible doit contenir toutes les données de la table source. La seule
différence c'est que ta table cible à un champ en plus.
Il faut donc que tu vérifies qu'il n'y a pas de données dans ta table source
qui ne soient pas dans la table cible.
Pour cela Access te propose un assistant : Requete de non correspondance.

Dans l'onglet requete de ta base tu choisis [nouveau] puis assistant requete
de non correspondance. Ensuite tu suis l'assistant. Evidemment il te faut un
champ commun dans tes deux tables qui te permette de distinguer les nouveaux
enregistrements.

Ensuite tu affiches cette requete en mode création puis tu choisis requete
ajout; tu choisis la table cible et tu exécute la requete ainsi modifier.
Seul les nouveaux enregistrements seront ajoutés. C'est la méthode la plus
propre que je vois.
En espèrant que ça t'aide.

A +
Damien.
Avatar
zarbout
pour ajouter des enregistrements ça marche nickel. Toutefois pour mettre à
jour des enregistrements qui existent dans la table cible pour qui une
valeur dans un champ quelconque (autre que la clé primaire) à changé dans la
table source, comment faire ? la requete de non-correspondance se fonde sur
la comparaison d'un seul champ dans les 2 tables !!
Je suis étonné que l'on puisse pas faire cela d'une façon simple sous Access
!! ou suis-je limité moi même (c'est plus probable en toute modestie ..)
Merci tout de même pour le conseil




"Damien Mermoz" wrote in message
news:
Salut,

si j'ai bien compris : tu a une table source et une table cible. La table
cible doit contenir toutes les données de la table source. La seule
différence c'est que ta table cible à un champ en plus.
Il faut donc que tu vérifies qu'il n'y a pas de données dans ta table
source

qui ne soient pas dans la table cible.
Pour cela Access te propose un assistant : Requete de non correspondance.

Dans l'onglet requete de ta base tu choisis [nouveau] puis assistant
requete

de non correspondance. Ensuite tu suis l'assistant. Evidemment il te faut
un

champ commun dans tes deux tables qui te permette de distinguer les
nouveaux

enregistrements.

Ensuite tu affiches cette requete en mode création puis tu choisis requete


ajout; tu choisis la table cible et tu exécute la requete ainsi modifier.
Seul les nouveaux enregistrements seront ajoutés. C'est la méthode la plus
propre que je vois.
En espèrant que ça t'aide.

A +
Damien.




Avatar
Damien Mermoz
Salut,

hehe c'est bien pour ça qu'on aime les clé primaires, répérer un
enregistrement identique sans ces clés est très compliqué. Cela demande
souvent de créer des algorythmes compliqués et même parfois une analyse
visuelle (ce qui, tu t'en doutes, est extrêmement chiant)

Pour le cas d'une modification d'enregistrement dans la table source ça me
semble plus compliqué :
Le mieux c'est quand même de répérer ces enregistrements à l'avance par
exemple avec un champ date de modification dans ta table source mais je ne
sais pas si tu controles cette base. Dans ce cas tu met un critère sur la
date de modification et tu rajoutes un critère Tablesource_ChampA Tablecible_ChampA en choisissant bien sûr le champ le plus approprié pour
comparer les deux table. Tu met à ainsi à jour tous les champs de ta table
cible autre que ta clé primaire et que ton champ A.
Sinon vu que tes données proviennent systèmatiquement de ta table source tu
peux essayer de concatener plusieurs champs et de faire ta liaison externe
dessus. Je m'explique : mettons que tu as un champs Nom; prénom; date de
naissance.
Tu crées un nouveau champ dans une requete qui fusionne ces champs : la
synthaxe est
ChampConca : [Nom]&[Prenom]&[date de naissance]
Tu fais ceci pour chacune des tables. Puis tu lance l'assistant requete de
non correspondance en faisant la comparaison sur ce nouveau champ qui est
plus riche puisque dans mon cas il compare 3 champs à la fois.
Tu repères les enregistrement à mettre à jour, et tu lances ta requete. Bien
sûr cette opération ne doit se faire qu'après avoir ajouté les nouveaux
enregistrements.

Voilà, honnetement c'est compliqué mais ce n'est pas un pb d'access c'est un
pb courant de normalisation. Je suis obligé de rester un peu dans le vague
car la réponse dépend certainement de tes données. C'est à toi de voir si tu
peux utiliser tel ou tel champ pour baser ta comparaison. Si tu bloques tu
peux mettre un nouveau message en expliquant ton pb spéfifique pour voir si
d'autres voient des solutions moins complexes.

A +
Damien.

"zarbout" a écrit dans le message news:
3f5b8a87$0$23108$
pour ajouter des enregistrements ça marche nickel. Toutefois pour mettre à
jour des enregistrements qui existent dans la table cible pour qui une
valeur dans un champ quelconque (autre que la clé primaire) à changé dans
la

table source, comment faire ? la requete de non-correspondance se fonde
sur

la comparaison d'un seul champ dans les 2 tables !!
Je suis étonné que l'on puisse pas faire cela d'une façon simple sous
Access

!! ou suis-je limité moi même (c'est plus probable en toute modestie ..)
Merci tout de même pour le conseil




"Damien Mermoz" wrote in message
news:
Salut,

si j'ai bien compris : tu a une table source et une table cible. La
table


cible doit contenir toutes les données de la table source. La seule
différence c'est que ta table cible à un champ en plus.
Il faut donc que tu vérifies qu'il n'y a pas de données dans ta table
source

qui ne soient pas dans la table cible.
Pour cela Access te propose un assistant : Requete de non
correspondance.



Dans l'onglet requete de ta base tu choisis [nouveau] puis assistant
requete

de non correspondance. Ensuite tu suis l'assistant. Evidemment il te
faut


un
champ commun dans tes deux tables qui te permette de distinguer les
nouveaux

enregistrements.

Ensuite tu affiches cette requete en mode création puis tu choisis
requete



ajout; tu choisis la table cible et tu exécute la requete ainsi
modifier.


Seul les nouveaux enregistrements seront ajoutés. C'est la méthode la
plus


propre que je vois.
En espèrant que ça t'aide.

A +
Damien.








Avatar
Hubert Canevet
D'après ce que je comprends tu disposes d'informations
dans une table d'une base existante, qu'il vaudrait mieux
éviter de modifier. Sur les mêmes enregistrements tu
voudrais stocker des informations dans des champs
supplémentaires.

Pour ce qui est de la structure des données, je verrais
bien une table liée sur la table de GEP, et une autre
table avec le même champ clef, qui contiendra les champs
manquants.

Admettons que les tables s'appellent [tbs Actions] pour la
table liée sur la table préexistante et [tbs ConvActions]
pour la table avec les nouveaux champs (ça m'arrange parce
que j'ai déjà un exemple sous la main) et que la clef
s'appelle CodeAction. On pourra obtenir l'ensemble des
informations par la requête suivante.

SELECT DISTINCTROW [tbs ConvActions].*, [tbs
Actions].IntituleAction
FROM [tbs ConvActions] LEFT JOIN [tbs Actions] ON [tbs
ConvActions].CodeAction = [tbs Actions].CodeAction
ORDER BY [tbs Actions].IntituleAction;

Mon exemple initial avait une finalité différente, mais je
ne crois pas me mélanger trop les pinceaux.

La requête de non-correspondance indiquée par Damien
permet de localiser dans [tbs Actions] les enregistrements
non créés dans [tbs ConvActions], admettons que cette
requête s'appelle ['tbs Actions' et 'tbs ConvActions' sans
correspondance]

La requête suivante permettra de créer les enregistrements
manquants d'un coup, bien entendu seul le champ clef sera
renseigné, il faudra saisir les autres.

INSERT INTO [tbs ConvActions] SELECT CodeAction FROM ['tbs
Actions' et 'tbs ConvActions' sans correspondance]

Nous avons donc une table liée sur GEP ([tbs Actions] dans
mon exemple), donc des informations à jour, et une table
avec les champs manquants ([tbs ConvActions] dans mon
exemple).

Il reste à voir si des précautions supplémentaires sont
nécessaires pour ne pas modifier la table source. Si
l'application source donne accès en lecture seule ça
devrait être facile à gérer.

Il restera à supprimer dans [tbs ConvActions] les
enregistrements correspondants lorsque des enregistrements
sont supprimés dans [tbs Actions].

Pour cela je verrais bien une requête de non-
correspondance mais dans le sens inverse de celle utilisée
tout-à-l'heure. On pourrait l'utiliser reqASupprimer, et
une autre requête du style
DELETE FROM reqASupprimer
pourrait donner le résultat.

Attention, bien visualiser les premières fois le contenu
de reqASupprimer avant de faire la suppression, d'autant
que je n'ai pas fait de test dessus.

Concernant la notion de clef. Si la table source ne
contient pas de doublon il ne doit pas y avoir de
problème, du reste l'ordre des enregistrements est obtenu
par la clause ORDER BY. Il me semble que ça ne serait pas
spécialement une mauvaise idée que CodeAction soit une
clef dans l'autre table, ça ne mange pas de pain.

+ + +

Une remarque au sujet d'une requête Union : elle permet de
concaténer deux tables ou requêtes contenant
impérativement les mêmes champs. Si on unit une table de 5
enregistrements et une de 7, on obtiendra 12
enregistrements, sauf doublons. Si toutefois il y a un
champ en plus ou en moins dans l'une par rapport à
l'autre, on n'obtiendra rien d'autre qu'une erreur.
Avatar
Hubert Canevet
Pour cela je verrais bien une requête de non-
correspondance mais dans le sens inverse de celle
utilisée

tout-à-l'heure. On pourrait l'utiliser reqASupprimer, et
___

On pourrait l'appeler reqASupprimer,
ce serait sûrement plus facile à comprendre.
___
une autre requête du style
DELETE FROM reqASupprimer
pourrait donner le résultat.


Avatar
zarbout
heureusement que le concepteur de la table source a prévu (pour un autre
but) un champ date de modification qui me permettre de me baser dessus pour
comparer des enregistrements qui existent dans les 2 tables, je vais suivre
ce filon pour voir ce que ça donne.
merci




"Damien Mermoz" wrote in message
news:
Salut,

hehe c'est bien pour ça qu'on aime les clé primaires, répérer un
enregistrement identique sans ces clés est très compliqué. Cela demande
souvent de créer des algorythmes compliqués et même parfois une analyse
visuelle (ce qui, tu t'en doutes, est extrêmement chiant)

Pour le cas d'une modification d'enregistrement dans la table source ça me
semble plus compliqué :
Le mieux c'est quand même de répérer ces enregistrements à l'avance par
exemple avec un champ date de modification dans ta table source mais je ne
sais pas si tu controles cette base. Dans ce cas tu met un critère sur la
date de modification et tu rajoutes un critère Tablesource_ChampA > Tablecible_ChampA en choisissant bien sûr le champ le plus approprié pour
comparer les deux table. Tu met à ainsi à jour tous les champs de ta table
cible autre que ta clé primaire et que ton champ A.
Sinon vu que tes données proviennent systèmatiquement de ta table source
tu

peux essayer de concatener plusieurs champs et de faire ta liaison externe
dessus. Je m'explique : mettons que tu as un champs Nom; prénom; date de
naissance.
Tu crées un nouveau champ dans une requete qui fusionne ces champs : la
synthaxe est
ChampConca : [Nom]&[Prenom]&[date de naissance]
Tu fais ceci pour chacune des tables. Puis tu lance l'assistant requete de
non correspondance en faisant la comparaison sur ce nouveau champ qui est
plus riche puisque dans mon cas il compare 3 champs à la fois.
Tu repères les enregistrement à mettre à jour, et tu lances ta requete.
Bien

sûr cette opération ne doit se faire qu'après avoir ajouté les nouveaux
enregistrements.

Voilà, honnetement c'est compliqué mais ce n'est pas un pb d'access c'est
un

pb courant de normalisation. Je suis obligé de rester un peu dans le vague
car la réponse dépend certainement de tes données. C'est à toi de voir si
tu

peux utiliser tel ou tel champ pour baser ta comparaison. Si tu bloques tu
peux mettre un nouveau message en expliquant ton pb spéfifique pour voir
si

d'autres voient des solutions moins complexes.

A +
Damien.

"zarbout" a écrit dans le message news:
3f5b8a87$0$23108$
pour ajouter des enregistrements ça marche nickel. Toutefois pour mettre
à


jour des enregistrements qui existent dans la table cible pour qui une
valeur dans un champ quelconque (autre que la clé primaire) à changé
dans


la
table source, comment faire ? la requete de non-correspondance se fonde
sur

la comparaison d'un seul champ dans les 2 tables !!
Je suis étonné que l'on puisse pas faire cela d'une façon simple sous
Access

!! ou suis-je limité moi même (c'est plus probable en toute modestie ..)
Merci tout de même pour le conseil




"Damien Mermoz" wrote in message
news:
Salut,

si j'ai bien compris : tu a une table source et une table cible. La
table


cible doit contenir toutes les données de la table source. La seule
différence c'est que ta table cible à un champ en plus.
Il faut donc que tu vérifies qu'il n'y a pas de données dans ta table
source

qui ne soient pas dans la table cible.
Pour cela Access te propose un assistant : Requete de non
correspondance.



Dans l'onglet requete de ta base tu choisis [nouveau] puis assistant
requete

de non correspondance. Ensuite tu suis l'assistant. Evidemment il te
faut


un
champ commun dans tes deux tables qui te permette de distinguer les
nouveaux

enregistrements.

Ensuite tu affiches cette requete en mode création puis tu choisis
requete



ajout; tu choisis la table cible et tu exécute la requete ainsi
modifier.


Seul les nouveaux enregistrements seront ajoutés. C'est la méthode la
plus


propre que je vois.
En espèrant que ça t'aide.

A +
Damien.












Avatar
zarbout
normalement la table source n'accepte pas les doublons et protégée en
écriture. Par ailleurs, je vais tester aussi la suite des requete que tu
propose et comparer cette solution à celle donnée par Damien.
Merci pour tes clarifications.


"Hubert Canevet" wrote in message
news:389a01c375f0$6ab714d0$
D'après ce que je comprends tu disposes d'informations
dans une table d'une base existante, qu'il vaudrait mieux
éviter de modifier. Sur les mêmes enregistrements tu
voudrais stocker des informations dans des champs
supplémentaires.

Pour ce qui est de la structure des données, je verrais
bien une table liée sur la table de GEP, et une autre
table avec le même champ clef, qui contiendra les champs
manquants.

Admettons que les tables s'appellent [tbs Actions] pour la
table liée sur la table préexistante et [tbs ConvActions]
pour la table avec les nouveaux champs (ça m'arrange parce
que j'ai déjà un exemple sous la main) et que la clef
s'appelle CodeAction. On pourra obtenir l'ensemble des
informations par la requête suivante.

SELECT DISTINCTROW [tbs ConvActions].*, [tbs
Actions].IntituleAction
FROM [tbs ConvActions] LEFT JOIN [tbs Actions] ON [tbs
ConvActions].CodeAction = [tbs Actions].CodeAction
ORDER BY [tbs Actions].IntituleAction;

Mon exemple initial avait une finalité différente, mais je
ne crois pas me mélanger trop les pinceaux.

La requête de non-correspondance indiquée par Damien
permet de localiser dans [tbs Actions] les enregistrements
non créés dans [tbs ConvActions], admettons que cette
requête s'appelle ['tbs Actions' et 'tbs ConvActions' sans
correspondance]

La requête suivante permettra de créer les enregistrements
manquants d'un coup, bien entendu seul le champ clef sera
renseigné, il faudra saisir les autres.

INSERT INTO [tbs ConvActions] SELECT CodeAction FROM ['tbs
Actions' et 'tbs ConvActions' sans correspondance]

Nous avons donc une table liée sur GEP ([tbs Actions] dans
mon exemple), donc des informations à jour, et une table
avec les champs manquants ([tbs ConvActions] dans mon
exemple).

Il reste à voir si des précautions supplémentaires sont
nécessaires pour ne pas modifier la table source. Si
l'application source donne accès en lecture seule ça
devrait être facile à gérer.

Il restera à supprimer dans [tbs ConvActions] les
enregistrements correspondants lorsque des enregistrements
sont supprimés dans [tbs Actions].

Pour cela je verrais bien une requête de non-
correspondance mais dans le sens inverse de celle utilisée
tout-à-l'heure. On pourrait l'utiliser reqASupprimer, et
une autre requête du style
DELETE FROM reqASupprimer
pourrait donner le résultat.

Attention, bien visualiser les premières fois le contenu
de reqASupprimer avant de faire la suppression, d'autant
que je n'ai pas fait de test dessus.

Concernant la notion de clef. Si la table source ne
contient pas de doublon il ne doit pas y avoir de
problème, du reste l'ordre des enregistrements est obtenu
par la clause ORDER BY. Il me semble que ça ne serait pas
spécialement une mauvaise idée que CodeAction soit une
clef dans l'autre table, ça ne mange pas de pain.

+ + +

Une remarque au sujet d'une requête Union : elle permet de
concaténer deux tables ou requêtes contenant
impérativement les mêmes champs. Si on unit une table de 5
enregistrements et une de 7, on obtiendra 12
enregistrements, sauf doublons. Si toutefois il y a un
champ en plus ou en moins dans l'une par rapport à
l'autre, on n'obtiendra rien d'autre qu'une erreur.
Avatar
Yann
SAlut

Je te conseill aller voir le cite www.statim.fr
specialiste GEP CASIMIR ......

le soft is name charlemagne vraiment super pratique pour l'inscription le
suivie les note etc ...... entierement compatile avec le rectora et GEP.....

bonne reception



"zarbout" a écrit dans le message de news:
3f59be9f$0$11288$
Bonjour,
je suis confronté à une question que je pense simple pour beaucoup d'entre
vous mais l'autodidacte que je suis peine à trouver son chemin.
Pour bien exposer mon problème, un novice comme moi risque d'être bavard.

Voilà : je travaill avec une BDD contenant table dont les données doivent
actualisées tout les jours à partir d'un fichier DBF utilisé par une autre
appli : qui est l'appli principale dans laquelle toutes les données sont
saisies (GEP pour les administratifs de l'éducation nationale). Je ne peux
pas travailler directement avec le fichier DBF car il ne prend pas de Clé
Primaire alors que j'en ai besoin dans ma BDD.
Ma table "cible" a donc la même structure que le fichier DBF "source" sauf
que l'un des champ me sert de Clé Primaire.
L'actualisation quotidienne consiste à comparer la "cible" et la "source"
et

faire en sorte que la cible contient les les mêmes enregistrements que la
source ( virer quelques enregistrements, ajouter d'autres ou modifier les
infos relatives à d'autres).
Dois-je faire 2 requetes (Suppression de tous les enregistrements de la
cible et ajout de tous les enregistrements de la "source") ce qui est
lourd

ou
faire une requete Mise à jour (que j'arrive pas à mettre en place)
ou une requete Union (que j'arrive pas à mettre enplace aussi faute de
connaitre la syntaxe) ?
Merci pour votre patience et votre aide.
zarbout








Avatar
zarbout
C'est un bon logiciel. Sauf que les concepteurs des logiciel pour
l'Education Nationale ne prennent en compte que les besoins standards
définis par service (Gestion, Vie Scolaire, Profs...). Dans la pratique, il
y a un nombre faramineux de tâches complexes et parfois inter-services dont
le support unique est la paperasserie et je peux disserter longtemps la
dessus.
Pour cette raison j'ai tenté et je tente toujours de faire appel à mes
modestes connaissances d'apprenti sorcier d'Acces pour me faciliter la vie,
mais ça reste trop artisanal. Un bon développeur en collaboration avec
quelqu'un du terrain peut créer un bel outils qui fait cruellement défaut
aujourd'hui (ça permettera d'ameliorer la rendement du personnel et
d'économiser un peu sur les deniers publics dépensés parfois pour des tâches
irrationnelles et kafkaiennes (avec le respect que je dois à mes collegues
qui se tapent du boulot ingrat et difficile).
merci pour le conseil.




"Yann" wrote in message
news:#
SAlut

Je te conseill aller voir le cite www.statim.fr
specialiste GEP CASIMIR ......

le soft is name charlemagne vraiment super pratique pour l'inscription le
suivie les note etc ...... entierement compatile avec le rectora et
GEP.....


bonne reception



"zarbout" a écrit dans le message de news:
3f59be9f$0$11288$
Bonjour,
je suis confronté à une question que je pense simple pour beaucoup
d'entre


vous mais l'autodidacte que je suis peine à trouver son chemin.
Pour bien exposer mon problème, un novice comme moi risque d'être
bavard.



Voilà : je travaill avec une BDD contenant table dont les données
doivent


actualisées tout les jours à partir d'un fichier DBF utilisé par une
autre


appli : qui est l'appli principale dans laquelle toutes les données sont
saisies (GEP pour les administratifs de l'éducation nationale). Je ne
peux


pas travailler directement avec le fichier DBF car il ne prend pas de
Clé


Primaire alors que j'en ai besoin dans ma BDD.
Ma table "cible" a donc la même structure que le fichier DBF "source"
sauf


que l'un des champ me sert de Clé Primaire.
L'actualisation quotidienne consiste à comparer la "cible" et la
"source"


et
faire en sorte que la cible contient les les mêmes enregistrements que
la


source ( virer quelques enregistrements, ajouter d'autres ou modifier
les


infos relatives à d'autres).
Dois-je faire 2 requetes (Suppression de tous les enregistrements de la
cible et ajout de tous les enregistrements de la "source") ce qui est
lourd

ou
faire une requete Mise à jour (que j'arrive pas à mettre en place)
ou une requete Union (que j'arrive pas à mettre enplace aussi faute de
connaitre la syntaxe) ?
Merci pour votre patience et votre aide.
zarbout