Discussion :

[Sebounet19]

Bonjour,

j'utilise à l'heure actuelle un framework propriétaire Java de requetage sur une base de données. Ce framework a été optimisé pour Oracle. Récemment, nous commençons à utiliser ce framework pour se connecter à des bases SQL Server. Mais là, j'ai une question sur les DELETE

Code :

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

delete from maTable t0 where t0.idTable=1;

Cette instruction me renvoit l'erreur suivante :

[Microsoft][SQLServer 2000 Driver for JDBC][SQLServer]Ligne 1 : syntaxe incorrecte vers 't0'.

Est-ce qu'il ne faut absolument pas utiliser d'alias dans un DELETE :

Merci d'avance

[Fabien Celaia]

Du moment que vous n'utilisez qu'une table, ou est l'intérêt ? Dans ce cas effectivement, le T-SQL réagit comme cité.

[Sebounet19]

C'est simplement le principe du framework. Une table a toujours un alias. Peu importe où elle se trouve.

J'imagine du coup que pour le update, c'est la même punition ...

Cependant, comment réaliser ce genre de requête sans ambiguïté

Code :

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

1
2
DELETE FROM table1
WHERE id in (select id from table2 where cle_etr = cle_etr);

avec cle_etr venant de table1 et cle_etr venant de table2 (le même nom quoi ...)

Ca peut devenir vite foulli ...

[Fabien Celaia]

En utilisant quelque chose de bien simple que seul le T-SQL sait faire

Code :

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

1
2
3
4
5
 
DELETE table1 T1
FROM table2 T2 
WHERE T1.id = T2.id 
AND T1.cle_etr = T2cle_etr

[SQLpro]

Votre framework a été élaboré par un bidouilleur qui ne connais pas le langage SQL. SQL est un langage normalisé et il est bien précisé que les tables cibles des ordres de mise à jour (INSERT, DELETE, UPDATE) ne peuvent en aucun cas être aliassées. En effet il ne doit y avoir aucune ambiguité sur la table à impacter, c'est pourquoi il est interdit d'utiliser un alias.

Ce n'est pas parce que certains SGBDR font n'importe quoi en la matière (Oracle en particulier) qu'il faut les prendre pour modèle !

SQL Server respecte assez bien la norme SQL. Oracle ne la respecte que très peu !

A +

[Fabien Celaia]

Ce n'est pas parce que certains SGBDR font n'importe quoi en la matière (Oracle en particulier) qu'il faut les prendre pour modèle !

SQL Server respecte assez bien la norme SQL. Oracle ne la respecte que très peu !

A +

SQLPro, te serait-il possible d'expliciter un peu ? cette affirmation me semble quelque peu obsolète en rapport avec les versions actuelles de ces SGBDR.

[SQLpro]

je comprends pas bien ce que tu veut dire ...

exemple sous MS SQL Server :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
CREATE TABLE T_TEST_UPDATE 
(COL1 INT)
GO
 
INSERT INTO T_TEST_UPDATE VALUES (33)
GO
 
1 ligne(s) affectée(s))
 
UPDATE T_TEST_UPDATE T
SET    T.COL1 = 44
 
Serveur : Msg 170, Niveau 15, État 1, Ligne 2
Ligne 2 : syntaxe incorrecte vers 'T'.
 
 
UPDATE T_TEST_UPDATE
SET    COL1 = 44
 
(1 ligne(s) affectée(s))
 
UPDATE T_TEST_UPDATE
SET    COL1 = (SELECT T.COL1 
               FROM T_TEST_UPDATE T)
 
(1 ligne(s) affectée(s))

A +