Discussion :

[Samuel_Vimaire]

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 !

[Luc Orient]

...
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 ...

Mais SPUFI n'a pas aimé

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

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 ?

[pwrdwnsys]

Bonjour

Cette instruction devrait faire ce que tu veux :

Code :

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

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) ;

[bernard59139]

Bonjour

Cette instruction devrait faire ce que tu veux :

Code :

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

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é........

[pwrdwnsys]

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...

[bernard59139]

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.................
@ +