Discussion :

[hayassinet]

bonjour,

J'utilise Sql Server Express 2012, le separateur décimal par defaut est le point, que je voudrais le changer en "," (virgule).
Les parametres regionaux du système est en français.

donc quand je crée une table
exemple :

create TABLE T_Test (
Champs_1 real
)
quand j'execute insert into T_Test values (2,5) ne fonctionne. pour cela fonctione je dois inserer 2.5.

Ma question: comment changer le separateur décimal pour enregistrer des decimaux avec virgules.

Merci de vos réposes.

Cordialement.

[joujousagem2006]

Vous pouvez insérer le en décimal
puis en affichage tu fait un cast associé a une simple replace

Code :

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

1
2
3
4
5
6
7
create TABLE T_Test (
Champs_1 real
)
 
insert into T_Test values (2.5)
 
select replace(cast(Champs_1 as varchar(10)),'.',',') from T_Test

[hayassinet]

Merci pour ta réponse,
mon objectif n'est pas de détourner le souci via sql.

Je cherche comment changer le separateur décimal dans Sql server, c'est a dire quuand je crée une table avec un champs de type réel, le separateur décimal sera virgule.

Cordialement

[SQLpro]

Je pense que vous n'avez rien compris aux bases de données. Vous confondez avec un tableur !
Dans une base, les données sont stockées de manière binaire et aucun paramétrage d'aucune sorte ne s'occupe de format, notion qui n'existe dans aucun SGBDR !
C'est aux application cliente de s'occuper de la cosmétique...

A +

[hayassinet]

Tout simplement je ne cherche pas l'impossible.

Sur Sql serveur dans certains serveur :
insert into Table values (2.5) fonctionne
et sur d'autres
insert into Table values (2,5) fonctionne
cela dépend du separateur décimal,

Je ne voudrais pas faire des replace dans la requete d'insertion.

Quelqu'un peut m'expliquer comment sql server choisi son separateur décimal ?

Cordialement.

[StringBuilder]

Euh...

J'aimerais voir un exemple où :

Code sql :

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

1
2
 
insert into matable (val) values (2,5);

Peut marcher...

Car c'est TOUT BONNEMENT IMPOSSIBLE !

En effet, comment interpréter la requête suivante ?

Code sql :

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

1
2
 
insert into matable (val1, val2) values (2,5,7);

Ça, oui, mais c'est à vomir, car fonctionne ou plante en fonction de la culture de votre contexte applicatif :

Code sql :

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

1
2
 
insert into matable (val) values ('2,5');

Le LANGAGE SQL utilise une cultre AMERICAINE pour la notation des nombres.
C'est invariant, vous n'avez en aucun cas la possibilité de le modifier sans réécrire le parseur SQL (et accessoirement, en déviant totalement de la norme).

Les données sont ensuite stockées dans leur format binaire natif.

Ensuite, comme dit SQLpro, c'est à votre programme client de mettre en forme les nombres pour l'affichage ou l'injection dans SQL.

A noter que :
- Si vous utilisez des requêtes paramétrées, vous n'avez pas à formatter les données, il suffit de les envoyer à SQL dans leur format natif, le bind des paramètres s'occupe de tout
- Si vous faire de l’insertion de masse à partir d'un fichier formaté (CSV par exemple) avec des nombres dans un format particulier, alors il existe BLUKLOADER qui permet d'indiquer un format de nombre (et donc un délimiteur) afin de décoder convenablement les données du CSV avant de les injecter dans le moteur SQL.

[hayassinet]

Merci pour tes explications,

Voici un exemple

Code :

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

1
2
3
4
5
6
7
8
Create MaTab_1 ( champs_Chaines Varchar(20) )
 
insert into Matab_1 ('2,5')
insert into MaTab_1 ('2.5')
insert into Matab_1 ('1,6')
insert into MaTab_1 ('1.6')
 
Create MaTab_2 ( champs_Décimal Decimal (4,2) )

Req 1 : se plante

Code :

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

1
2
3
4
insert into MaTab_2
select *
from MaTab_1
where champs_Chaines in ('2,5', '1,6')

Req 2: s'exécute avec succès

Code :

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

1
2
3
4
insert into MaTab_2
select *
from MaTab_1
where champs_Chaines in ('2.5', '1.6')

en fait selon le métier les nombres saisis avec point sont faux alors il ne faut garder que les nombres dont le séparateur décimal est la virgule.
Les valeurs sont saisies sur une application mobile dont on applique aucun contrôle, les données arrivent dans des fichiers CSV qu'on intègre dans des tables ODS ( dans l’exemple Matab_1).


J'espère que c'est clair.

Cordialement.

[StringBuilder]

Donc on est bien dans le cas (à vomir) où on enregistre dans une colonne numérique une chaîne de caractères.

Ceci n'est absolument pas performant, et peut, suite à un changement inopiné d'une configuration en dehors de SQL Server, se mettre subitement à ne plus fonctionner.

En effet, la représentation en chaînes de caractères se fait en fonction de la culture du logiciel client.
Cette culture est déterminée, selon les outils utilisés par le logiciel :
- Soit une culture arbitraire, choisie par le client
- Soit la culture de l'ordinateur CLIENT
- Soit par la culture du SERVER

Il suffit donc qu'un même script SQL qui est lancé sur un PC avec SQLCMD soit lancé par une personne qui a choisi "fr-fr" ou "en-US" comme locale, et un coup ça marche, un coup ça marche pas.

Il ne faut JAMAIS travailler avec des représentations localisées des nombres, toujours avec le nombre lui-même.
=> '2,5' doit être traduit en SQL par 2.5 (et surtout pas '2.5')

Il ne faut pas chercher à faire autrement.

[SQLpro]

Voici un exemple

Create MaTab_1 ( champs_Chaines Varchar(20) )

insert into Matab_1 ('2,5')
....

Nous revenons à la remarque de départ.. Vous n'avez pas compris ce qu'était un SGBDR, que vous voulez utiliser comme un tableur.
Insérer des données pseudo numérique sous forme de chaine en espérant contrôler un format c'est parfaitement débile.
Soit vous vous débarrassez de SQL Server et utilisez un tableau EXCEL soit vous utilisez un SGBDR pour ce qu'il fait le mieux. Dans un SGBDR un nombre est un nombre et pas une chaine de caractère !

A +