Requête Mise à Jour anomalie
Résolu/Fermé
cocotehier
Messages postés
12
Date d'inscription
dimanche 23 mars 2014
Statut
Membre
Dernière intervention
26 mai 2015
-
7 janv. 2015 à 11:19
cocotehier Messages postés 12 Date d'inscription dimanche 23 mars 2014 Statut Membre Dernière intervention 26 mai 2015 - 8 janv. 2015 à 18:12
cocotehier Messages postés 12 Date d'inscription dimanche 23 mars 2014 Statut Membre Dernière intervention 26 mai 2015 - 8 janv. 2015 à 18:12
A voir également:
- Requête Mise à Jour anomalie
- Mise à jour pilote - Guide
- Mise a jour airpods - Guide
- Mise a jour windows 10 - Guide
- Mise a jour xiaomi - Guide
- Mise a jour chromecast - Guide
3 réponses
Utilisateur anonyme
7 janv. 2015 à 13:38
7 janv. 2015 à 13:38
Bonjour
Comment pourrions-nous avoir une piste, sans la moindre requête ni le plus petit bout de code ? Les boules de cristal ne sont pas très efficaces dans ce domaine.
Comment pourrions-nous avoir une piste, sans la moindre requête ni le plus petit bout de code ? Les boules de cristal ne sont pas très efficaces dans ce domaine.
Utilisateur anonyme
7 janv. 2015 à 16:52
7 janv. 2015 à 16:52
La requête que tu montres correspond-elle à Ce qui est dans le référent mais pas dans l'extraction...obtient une date de sortie. , comme je crois le deviner ?
Tu as un peu désembué ma boule de cristal, mais il reste beaucoup de zones floues :
Peux-tu expliquer avec des termes précis ce que tu entends par "ce qui est dans le référent" et par "pas dans l'extraction" en donnant les noms des tables , des champs et ce que signifie "ne pas être" (valeur NULL, chaîne vide, date 0000-00-00), etc...
Quand tu dis qu'il y a effacement d'informations "sur des lignes non impactées pendant la mise à jour", veux-tu dire que des lignes qui n'apparaissent pas quand tu fais
Je ne vois pas du tout ce qui limite l'action de cette requête à des champs qui ne seraient que dans l'une des deux tables. À vue de nez, il doit manquer un "WHERE (quel champ ?) IS NULL ou quelque chose de ce style.
Tu as un peu désembué ma boule de cristal, mais il reste beaucoup de zones floues :
Peux-tu expliquer avec des termes précis ce que tu entends par "ce qui est dans le référent" et par "pas dans l'extraction" en donnant les noms des tables , des champs et ce que signifie "ne pas être" (valeur NULL, chaîne vide, date 0000-00-00), etc...
Quand tu dis qu'il y a effacement d'informations "sur des lignes non impactées pendant la mise à jour", veux-tu dire que des lignes qui n'apparaissent pas quand tu fais
SELECT DATE_OFF LEFT JOIN UTILISATEUR ON DATE_OFF.RACF = UTILISATEUR.RACFsont modifiées ? . D'ailleurs, as-tu fait ce SELECT pour t'assurer des lignes qui sont censées être impactées ?
Je ne vois pas du tout ce qui limite l'action de cette requête à des champs qui ne seraient que dans l'une des deux tables. À vue de nez, il doit manquer un "WHERE (quel champ ?) IS NULL ou quelque chose de ce style.
cocotehier
Messages postés
12
Date d'inscription
dimanche 23 mars 2014
Statut
Membre
Dernière intervention
26 mai 2015
7 janv. 2015 à 17:29
7 janv. 2015 à 17:29
Merci à nouveau,
Le référent est la table UTILISATEUR (ensemble A). C'est le référentiel des utilisateurs ils ont une date d'entrée....un jour ils auront une date de sortie. Elle contient le champ RACF et un champ vide au départ...LADATE_SORTIE qui sera donc rempli au moment (mois) opportun.
DATE_OFF est une table créé via requete de création elle liste les utilisateurs qui n'apparaissent plus dans une extraction du systéme pour un mois donné...(ensemble B) bien que présent dans l'ensemble A, elle comporte comme champs RACF commun avec la table UTILISATEUR et D_DATE qui est la date de (Dead) sortie.
La requête que je montre
SELECT....est ma requête de mise à jour du champ LADATE_SORTIE de la table UTILISATEUR pour tous les champs RACF de DATE_OFF présent donc dans UTILISATEUR et qui vise à mettre à jour avec D_DATE...la date de sortie.
Elle fonctionne (presque) bien à ceci prêt qu'elle met à jour le champ LADATE_SORTIE uniquement pour les RACF communs avec la valeur D_DATE......mais j'ai l'impression qu'elle vide les précédentes D_DATE sur des RACF non commun.....
Je pensais que la limitation était "de facto" induite par le LEFT JOIN...
Qu'en pensez vous ?
Le référent est la table UTILISATEUR (ensemble A). C'est le référentiel des utilisateurs ils ont une date d'entrée....un jour ils auront une date de sortie. Elle contient le champ RACF et un champ vide au départ...LADATE_SORTIE qui sera donc rempli au moment (mois) opportun.
DATE_OFF est une table créé via requete de création elle liste les utilisateurs qui n'apparaissent plus dans une extraction du systéme pour un mois donné...(ensemble B) bien que présent dans l'ensemble A, elle comporte comme champs RACF commun avec la table UTILISATEUR et D_DATE qui est la date de (Dead) sortie.
La requête que je montre
SELECT....est ma requête de mise à jour du champ LADATE_SORTIE de la table UTILISATEUR pour tous les champs RACF de DATE_OFF présent donc dans UTILISATEUR et qui vise à mettre à jour avec D_DATE...la date de sortie.
Elle fonctionne (presque) bien à ceci prêt qu'elle met à jour le champ LADATE_SORTIE uniquement pour les RACF communs avec la valeur D_DATE......mais j'ai l'impression qu'elle vide les précédentes D_DATE sur des RACF non commun.....
Je pensais que la limitation était "de facto" induite par le LEFT JOIN...
Qu'en pensez vous ?
Utilisateur anonyme
7 janv. 2015 à 18:06
7 janv. 2015 à 18:06
Merci pour les précisions
"La requête que je montre SELECT....est ma requête", non, c'est MA requête. La tienne était un UPDATE et je te suggérais justement de faire un SELECT pour voir quelles lignes étaient concernées par ton UPDATE. L'as-tu fait ?
Le LEFT JOIN ne limite rien du tout. Il englobe TOUTES les lignes de ta table de gauche, en fournissant les champs de la table de droite qui correspondent, ou NULL dans ces champs s'il n'y a pas de correspondance.
Tu n'as pas à faire de RIGHT ou LEFT JOIN puisque tu ne t'intéresses, si j'ai compris, qu'aux utilisateurs qui existent dans les deux tables
J'ai bien l'impression que tu voulais faire tout simplement
"La requête que je montre SELECT....est ma requête", non, c'est MA requête. La tienne était un UPDATE et je te suggérais justement de faire un SELECT pour voir quelles lignes étaient concernées par ton UPDATE. L'as-tu fait ?
Le LEFT JOIN ne limite rien du tout. Il englobe TOUTES les lignes de ta table de gauche, en fournissant les champs de la table de droite qui correspondent, ou NULL dans ces champs s'il n'y a pas de correspondance.
Tu n'as pas à faire de RIGHT ou LEFT JOIN puisque tu ne t'intéresses, si j'ai compris, qu'aux utilisateurs qui existent dans les deux tables
J'ai bien l'impression que tu voulais faire tout simplement
UPDATE DATE_OFF INNER JOIN UTILISATEUR ON DATE_OFF.RACF = UTILISATEUR.RACF SET UTILISATEUR.LADATE_SORTIE = [DATE_OFF].[D_DATE] WHERE UTILISATEUR.LADATE_SORTIE IS NULL
cocotehier
Messages postés
12
Date d'inscription
dimanche 23 mars 2014
Statut
Membre
Dernière intervention
26 mai 2015
8 janv. 2015 à 10:35
8 janv. 2015 à 10:35
Merci pour le retour et de ton aide,
Les lignes conercernées sont bien celles qui doivent l'être pas de soucis.
Je te confirme aussi pour avoir fait tourner à vide c'est à dire supprimé la date de sortie qui venait d'être mise et ajouter sur un RACF non sorti une date fictive qu'aprés relancement de la requête, la date fictive reste et n'est pas écrasée, la date de sortie réapparait au bon endroit.
En fait le sujet est résolu.... les dates de sortie ont disparues.....parce que les gens sont redevenus actifs.....changement de service.....réinitialisation oblige.
Pour autant, je voulkais te dire que tu as des erreurs de syntaxe sur les requêtes que tu proposes
cette syntaxe est bien la bonne
UPDATE DATE_OFF LEFT JOIN UTILISATEUR ON DATE_OFF.RACF = UTILISATEUR.RACF SET UTILISATEUR.LADATE_SORTIE = [DATE_OFF].[D_DATE];
Les lignes conercernées sont bien celles qui doivent l'être pas de soucis.
Je te confirme aussi pour avoir fait tourner à vide c'est à dire supprimé la date de sortie qui venait d'être mise et ajouter sur un RACF non sorti une date fictive qu'aprés relancement de la requête, la date fictive reste et n'est pas écrasée, la date de sortie réapparait au bon endroit.
En fait le sujet est résolu.... les dates de sortie ont disparues.....parce que les gens sont redevenus actifs.....changement de service.....réinitialisation oblige.
Pour autant, je voulkais te dire que tu as des erreurs de syntaxe sur les requêtes que tu proposes
cette syntaxe est bien la bonne
UPDATE DATE_OFF LEFT JOIN UTILISATEUR ON DATE_OFF.RACF = UTILISATEUR.RACF SET UTILISATEUR.LADATE_SORTIE = [DATE_OFF].[D_DATE];
La requête que je t'ai donnée est syntaxiquement correcte pour mySQL (sauf les [] autour des noms de tables et de champs). L'important n'était pas la syntaxe, mais la suppression du LEFT et l'ajout du WHERE, qui ne sont pas des changements de syntaxe mais de sémantique.
Si je comprends bien, tu me dis que la requête est toujours la même, mais que maintenant ça marche ?
Si je comprends bien, tu me dis que la requête est toujours la même, mais que maintenant ça marche ?
cocotehier
Messages postés
12
Date d'inscription
dimanche 23 mars 2014
Statut
Membre
Dernière intervention
26 mai 2015
>
Utilisateur anonyme
Modifié par cocotehier le 8/01/2015 à 18:13
Modifié par cocotehier le 8/01/2015 à 18:13
Oui le pére. Elle fonctionne parfaitement sous access 2007 ce que je ne vous avait pas spécifié....cette requête est le copié collé en mode Sql de la requête de mise à jour
Un grand Merci pour votre patience.
Je vous assure que le message erreur de syntaxe est apparu dans access 2007 le premier parlait du manque d'opérateur....ai-je mal copié coller, trés surement...
Pardon de ne pouvoir mettre à disposition cette base....elle comporte des information sensible..vous comprendrez..
Encore Merci
Un grand Merci pour votre patience.
Je vous assure que le message erreur de syntaxe est apparu dans access 2007 le premier parlait du manque d'opérateur....ai-je mal copié coller, trés surement...
Pardon de ne pouvoir mettre à disposition cette base....elle comporte des information sensible..vous comprendrez..
Encore Merci
Modifié par cocotehier le 7/01/2015 à 15:01
Est ce qu'une requête de mise à jour, dont l'unique objet est de compléter un champ vide par une information, peut malencontreusement effacer des données déja présente dans cette table sur des lignes non impactées pendant la mise à jour ?
Si votre réponse était : normallement non, alors j'aurai copié en version sql les informations.
Si la réponse etait : oui, avec vos piste je chercherai à améliorer ma requête..
Mais bon, considérant votre réponse le pére comme non...voici le code sql de ladite request
UPDATE DATE_OFF LEFT JOIN UTILISATEUR ON DATE_OFF.RACF = UTILISATEUR.RACF SET UTILISATEUR.LADATE_SORTIE = [DATE_OFF].[D_DATE];
S'il vous plait, qu'en pensez-vous ?
Merci