Discussion :

[DiverSIG]

Bonjour,

J'ai besoin d'un oeil neuf pour comprendre pourquoi ma requête INSERT ne fonctionne pas:

Je crée ma table :

Code :

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

1
2
3
4
5
6
7
8
CREATE TABLE JUR (
	jur_code			VARCHAR(5)		PRIMARY KEY,
	jur_code_father		VARCHAR(5)		,
	jur_label_eng		VARCHAR(50)		NOT NULL,
	jur_label_fre		VARCHAR(50)		,
	jur_comment			VARCHAR(2000)	,
	CONSTRAINT fk_jur_code_father FOREIGN KEY(jur_code_father) REFERENCES JUR(jur_code)
);

Ma requête INSERT:

Code :

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

1
2
3
4
INSERT INTO JUR (jur_code, jur_code_father, jur_label_eng, jur_label_fre, jur_comment)
VALUES
("A", null, "Maritime zone", "Zone maritime", "Classification established in the Law Of The Sea : Internal Waters, Territorial Sea, Contiguous Zone, Exclusive Economic Zone, Continental Shelf, High Seas & Deep Ocean Floor")
;

Erreur :

Code :

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

1
2
3
4
5
6
7
8
9
NOTICE:  l'identifiant « Classification established in the Law Of The Sea : Internal Waters, Territorial Sea, Contiguous Zone, Exclusive Economic Zone, Continental Shelf, High Seas & Deep Ocean Floor » sera tronqué en « Classification established in the Law Of The Sea : Internal Wat »
 
ERROR:  la colonne « A » n'existe pas
LINE 3: ("A", null, "Maritime zone", "Zone maritime", "Classificatio...
         ^ 
 
ERREUR:  la colonne « A » n'existe pas
SQL state: 42703
Character: 96

Où est l'os?

Merci,

Nico

[tatayo]

Bonjour,
I faut utiliser des simples quotes (') comme délimiteur de chaîne, et non des doubles quotes.

Tatayo.

[DiverSIG]

Merci,

Nico

[Obsidian]

Merci,

Nico

En complément de réponse, histoire d'éclaircir le message d'erreur cryptique, le délimiteur de chaîne en SQL est bien '. Il est d'ailleurs possible d'écrire '' au sein d'une chaîne pour y insérer une vraie apostrophe sans avoir à effectuer trop de contorsions. Elle sera bien reconnue comme telle ici et pas comme la fin d'une chaîne immédiatement suivie par le début d'une autre.

Le guillemet " permet de décrire des identifiants quand ceux-ci contiennent des caractères spéciaux, c'est pourquoi le contenu de tes "…" est considéré comme un nom de colonne (à évaluer) et pas comme une chaîne littérale.

Il convient de souligner que — contrairement à d'autres SGBD — PostGreSQL est très respectueux de la norme et échoue donc là où il y a lieu de le faire. C'est pourquoi on se retrouve face à ce genre de chose quand on a pris de mauvaises habitudes sur d'autres plateformes et c'est une bonne chose en soi.

[escartefigue]

On peut noter également que définir une primary key sur une colonne de type varchar est souvent un mauvais choix : le contenu des colonnes char ou varchar est rarement stable, car souvent signifiant. Or une PK doit avoir un contenu stable (asémantique), car elle se propage dans les tables filles au travers des foreign key. De plus, le char/varchar est beaucoup plus encombrant à nombre de valeurs égal. Aussi, le char/varchar est sensible à la collation. Enfin, du varchar très court comme varchar(5) ne présente aucun intérêt, pour ce type de longueurs, le char fixe est préférable.