DELETE lignes dont la clé est dans une table et absente d'une autre

Bonjour,

Je travaille actuellement sur 2 tables dans la configuration suivante

TABLE1
CODE1 PIC 9(005) (clé primaire)
TS1 PIC X(026) (clé primaire)
Données ...

TABLE2
CODE1 PIC 9(005) (clé primaire)
TS1 PIC X(026) (clé primaire)
CPT1 PIC 9(003) (clé primaire)
Données ...

Normalement, les lignes dans TABLE2 doivent avoir leur équivalent dans TABLE1 avec le même CODE1 et le même TS1. Mais, chez mon client, il n'y a pas de contrainte d'intégrité référentielle. Du coup on trouve des lignes présentes dans TABLE2 et pas dans TABLE1 ce qui fait planter des programmes.

Je dois donc développer un programme qui supprime les lignes présentes dans TABLE2 sans équivalent dans TABLE1 mais j'ai des contraintes à respecter au niveau des requêtes DB2 :
- Pas de requête imbriquée ou sous-requête
- Pas de FETCH pour modification

J'ai donc essayé ça :
DELETE
FROM TEST.TABLE2 B
LEFT OUTER JOIN TEST.TABLE1 A
ON (A.CODE1 = B.CODE1
AND A.TS1 = B.TS1)
WHERE A.CODE1 IS NULL
;

Mais SPUFI n'a pas aimé :
SQLCODE = -199, ERROR: ILLEGAL USE OF KEYWORD LEFT. TOKEN INCLUDE
<END-OF-STATEMENT> QUERYNO WHERE SKIP WITH SET WAS EXPECTED
SQLSTATE = 42601 SQLSTATE RETURN CODE
SQLERRP = DSNHPARS SQL PROCEDURE DETECTING ERROR
SQLERRD = 2 0 0 -1 151 506 SQL DIAGNOSTIC INFORMATION
SQLERRD = X'00000002' X'00000000' X'00000000' X'FFFFFFFF'
X'00000097' X'000001FA' SQL DIAGNOSTIC INFORMATION

Alors qu'il accepte très bien :
SELECT *
FROM TEST.TABLE2 B
LEFT OUTER JOIN TEST.TABLE1 A
ON (A.CODE1 = B.CODE1
AND A.TS1 = B.TS1)
WHERE A.CODE1 IS NULL
;

Cela me retourne très bien les lignes incriminées.
Si j'avais la possibilité de faire du DELETE sur des lignes fetchées, j'aurais déjà la solution, mais c'est interdit.

Quelqu'un aurait-il une solution pour réaliser cela sans requête imbriquée et sans DELETE sur un FETCH ?

Merci d'avance ! :)

Citation:

Envoyé par Samuel_Vimaire

...
Je dois donc développer un programme qui supprime les lignes présentes dans TABLE2 sans équivalent dans TABLE1 mais j'ai des contraintes à respecter au niveau des requêtes DB2 :
- Pas de requête imbriquée ou sous-requête
- Pas de FETCH pour modification

Mon dieu ... encore un exemple de règles débiles ...

Citation:

Mais SPUFI n'a pas aimé

Normal ... la notion de jointure ne s'applique qu'au SELECT ...

Citation:

Quelqu'un aurait-il une solution pour réaliser cela sans requête imbriquée et sans DELETE sur un FETCH ?

Est ce que la récupération de la clé primaire sur un curseur puis un DELETE direct sur la clé ainsi récupérée est permis ?

Bonjour

Cette instruction devrait faire ce que tu veux :

Code:

1
2
3
4
 
delete
from test.table2 a
where not exists (select '*' from test.table1 b where b.code1=a.code1 and b.ts1=a.ts1) ;

Citation:
Envoyé par pwrdwnsys
Bonjour

Cette instruction devrait faire ce que tu veux :
Code:

1 2 3 4 delete from test.table2 a where not exists (select '*' from test.table1 b where b.code1=a.code1 and b.ts1=a.ts1) ;
Il y a une sous-requete, donc pas adapté à la demande. J'aurais bien aussi proposé........

Citation:

Envoyé par bernard59139

Il y a une sous-requete, donc pas adapté à la demande. J'aurais bien aussi proposé........

Effectivement (j'avais zappé ce postulat ridicule), mais du coup, s'il faut vraiment se plier à des règles totalement dépassées, il ne faut plus faire de SQL et il faut développer des programmes de quelques dizaines de lignes pour faire la même chose de manière moins lisible et avec probablement plus de risque de bogue...
Et du coup, en SQL, je ne vois aucune solution autre qu'une sous-requête, puisque la valeur de la clé est externe...

Je connais ce genre de règles "ridicules", souvent faites pour éviter que des personnes mettent à jour des tables avec des LOCK qui durent, qui durent.................
@ +

Bonsoir,

Je n’ai pas fait de DB2 depuis plus de 10 ans, je peux donc dire des bêtises, mais pourquoi ne pas utiliser une méthode bourrin ?

1) CREATE TABLE T3 LIKE T2 ;

2) INSERT dans T3 des lignes de T2 qui ne sont pas orphelines ;

3) DROP des index de T2 ;

4) DELETE FROM T2 ;

5) INSERT de T3 dans T2 ;

6) Création des index de T2 et Reorg de T2 ;

7) DROP TABLE T3.

Maintenant, vous direz à celui qui vous impose des contraintes stupides, que ne pas mettre en œuvre l’intégrité référentielle, c’est passible des tribunaux relationnels.

Bonjour,

L'une des premières questions à se poser pour ce genre de problème est : "quel volume dois-je traiter"
En effet la réponse sera totalement différente selon qu'il s'agit de quelques lignes ou de millions ou milliards de lignes
Bien sur il faut penser à l'évolution de ce volume, si la base est nouvelle il faut tenir compte de son taux de croissance

Dans le cas de volumes faibles (quelques lignes à quelques dizaines de lignes), le where exists évoqué plus haut est une solution simple, la restriction normative que tu évoques est curieuse, et peut peut être faire l'objet d'une dérogation.
Par contre faire un where exists avec un select * est aberrant, pour un test d'existence, il est bien préférable de faire un select constante ou select d'une colonne de petite taille, inutile de transporter toute la table :
DELETE from MATABLE
WHERE NOT EXISTS
(SELECT 1 FROM SUBQ
WHERE...)

Dans le cas de très fortes volumétries (genre épuration annuelle d'une base archive, traitement de convergence, de migration...) il est préférable de
- décharger par unload les 2 tables
- appareiller les fichiers pour éliminer les orphelins
- trier les fichiers résultants sur la clef cluster
- recharger en load replace avec les options "log no" et "statistics table all index all keycard" de facon à réorganiser la table, produire les stats et ne pas charger la log DB2 (contrairement au delete en masse)
Le temps de traitement par rapport a du delete sera divisé de façon exponentielle

D'amour mourir me font, belle Marquise, vos beaux yeux

Bonjour,

J’espère que, depuis le temps, Samuel a réglé son problème...

Citation:

Envoyé par escartefigue

faire un where exists avec un select * est aberrant

Ça peut paraître aberrant, mais ça n’a aucune incidence. En effet qu’on code :
Code:

1 2 WHERE NOT EXISTS (SELECT 1 FROM SUBQ WHERE...) ;
Ou bien :
Code:

1 2 WHERE NOT EXISTS (SELECT * FROM SUBQ WHERE...) ;
Depuis sa naissance, DB2 considère comme équivalents * ou 1 ou 2 ou ' D'amour mourir me font, belle Marquise, vos beaux yeux', dans le cas du prédicat EXISTS.

Je vous renvoie à ce qu'a écrit C. J. Date dans A Guide to DB2 en 1984 :

« Incidentally, the parenthesized subquery in an EXISTS expression does not necessarily have to involve the “SELECT *” form of SELECT; it may for example, be of the form “SELECT field-name FROM ...”. »

La doc officielle de DB2 confirme. Extrait de DB2 10 for z/OS, SQL Reference, SC19-2983 :

http://www.fsmwarden.com/developpez_...20truc...).png