Msg 4145 sur SQL SERVER 2008 R

Version imprimable

Bonjour,
Je veux parcourir ma table et supprimer les doublons.
J'ai un message d'erreur lorsque j'exécute la requête ci-dessous:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
DELETE FROM MfProd 
WHERE COLUID < ANY (SELECT COLUID
					FROM MfProd T2
					WHERE COLUID <> T2.COLUID
					AND MfProd.id = T2.id
					AND MfProd.Dates = T2.Dates
					AND MfProd.Timer Bagscan = T2.Timer Bagscan
					AND MfProd.Nom machine = T2.Nom machine
					AND MfProd.IP machine = T2.IP machine
					AND MfProd.Timer Tag = T2.Timer Tag
					AND MfProd.Tag = T2.Tag
					AND MfProd.Timer Mfdec = T2.Timer Mfdec
					AND MfProd.MfDec = T2.MfDec
					AND MfProd.Timer SendB = T2.Timer SendB
					AND MfProd.Nom du poste = T2.Nom du poste
					AND MfProd.IP du poste = T2.IP du poste
					AND MfProd.Numéro de controle = T2.Numéro de controle
					AND MfProd.Timer WsRcv = T2.Timer WsRcv
					AND MfProd.Numéro identification = T2.Numéro identification
					AND MfProd.Timer Wssho = T2.Timer Wssho
					AND MfProd.timer WsDec= T2.Timer WsDec
					AND MfProd.WsDec = T2.WsDec)

Citation:

Msg*4145, Niveau*15, État*1, Ligne*7
Expression de type non booléen spécifiée dans un contexte où une condition est attendue, près de 'Bagscan'.

J'ai essayé de résoudre mon problème en cherchant sur Google, mais j'obtiens pas le résultat que je souhaite.:cry:

Je vous remercie de votre aide

Quand tu as des objets (très mal nommés) qui contiennent des espaces, il faut les mettre entre crochets lorsque tu les utilises depuis une requête :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 DELETE FROM MfProd WHERE COLUID < ANY (SELECT COLUID FROM MfProd T2 WHERE COLUID <> T2.COLUID AND MfProd.id = T2.id AND MfProd.Dates = T2.Dates AND MfProd.[Timer Bagscan] = T2.[Timer Bagscan] AND MfProd.[Nom machine] = T2.[Nom machine] AND MfProd.[IP machine] = T2.[IP machine] AND MfProd.[Timer Tag] = T2.[Timer Tag] AND MfProd.Tag = T2.Tag AND MfProd.[Timer Mfdec] = T2.[Timer Mfdec] AND MfProd.MfDec = T2.MfDec AND MfProd.[Timer SendB] = T2.[Timer SendB] AND MfProd.[Nom du poste] = T2.[Nom du poste] AND MfProd.[IP du poste] = T2.[IP du poste] AND MfProd.[Numéro de controle] = T2.[Numéro de controle] AND MfProd.[Timer WsRcv] = T2.[Timer WsRcv] AND MfProd.[Numéro identification] = T2.[Numéro identification] AND MfProd.[Timer Wssho] = T2.[Timer Wssho] AND MfProd.[timer WsDec]= T2.[Timer WsDec] AND MfProd.WsDec = T2.WsDec )
En règle générale, en programmation :
- On n'utilise pas d'espace pour nommer les objets (variables, tables, champs, etc.)
- On n'utilise que le jeu de caractères US ASCII 7 bits (donc sans accents ou autres caractères étendus)
- On évite d'utiliser la casse pour différentier des objets

Ceci afin (dans l'ordre) :
- De rendre le code plus lisible (regarde tous les crochets comme c'est beau maintenant ;))
- De rendre le code lisible par le plus grand nombre, y compris des étrangers (que faire si demain ton appli est utilisée et maintenue à l'étranger ?)
- D'éviter de troubler les personnes qui vont faire la maintenance avec des mots à priori identiques mais orthographiés différement (surtout quand il s'agit d'une majuscule qui change !)

Donc avant d'aller plus loin, je te conseille fortement de revoir le nom de tes tables et champs pour virer les espaces et les accents (SQL n'est pas CS, dont les majuscules on s'en cogne ;))

08/09/2011, 15h35
nathantahiti

Grand merci StringBuilder, problème résolu simplement, la honte opour moi:oops:.
08/09/2011, 16h00
iberserk

Citation:

SQL n'est pas CS, dont les majuscules on s'en cogne

Décidément... SQL SERVER n'a rien à voir la dedans c'est la COLLATION qui détermine cela!
12/09/2011, 15h42
StringBuilder
Citation:

Envoyé par iberserk

Décidément... SQL SERVER n'a rien à voir la dedans c'est la COLLATION qui détermine cela!

Décidément... oui, c'est vraiment le cas de le dire...

Je ne parle pas de SQL Server, mais du langagne SQL.

SQL n'est pas CS.

Les données qu'il manipule peuvent l'être.

Mais si tu crées une table "toto" de la façon suivante :
Code:

1 2 create table toto (id int primary key, name varchar(20) not null);
Rien ne t'empêche d'utiliser cette requête :
Code:

1 2 select NAME from Toto where iD = 1;
LE LANGAGE SQL N'EST PAS CS.
12/09/2011, 16h25
iberserk
Citation:

Décidément... oui, c'est vraiment le cas de le dire...

Je ne parle pas de SQL Server, mais du langagne SQL.

SQL n'est pas CS.

Les données qu'il manipule peuvent l'être.

Mais si tu crées une table "toto" de la façon suivante :

Vous pourriez au moins vérifier vos affirmations:
Code:

1 2 3 CREATE DATABASE TEST ON PRIMARY ( NAME = N'TEST', FILENAME = N'D:\MSSQL10.MSSQLSERVER\MSSQL\DATA\TEST.mdf' , SIZE = 4096KB , MAXSIZE = UNLIMITED, FILEGROWTH = 1024KB ) COLLATE FRENCH_BIN
Puis:
Code:

1 2 3 4 5 6 USE TEST GO CREATE TABLE dbo.TEST ( TEST_ID integer NOT NULL )
Et enfin voyez si 'SQL' n'est pas CS:

Code:

SELECT * FROM TEST.dbo.test

Résultat:
Code:

1 2 Msg*208, Niveau*16, État*1, Ligne*1 Nom d'objet 'test' non valide.
13/09/2011, 02h19
Waldar

Vous avez tous les deux raisons : le langage SQL est insensible à la casse, mais cela ne concerne que les mots réservés, SELECT, UPDATE, FROM, AND, OR...

Dès qu'on arrive sur les noms d'objets, ce sont bien les paramétrages des bases de données qui définissent ou non la sensibilité à la casse.
13/09/2011, 07h37
iberserk

Citation:

Vous avez tous les deux raisons : le langage SQL est insensible à la casse, mais cela ne concerne que les mots réservés, SELECT, UPDATE, FROM, AND, OR...

Dès qu'on arrive sur les noms d'objets, ce sont bien les paramétrages des bases de données qui définissent ou non la sensibilité à la casse.

Sans vouloir pinailler (quoique...)

Citation:

SELECT NAME FROM Toto WHERE iD = 1;

Il était bien question ici de nom d'objet...
13/09/2011, 12h22
Waldar

Tout-à-fait, StringBuilder avait raison sur le fond mais tort sur l'exemple !
13/09/2011, 13h06
iberserk

Citation:

Tout-à-fait, StringBuilder avait raison sur le fond mais tort sur l'exemple !

Citation:

Donc avant d'aller plus loin, je te conseille fortement de revoir le nom de tes tables et champs pour virer les espaces et les accents (SQL n'est pas CS, dont les majuscules on s'en cogne )

A?
Je ne peux laisser nathantahiti croire celà:ccool: