Erreur de requête not in sur deux tables

[neptunia]

Bonjour a tous,

Je me permets d écrire car je n ai pas trouvé de problème similaire au miens ...
Je m explique :

J ai deux tables dans une base " assez bien utilisé par plusieurs utilisateurs " j ai une requete delete from avec une condition not in ... cependant de temps en temps sans expliquation j ai ma requête qui " ne va pas bien consulter la deuxième dépendante du not in et va donc me supprimer des donnes que je ne voudrais pas.

Exemple : delete from tablea where c_client not in (select c_client from tableb)

Parfois cette requête va supprimer des éléments de tablea qui sont bien dans tableb

La question est donc, pourquoi ... est ce que parce que tableb est occupé au moment de la requête ? Et surtout il y a t il un moyen d empêcher cela sans toucher a la requête ? Paramètre dans sql serveur ?

Merci de votre aide

[SQLpro]

A priori je pense que vous connaissez mal le langage SQL...

En effet, avec NOT IN, si la sous requête retourne des NULL, alors le prédicat vaut faux.

DEMONSTRATION...

Code :

1
2
3
4
5
CREATE TABLE T1 (C1 INT);
INSERT INTO T1 VALUES (1), (2), (3), (4);
 
CREATE TABLE T2 (C2 INT);
INSERT INTO T2 VALUES (2), (4), (6);

Code :

1
2
DELETE FROM T1
WHERE C1 NOT IN (SELECT C2 FROM T2);

Code :

1
2
3
4
5
6
SELECT * FROM T1;
 
C1
-----------
2
4

--> ce qui est le résultat que vous attendiez certainement...

Code :

1
2
3
4
5
 
DELETE FROM T1;
INSERT INTO T1 VALUES (1), (2), (3), (4);
 
INSERT INTO T2 VALUES (NULL);

Code :

1
2
3
 
DELETE FROM T1
WHERE C1 NOT IN (SELECT C2 FROM T2);

Code :

1
2
3
4
5
6
7
8
SELECT * FROM T1;
 
C1
-----------
1
2
3
4

--> ce qui est exact, mais auquel vous ne vous attendiez pas !

Bref, apprenez le SQL... Mon site web, comme mon bouquin est là pour vous aider !

A +

[neptunia]

Bonjour, et merci pour ton aide.

Je ne pense pas être une experte, mais une utilisatrice normalement expérimentée.

J'ai donc mal du m'exprimer pour exposer mon problème.

Voici donc la rêquete en question

Code :

DELETE FROM  stock_reserve  WHERE date_liv<'20111020'  AND stock_reserve.n_cde NOT IN (SELECT ent_cde.n_cde FROM ent_cde WHERE stock_reserve.n_cde=ent_cde.n_cde AND c_etat_cde='C') AND c_trf<>'O'

Ce qui se passe, de temps en temps, cette requête va mal faire son travail, et supprimer des valeurs qui sont pourtant bien présente sur

Code :

SELECT ent_cde.n_cde FROM ent_cde WHERE stock_reserve.n_cde=ent_cde.n_cde AND c_etat_cde='C'

Je me suis demandée, si ce n'était pas parce que la table ent_cde représente 140 924 lignes, et qu'elle est souvent select / update / insert
est il donc possible que ma premiere requete n'arrive pas à consulter de temps en temps ent_cde et donc .. va supprimer des éléments de stock_reserve sans vraiment attendre la fin du résultat de ent_cde

Merci encore de votre aide.

[Rei Ichido]

Envoyé par neptunia

Je me suis demandée, si ce n'était pas parce que la table ent_cde représente 140 924 lignes, et qu'elle est souvent select / update / insert
est il donc possible que ma premiere requete n'arrive pas à consulter de temps en temps ent_cde et donc .. va supprimer des éléments de stock_reserve sans vraiment attendre la fin du résultat de ent_cde

Merci encore de votre aide.

"Sans attendre", non. Par contre, il se peut qu'un autre traitement, en particulier s'il est itératif, rajoute une ligne dans ent_cde APRÈS que la suppression ait été faite.

[neptunia]

Hummm ... merci bien de ta réponse ...
Certain ? qu'aucun paramètre serveur pourrait mettre un délai timeout ?! et que du coups il n'arrive pas à lire dans un délai " normal " execute la requete sans lire la table ent_cde ... ?!

Le pire étant que ce n'est pas la seule requete avec un not in qui me fait ce genre de problème ... ='( ce qui n'est pas logique étant qu'il n'y a pas de répétition bien définie ... cela arrive de temps en temps parfois 1 fois par mois, parfois rien durant 2 mois, parfois 4 fois sur un mois ...

[Rei Ichido]

S'il y a un timeout, cela déclenchera une exception qui portera sur l'intégralité de la requête, et donc aucune suppression n'aura été effectuée.

[neptunia]

Hummm ... ok !

Bon quel serait le moyen pour " vérifier " ce qu'il se passe exactement ? Autre que lancer manuellement un profiler ... ?

[SQLpro]

Si votre sous requête :

Code :

SELECT ent_cde.n_cde FROM ent_cde WHERE stock_reserve.n_cde=ent_cde.n_cde AND c_etat_cde='C'

Renvoi un NULL dans ent_cde.n_cde
Alors NOT IN est faux, donc tout est traité.

Vérifiez que vous n'avez pas de temps à autre un ent_cde.n_cde NULL !

Remplacez le NOT IN pas un NOT EXISTS corrélé.

A +

[neptunia]

Hum Hum ...
Je ne peux modifier la requete hélas ...
Il n'est normalement pas pensable d'avoir une valeur null dans n_cde ...
mais pouvons nous avec un profiler automatique qui sauvegarde jour / jour avec un résultat des requetes ? enfin ... un moyen tout simplement de pister l'erreur ?!

Merci en tout cas de votre aide.

[Rei Ichido]

Envoyé par SQLpro

Si votre sous requête :

Code :

SELECT ent_cde.n_cde FROM ent_cde WHERE stock_reserve.n_cde=ent_cde.n_cde AND c_etat_cde='C'

Renvoi un NULL dans ent_cde.n_cde
Alors NOT IN est faux, donc tout est traité.

Vu la requête, si le NOT IN est faux, il n'y aura aucune ligne supprimée.
Or là, le problème c'est qu'il y a des lignes supprimées qui ne devraient pas l'être.

Edit : de toute façon, NULL n'est pas une valeur qui peut être retournée par cette requête ; elle sélectionne ent_cde.n_cde et il y a une condition d'égalité sur cette valeur.

[nsanabi]

Envoyé par SQLpro

Si votre sous requête :

Code :

SELECT ent_cde.n_cde FROM ent_cde WHERE stock_reserve.n_cde=ent_cde.n_cde AND c_etat_cde='C'

Renvoi un NULL dans ent_cde.n_cde
Alors NOT IN est faux, donc tout est traité.

(x not in (null)) renvoi false ??!!

[Rei Ichido]

Envoyé par nsanabi

(x not in (null)) renvoi false ??!!

Oui.
x NOT IN (null), ce n'est jamais que x <> null, dont le résultat est unknown, ce qui est finalement converti en false.
D'ailleurs, NOT (x NOT IN (null)) est aussi false.

[neptunia]

Merci de vos réponses, j'aimerai savoir cependant, si ma précédente question est possible :

mais pouvons nous avec un profiler automatique qui sauvegarde jour / jour avec un résultat des requetes ? enfin ... un moyen tout simplement de pister l'erreur ?!

Merci bien !

[Rei Ichido]

Vous pourriez mettre temporairement en place une insertion dans une table de log, avant et après votre requête ... Cela peut s'avérer consommateur (de temps CPU et de mémoire), cela dit.

Vous devriez surtout tracer les modifications sur la table stock_reserve, vu la requête le seul moyen de générer votre problème c'est qu'elle soit modifiée après le DELETE, provoquant une incohérence des données.