Discussion :

[Dosco10]

Bonsoir j'utilise cette requete " UPDATE table SET nom_colonne_1 = 'nouvelle valeur' WHERE IN (plusieurs idendifiants ici voir 1000) " pour inserer une date. mais le probleme est que toutes les lignes ne sont pas affectées et j'aimerais savoir lesquelles pour pouvoir s'il le faut faire manuellement pour ce qui n'a pas marché ou identifier le probleme pour reprendre la requete

cordialement

[vanagreg]

Bonjour,

Qu'entends tu par "ce qui n'a pas marché"? Soit l'update finit correctement, soit il plante et aucune ligne n'est mise à jour.

[Dosco10]

Bonjour,

Qu'entends tu par "ce qui n'a pas marché"? Soit l'update finit correctement, soit il plante et aucune ligne n'est mise à jour.

bonjour quand vous faites une requete qui doit affecter 1000 lignes et que mysql vous dit 900 lignes on été affectées ca veut dire il y'a 100 ligne qui n'ont pas mache (un peu terre à terre) sinon j'aurais dû dire 100 lignes non affectés

[Paraffine]

Pour reprendre l'exemple où tu t'attends à 1000 lignes modifiées et que tu en obtiens seulement 900 ;
cela peut se produire lorsque 100 lignes avaient déjà la valeur que tu voulais affecter (MySQL / MariaDB)
ou lorsque tu t'es trompé sur le nombre de lignes qui devaient être affectées (comment le détermines-tu? le nombre de valeurs pour ton "WHERE IN" ?),
ou lorsque tu t'es trompé en rédigeant ta requête Update (erreurs sur les valeurs dans "WHERE IN").

Si tu n'es pas sûr de ta requête UPDATE, fais d'abord une requête SELECT (pour vérifier que tes critères sont justes).
Tu peux aussi vérifier a posteriori que tu obtiens bien le nombre "final" juste d'enregistrements pour les valeurs mises à jour (ou qu'il ne reste plus de valeurs à modifier); si tu fais un SELECT avec le même critère, les dates sont-elles renseignées ?

Quand je travaille sous MariaDB avec Workbench sur une requête Update, il m'indique à la fois le nombre de lignes affectées (= dont les valeurs ont effectivement changé) et le nombre de lignes correspondant au critère ("matched"), dont celles qui n'ont pas eu besoin de mise à jour.

[escartefigue]

Il faut également tenir compte du fait qu'on est rarement seul sur une base de données relationnelles.
Si vous faites dans un premier temps un comptage pour analyser le nombre de lignes à modifier puis une requête de mise à jour, le nombre de lignes effectivement modifié ne sera identique que si vous êtes le seul utilisateur connecté sur la base de données ou que vous avez utilisé un niveau d'isolation suffisamment restrictif pour interdire toute mise à jour par un tiers entre le comptage et la modification.

[Dosco10]

Cela se produit lorsque ces 100 lignes avaient déjà la valeur que tu voulais affecter,
ou lorsque tu t'es trompé sur le nombre de lignes qui devaient être affectées (comment le détermines-tu?),
ou lorsque tu t'es trompé en rédigeant ta requête Update (erreur sur les identifiants).

Si tu n'es pas sûr de ta requête UPDATE, fais d'abord une requête SELECT (pour vérifier que tes critères sont justes).
Tu peux aussi vérifier a posteriori que tu obtiens bien le nombre "final" juste d'enregistrements pour les valeurs mises à jour (ou qu'il ne reste plus de valeurs à modifier); si tu fais un SELECT avec le même critère, les dates sont-elles renseignées ?

Quand je travaille sous MariaDB avec Workbench sur une requête Update, il m'indique à la fois le nombre de lignes affectées (= dont les valeurs ont effectivement changé) et le nombre de lignes correspondant au critère ("matched"), qui avaient déjà les bonnes valeurs.

le probleme est qu'il peut y avoir des lignes mals renseingnées compte tenu du nombre c'est tres difficile de verifier celà donc j'aimerais avoir une folle idées qui me permettra d'identifier ces echecs

[Paraffine]

Bonjour Dosco_10,

Et si tu faisais une requête SELECT pour identifier tes enregistrements sans date (colonne date à NULL)?
Cela ne te permettrais pas de corriger ?

[Dosco10]

le probleme est qu'il peut y avoir des lignes mal renseignées vu le nombre c'est pour cà je demande s'il y'a moyen d'identifier ces lignes lorsque le resultats s'affiche et je crois que l'idée de parafine avec un "SELECT" n'est pas mauvaise pour mieux comprendre. mais les identifier automatiquement serai idéale c'est bien cà le rôle des outils non?!

[escartefigue]

Vous n'avez pas répondu sur le fait d'être le seul utilisateur ou pas sur la BDD ni sur le niveau d'isolation utilisé pour votre transaction (ma question du 21-11 à 12h01).
Qu'en est il ?
Faire une requête select ou autre pour identifier les lignes candidates à la mise à jour ne sert à rien si la base est modifiée par d'autres utilisateurs !

[Dosco10]

je suis le seul

[escartefigue]

En ce cas le critère de filtrage appliqué sur un SELECT puis sur un UPDATE doit affecter exactement le même nombre de lignes, il n'y a pas d'exception !

[Paraffine]

@Dosco10 ; j'ai l'impression que tu voudrais la liste de tes valeurs dans la clause "WHERE IN " pour lesquelles tu n'as pas de mise à jour?
Mais l'outil ne peut te fournir d'information que sur les données qui sont en base.
D'où viennent ces identifiants de ta clause "WHERE IN" ; car j'imagine que tu n'en saisis pas 1000 à la main ?
Il faudrait qu'ils soient stockés dans une autre table, pour faire une requête de non correspondance.

Accessoirement, sur quel système de gestion de base de données travailles-tu ?

[escartefigue]

Merci de communiquer le script CREATE TABLE et un extrait du contenu montrant quelques lignes satisfaisant la recherche et quelques lignes ne la satisfaisant pas. Ca nous aidera à sortir de la théorie pour passer à la pratique

[Waldar]

cela peut se produire lorsque 100 lignes avaient déjà la valeur que tu voulais affecter

Attention ceci est extrêmement faux et confusant.
On a tout à fait le droit de mettre une valeur à jour par sa même valeur et le système se plie à l'ordre envoyé et indiquera bien qu'il a mis à jour une ligne.

[aieeeuuuuu]

bonjour,

Sous MySQL, si une ligne matche mais que la valeur de remplacement est la même que la valeur d'origine, alors le moteur ne comptera pas la ligne dans les lignes affectées (==> 0 row affected)
En revanche, elle sera prise en compte pour les lignes répondant aux critères de restriction (1 row matched)

[Waldar]

Oh... Et bien au temps pour moi alors.
Rassure-moi, s'il y a un déclencheur AFTER UPDATE s'exécute-t-il ?

[Paraffine]

@Waldar j'ai modifié mon message pour préciser que cela s'applique, comme le dit aieeeuuuuu, aux bases MySQL - ainsi que MariaDB -, au grand dam de mes utilisateurs, d'ailleurs.

Dans mes procédures stockées, ROW_COUNT retourne le nombre d'enregistrements "affected" et non "matched" - je n'ai pas trouvé comment modifier ce comportement.
Selon les outils utilisés, on peut récupérer le nombre d'enregistrements "matched", "affected", ou les deux.
Bien sûr, si la base en question est Oracle ou DB2, le problème ne se pose pas, mais vu la question, j'ai comme un doute.

Pour la question du AFTER_UPDATE, il semble que OUI , cf. ce fil

[Dosco10]

bonjour, je crois qu'il est nécessaire d'expliquer avec d'amples détails l'affaire ;

je travail sous mysql et la base de donnée ce n'est pas moi qui l'ai conçu et actuellement le travail est tellement pénible pour nous à cause de la quantité j'ai décidé de rentrer certaines informations directement dans la base et en masse, alors comment cela se passe?
j'ai demandé à celui qui gère les dossiers au lieu de perdre le temps et marquer la date de traitement (pour des centaines de dossiers je précise) manuellement qu'il établisse une liste de ces dossiers dans un fichier excel au fur à mesure pour que je fasse cela avec une requête. mais sachez que ces dossiers sont créés dans la base a leur arrivé après on valide les étapes du dossier au fur à mesure donc pour marquer les dates il faut que je retrouve précisément le dossier dans base. Or le problème est que ceux qui saisissent la liste des dossiers à mettre à jour peuvent commettre des erreurs de saisie et vous savez que mysql ne tolère pas les erreurs voilà comment les numéros des dossiers se présentes "0000 /0000" imaginez qu'il y est un chiffre faux ou un espace mal placé entre slash et les numéros et c'est l'échec assurée de cette pour cette ligne. Et il y'en à tellement que vérifier manuellement devient aussitôt un calvaire.

normalement cette explication doit pouvoir répondre à tout le monde mais je reviens sur certaines questions.

pour paraffine : oui c'est la liste de celles qui n'ont pas été mise à jour et ces informations sont déjà dans la base de donnée dans une table mais il peut y avoir une erreur de saisi et qu'elle cette requête de correspondance ? cà pourrais m'aider.je bosse sur mysql

pour escartefigue : je n'ai pas le script pour la table ce n'est pas moi qui l'ai conçu mais je essayer de la trouver

[Paraffine]

Bonjour Dosco10,

Une requête de "non-correspondance" entre une table A et une table B qui ont une clé commune (ici=ton identifiant de dossier) sert à repérer par exemple les enregistrements de B qui sont absents de A.

Si A représente la table des dossiers, il faut avoir la liste des identifiants de dossier à mettre à jour dans une table B (celle de la clause WHERE IN) et faire un SELECT des enregistrements de B qu'on ne trouve pas dans A. Dans d'autres systèmes de base de données, on utiliserait l'opérateur MINUS, mais il n'est pas disponible pour MySQL : donc il faut passer par un LEFT JOIN ou une condition NOT EXISTS.

Par exemple, pour une clé qui s'appellerait NUM_DOSSIER, cela donnerait avec NOT EXISTS;

Code :

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

SELECT B.* FROM B  WHERE NOT EXISTS (select 1 from A WHERE A.NUM_DOSSIER = B.NUM_DOSSIER) ;

Cela fonctionne aussi avec une condition "NOT IN", mais "NOT EXISTS" est plus performant, et LEFT JOIN peut l'être encore plus (selon les volumétries relatives de A et B, le taux de non correspondance, les autres critères...).

Donc on privilégie :

Code :

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

SELECT B.* FROM B LEFT JOIN A ON A.NUM_DOSSIER = B.NUM_DOSSIER  WHERE A.NUM_DOSSIER IS NULL ;