Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Windows Windows Serveur SQL Serveur Insert into ... values(...)

Insert into ... values(...)

5 réponses
Avatar
Tdelob
Bnjour,

J'ai des probl=E8mes lorsque j'essai d'ins=E9rer des infos ds=20
ma base, voici ma requette :

insert into carpark values
('cpname.text',...,'charges.text')

D'apr=E8s le compilateur le probl=E8me provient du dernier=20
champs : CHARGES, je l'ai d=E9clar=E9 en INT dans ma base et=20
il ne veut par consequent pas mettre du .TEXT, j'ai=20
essay=E9 de le convertir en utilisant VAL() mais toujours=20
pareil. Est ce que qqun =E0 une id=E9e ?

P.S. : Mon premier champs est un AUTO INCREMENT comment=20
l'exprimer en sql car ('', 'cpname.text'...) ne=20
fonctionne pas.=20

Merci d'avance

Tdelob
Signaler un problème avec ce contenu

5 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Avatar
Fred BROUARD
Oulala bieaucoup d'horreurs...

1) dans une requête SQL tu ne peut mettre des appels à des objets de
l'interface cliente.

2) si identity , par défaut la clause VALUES demande à ce que le colonne
auto incrémentée ne figure pas dans la requête

Donc ta requête devrait s'écrire :

'insert into carpark values (' + QuotedStr(cpname.text)
+ ', ' + ...
+ ', ' + IntToStr(charges.text) +' )'


Ceci étantr en Delphi

A +


Tdelob a écrit:
Bnjour,

J'ai des problèmes lorsque j'essai d'insérer des infos ds
ma base, voici ma requette :



> insert into carpark values
> ('cpname.text',...,'charges.text')

D'après le compilateur le problème provient du dernier
champs : CHARGES, je l'ai déclaré en INT dans ma base et
il ne veut par consequent pas mettre du .TEXT, j'ai
essayé de le convertir en utilisant VAL() mais toujours
pareil. Est ce que qqun à une idée ?

P.S. : Mon premier champs est un AUTO INCREMENT comment
l'exprimer en sql car ('', 'cpname.text'...) ne
fonctionne pas.

Merci d'avance

Tdelob



--
Frédéric BROUARD - expert SQL, spécialiste : SQL Server / Delphi / web
Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
****************** mailto: ******************
Avatar
Nicolas LETULLIER
Attention, je crois bien que tu mélanges tes différents langages
(apparemment PHP et SQL). Pense bien que l'instruction SQL que tu écris est
envoyée au serveur et interprétée à ce moment là. Si tu as donc des objets
"cpname" ou "charges", ceux-ci ne sont pas connus sur le serveur. Tu dois
donc construire ta chaine SQL en concaténant du texte brut ("INSERT
INTO...") et des variables.

Autre-chose, dans un INSERT, il vaut mieux toujours lister les champs avant
le VALUES, rien ne te garantit autrement l'ordre réel des champs au niveau
de l'implémentation physique.

Exemple (mais pas solution) :

SQL="INSERT INTO CARPARK (CHAMP_CPNAME, ... , CHAMP_CHARGES) VALUES ('" +
cpname.text + "', ... , " + charges.text + ")"

// Note les quotes qui délimitent les chaines de caractères SQL juste avant
et juste après les double-quotes qui délimitent les chaines PHP quand tu
concatènes le texte brut et les variables.

mssql_query(SQL)

Nicolas.


"Tdelob" a écrit dans le message de
news:0fc701c3a2dd$1382b0b0$
Bnjour,

J'ai des problèmes lorsque j'essai d'insérer des infos ds
ma base, voici ma requette :

insert into carpark values
('cpname.text',...,'charges.text')

D'après le compilateur le problème provient du dernier
champs : CHARGES, je l'ai déclaré en INT dans ma base et
il ne veut par consequent pas mettre du .TEXT, j'ai
essayé de le convertir en utilisant VAL() mais toujours
pareil. Est ce que qqun à une idée ?

P.S. : Mon premier champs est un AUTO INCREMENT comment
l'exprimer en sql car ('', 'cpname.text'...) ne
fonctionne pas.

Merci d'avance

Tdelob
Avatar
Fred BROUARD
Nicolas LETULLIER a écrit:

Autre-chose, dans un INSERT, il vaut mieux toujours lister les champs avant
le VALUES, rien ne te garantit autrement l'ordre réel des champs au niveau
de l'implémentation physique.



faux... en effet SQL conserve la position ordinale de la colonne lors de
la création. Ceci étant normatif...

Exemple :

CREATE TABLE T_testCol
(col1 int,
col2 int,
col3 int)

SELECT CAST(COLUMN_NAME AS VARCHAR(16)) AS COL_NAME, ORDINAL_POSITION
FROM INFORMATION_SCHEMA.COLUMNS
WHERE TABLE_NAME = 'T_testCol'

COL_NAME ORDINAL_POSITION
---------------- ----------------
col1 1
col2 2
col3 3


ALTER TABLE T_testCol ADD col4 int

SELECT CAST(COLUMN_NAME AS VARCHAR(16)) AS COL_NAME, ORDINAL_POSITION
FROM INFORMATION_SCHEMA.COLUMNS
WHERE TABLE_NAME = 'T_testCol'

COL_NAME ORDINAL_POSITION
---------------- ----------------
col1 1
col2 2
col3 3
col4 4

ALTER TABLE T_testCol DROP COLUMN col2

SELECT CAST(COLUMN_NAME AS VARCHAR(16)) AS COL_NAME, ORDINAL_POSITION
FROM INFORMATION_SCHEMA.COLUMNS
WHERE TABLE_NAME = 'T_testCol'

COL_NAME ORDINAL_POSITION
---------------- ----------------
col1 1
col3 3
col4 4


CQFD !

A +


--
Frédéric BROUARD - expert SQL, spécialiste : SQL Server / Delphi / web
Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
****************** mailto: ******************



Avatar
Nicolas LETULLIER
Décidément,

Il n'y a cependant pas que les normes qui comptent Fred, il y a aussi la
pratique. Imagine que la personne ait son MLD d'origine documenté, mais
qu'après un certain temps, un autre développeur ait, par exemple, supprimé
une colonne de type INT simple pour rajouter un INT IDENTITY (pour faire le
lien avec le post de Jean JUILLARD), celle-ci se retrouve alors en dernière
position. L'ordre des colonnes documenté est donc différent de l'ordre
physique réel, sauf très grande rigueur de l'équipe. Et dans ce cas là, les
anciennes requêtes INSERT doivent être reprises pour changer l'ordre des
colonnes.

Que faut-il donc ? Faire confiance à tous les développeurs ayant manipulé la
base de données pour que la documentation soit à jour ou bien lister les
champs explicitement ? Personnellement, j'opte pour la seconde solution,
quitte à perdre un peu de temps.

Nicolas.


"Fred BROUARD" a écrit dans le message de
news:

Nicolas LETULLIER a écrit:

> Autre-chose, dans un INSERT, il vaut mieux toujours lister les champs


avant
> le VALUES, rien ne te garantit autrement l'ordre réel des champs au


niveau
> de l'implémentation physique.

faux... en effet SQL conserve la position ordinale de la colonne lors de
la création. Ceci étant normatif...

Exemple :

CREATE TABLE T_testCol
(col1 int,
col2 int,
col3 int)

SELECT CAST(COLUMN_NAME AS VARCHAR(16)) AS COL_NAME, ORDINAL_POSITION
FROM INFORMATION_SCHEMA.COLUMNS
WHERE TABLE_NAME = 'T_testCol'

COL_NAME ORDINAL_POSITION
---------------- ----------------
col1 1
col2 2
col3 3


ALTER TABLE T_testCol ADD col4 int

SELECT CAST(COLUMN_NAME AS VARCHAR(16)) AS COL_NAME, ORDINAL_POSITION
FROM INFORMATION_SCHEMA.COLUMNS
WHERE TABLE_NAME = 'T_testCol'

COL_NAME ORDINAL_POSITION
---------------- ----------------
col1 1
col2 2
col3 3
col4 4

ALTER TABLE T_testCol DROP COLUMN col2

SELECT CAST(COLUMN_NAME AS VARCHAR(16)) AS COL_NAME, ORDINAL_POSITION
FROM INFORMATION_SCHEMA.COLUMNS
WHERE TABLE_NAME = 'T_testCol'

COL_NAME ORDINAL_POSITION
---------------- ----------------
col1 1
col3 3
col4 4


CQFD !

A +


--
Frédéric BROUARD - expert SQL, spécialiste : SQL Server / Delphi / web
Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
****************** mailto: ******************
>



Avatar
Fred BROUARD
Là je te rejoins à 100% !

L'utilisation de l'étoile dans la clause SELECT, comme la non
spécification des colonnes dans l'ordre INSERT ne devrait pas être
utilisé en développement.

A +

Nicolas LETULLIER a écrit:
Décidément,

Il n'y a cependant pas que les normes qui comptent Fred, il y a aussi la
pratique. Imagine que la personne ait son MLD d'origine documenté, mais
qu'après un certain temps, un autre développeur ait, par exemple, supprimé
une colonne de type INT simple pour rajouter un INT IDENTITY (pour faire le
lien avec le post de Jean JUILLARD), celle-ci se retrouve alors en dernière
position. L'ordre des colonnes documenté est donc différent de l'ordre
physique réel, sauf très grande rigueur de l'équipe. Et dans ce cas là, les
anciennes requêtes INSERT doivent être reprises pour changer l'ordre des
colonnes.

Que faut-il donc ? Faire confiance à tous les développeurs ayant manipulé la
base de données pour que la documentation soit à jour ou bien lister les
champs explicitement ? Personnellement, j'opte pour la seconde solution,
quitte à perdre un peu de temps.

Nicolas.


"Fred BROUARD" a écrit dans le message de
news:

Nicolas LETULLIER a écrit:


Autre-chose, dans un INSERT, il vaut mieux toujours lister les champs





avant

le VALUES, rien ne te garantit autrement l'ordre réel des champs au





niveau

de l'implémentation physique.



faux... en effet SQL conserve la position ordinale de la colonne lors de
la création. Ceci étant normatif...

Exemple :

CREATE TABLE T_testCol
(col1 int,
col2 int,
col3 int)

SELECT CAST(COLUMN_NAME AS VARCHAR(16)) AS COL_NAME, ORDINAL_POSITION
FROM INFORMATION_SCHEMA.COLUMNS
WHERE TABLE_NAME = 'T_testCol'

COL_NAME ORDINAL_POSITION
---------------- ----------------
col1 1
col2 2
col3 3


ALTER TABLE T_testCol ADD col4 int

SELECT CAST(COLUMN_NAME AS VARCHAR(16)) AS COL_NAME, ORDINAL_POSITION
FROM INFORMATION_SCHEMA.COLUMNS
WHERE TABLE_NAME = 'T_testCol'

COL_NAME ORDINAL_POSITION
---------------- ----------------
col1 1
col2 2
col3 3
col4 4

ALTER TABLE T_testCol DROP COLUMN col2

SELECT CAST(COLUMN_NAME AS VARCHAR(16)) AS COL_NAME, ORDINAL_POSITION
FROM INFORMATION_SCHEMA.COLUMNS
WHERE TABLE_NAME = 'T_testCol'

COL_NAME ORDINAL_POSITION
---------------- ----------------
col1 1
col3 3
col4 4


CQFD !

A +


--
Frédéric BROUARD - expert SQL, spécialiste : SQL Server / Delphi / web
Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
****************** mailto: ******************








--
Frédéric BROUARD - expert SQL, spécialiste : SQL Server / Delphi / web
Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
****************** mailto: ******************