Est-ce que qq saurait modifier des valeurs dans 2 tables différentes ayant les mêmes champs.
Table1
(Nom, Prenom, adresse)
Table2
(Nom, Prenom, adresse)
 
Update Table1
set adresse= rue x
where nom=durand
 
je voudrai que les deux fichiers soient modifiés.
Merci  

il me semble qu'un update ne peut se rapporter qu'a à une table et une seule à la fois

y aurait pas un moyen?

faire 2 requêtes  

tout dépends certainement du SGBD.
 
avec SQL Server ou Oracle, tu peux faire ça sans problème.
 
Syntaxe MSSQL :
 
UPDATE A INNER JOIN B ON A.F1=B.F1 SET A.X = 1, B.Y = 2 WHERE A.Z =10
 
Syntaxe Oracle (tourne aussi sous MSSQL) :
 
UPDATE A, B SET A.X = 1, B.Y = 2 WHERE A.F1=B.F1
AND A.Z =10

j'aurai appris qqch, merci  

bon, maintenant me me grouille d'aller au taff, ça fait 1 heure que je devrait être en train de mettre en application mon savoir

Qq aurait-il une autre syntaxe possible car apparemment cette syntaxe ne passe sous AS400?
Merci qd même.  

AS400, c'est le serveur. La base de données est à priori un vieux DB2.
 
Fait deux requêtes, DB2 est très merdique au niveau du support SQL standard, alors on ne parle pas des ajouts de la norme SQL 92...

En fait je suis en stage et c'est justement ce qu'on me demande, je dois effectuer ces update en même temps, c'est un problème de synchronisation, si les deux requêtes ne sont pas effectuée en même temps, deux enregistrements pourrait être ajoutés dans une table et ne serait pas modifié dans les 2.
 
Je redemande donc à une âme charitable si il n'y pas d'autres syntaxes possibles.

Concentre-toi sur les transactions et les LOCK de table.
 
Normalement, avec simplement une transaction ça devrait le faire, mais pour être certain, je te conseille de faire manuellement un LOCK sur les deux tables en plus.

Si c'est pas trop en demander comment on fait ?

Pour le lock, je sais plus.
 
Pour les transactions :
 
begin trans;
update t1 ...;
update t2 ...;
commit;
 
à la place du "commit;" tu peux faire un "rollback;", qui va annuler tout ce qui a été fait depuis le "begin trans;", seulement pour ta session (ça n'altère pas les actions des autres personnes).
 
Normalement, sur un vri SGBD, une transaction porte sur une vue statique des données, c'est à dire que si une personne en // crée/met à jour/supprime des lignes, elle tu ne veras pas les modifs. De plus, tant que t'as pas commité ou rollbacké, les autres utilisateurs ne peuvent pas accéder aux lignes que tu as modifié, mise à part sous certains SGBD, tels qu'Oracle, qui leur permet de voir les lignes dans l'étant avant leur modification.

Mais pour les lock et les transactions, leur syntaxe est assez similaire d'un SGBD à l'autre, par contre, leur fonctionnement peut énormément varier d'un SGBD à l'autre, notamment en ce qui concerne l'inter-action avec les autres sessions.

Et un up de la mort
 
Quand je fais ça sous Oracle j'ai une erreur (mot clé SET absent), il s'attend à avoir le SET après le nom de la première table
C'est dommage je ne voudrai pas être obligé de passer par une procédure stockée.
Y'a pas un paramétrage ou un autre truc à faire pour que ça passe ?

chais pas. quelle version d'Oracle ?

Avec la 8i ça marche (je pourrai re-vérifier demain)

avec la 9i

bah ça devrait marcher...

Je vais devoir faire autrement, c'est dommage ça me plaisait bien et ce n'était pas long à mettre en oeuvre

Attends, que demain je teste, il y a peut-être un petit problème dans la requête. Faut juste que j'aie un Oracle sous la main pour tester, et c'est pas le cas actuellement

En effet, ça passe pas sous Oracle 9i.
Et je trouve pas d'exemple dans Google qui montreraient qu'on puisse le faire, au contraire :
 
http://www.experts-exchange.com/Da [...] 25051.html
 

 
Confirmé ici aussi:
 
http://dbforums.com/archive/49/2002/04/3/354364

Etrange, parceque je suis certain d'avoir réussi une fois à faire un truc comme ça.

Avec SQL Server apparemment c'est ok, donc tu confonds peut-être ?

Bon bein merci à tous, en fait ce n'était pas vraiment pour faire l'update de 2 tables mais pour un truc du genre :
 

 
Mais comme de toutes façons il faut SET juste après le nom de la première table c'est mort.
Allez zou j'vais coder tout ça

update table1 set table1 = (select table2.champ where not table1.champ2 is null and table1.champ1 = table2.champ1)
 
Normalement, ça doit marcher par contre

oui et non. C'est en cherchant pour SQL Server que j'étais tombé sur une syntaxe pour Oracle. De souvenir, ça avait marché. Mais impossible de me souvenir...

Nan marche pas non plus

bon, déjà, quand ça marche pas, dit quelle est l'erreur, parceque cette syntaxe ne peut QUE marcher, à moins que la sous-requête retourne des doublons normalement, ou que certaines lignes ne participent pas à la jointure (à ce moment, il faut ajouter quasiement la même sous-requête dans ma clause WHERE du update.

update table1 set table1.champ1 = (select table2.champ where table1.champ2 is not null and table1.champ1 = table2.champ1)

arf, vi, problèmes en recopitant depuis ma tête

pour le NOT, je suis pas d'accord :
 
"where not table1.champ2 is null" = where table1.champ2 is not null"

je sais bien mais c'est plus lisible

ouais mais moi j'ai copité c'est koi qui était écrit dans le post du monsieur moi d'abors

oh yaisssssse ça marche
Je ne pensais pas que dans une sous requete on pouvait se passer du FROM
 

J'avais même pas vu qu'il manquait ça
 
update table1 set table1.champ1 = (select table2.champ from table2 where table1.champ2 is not null and table1.champ1 = table2.champ1)
 
C'est plus lisible quand même

arf, mon non plus j'avais pas vu

De plus je ne savais pas qu'on pouvait, dans une sous requête, faire référence dans la clause WHERE à une table non explicitée dans le FROM mais définie dans la requête principale
 
C'est fou ça non

ben si, ça c'est justement tout l'intérêt des sous-requêtes : être capable d'inter-agir avec la requête principale.

C'est con ça fait 5 ans que je code du SQL et j'étais toujours emmerdé quand je devais faire ce type d'opérations.
 
Bon oserais-je poser une question plus compliquée (je pense)
Cette fois c'est plus pour la culture personnelle sur la manière dont Oracle analyse les requêtes
Donc ne vous prenez pas la tête dessus, j'ai un jour essayé cette requête, elle prend un temps énorme bien qu'il n'y ait qu'un miliers d'enregistrements dans la base
 

 
Alors que d'exécuter  
 

 
Puis d'exécuter
 

 
Est d'une vitesse normale.
 
Ce qui signifie qu'Oracle ne commence pas par exécuter la sous-requête puis réinjecter le résultat dans la requête principale. Du coup il doit y avoir moyen de l'optimiser, mais là je ne sais plus comment puisque ma logique de calcul d'Oracle n'est pas pareil que la mienne