Discussion :

[galactica1]

Bonsoir chers tous

j'ai un p'tit souci j'arrive pas a concaténer deux champs de type string sur sql server 2008
quelqu'un pourrait-il m'aider
je vous laisse mon code

Code :

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

select matricule,nom +'  '+prenom AS noms from ETUDIANT

[Invité]

Avec autant d'indices, je vais sortir ma boule de cristal...
Message d'erreur, s'il y en a un... En tout cas, une idée du résultat pourrait aider.
Types des champs ?
Est-ce que l'un des deux est NULL ?
Et y a pas de type string en sql server, jusqu'à nouvel ordre

[StringBuilder]

Déjà, si on veut quel chose de lisible et sémantiquement correct, on ne concatène pas en faisant des + mais en utilisant la fonction CONCAT.

Car si demain tu veux concaténer 2 + '5' tu auras 7 au lieu de '25'...

[galactica1]

Avec autant d'indices, je vais sortir ma boule de cristal...
Message d'erreur, s'il y en a un... En tout cas, une idée du résultat pourrait aider.
Types des champs ?
Est-ce que l'un des deux est NULL ?
Et y a pas de type string en sql server, jusqu'à nouvel ordre

il n'y a pas de message d'erreur. En résultat je n'est pas la concaténation du nom et du prénom,seul le nom s'affiche. Pour résoudre ce problème j'ai utilisé la fonction RTRIM

[SQLpro]

C'est normal, si vos colonnes (et non"champs" qui est pour laespaysans) sont de type CHAR, les blancs seront conservés.

A +

[StringBuilder]

Accessoirement, mise à part pour quelques cas précis où le nombre de caractères est à la fois petit et figé, le type CHAR() est à considérer comme déprécié.
C'est un résidu des bases fichier, et n'a aujourd'hui plus vraiment de raison d'être… Même les performances, qui autrefois était largement meilleures avec ce type, sont discutables en raison de la place perdue (aussi bien sur le disque qu'en mémoire).

Grossomodo, CHAR n'est à utiliser qu'avec des colonnes types genre "classification ABC" ou éventuellement segmentation comptable (quand on utilise des numéros de comptes de taille fixe).

Pour stocker des noms et prénoms, c'est une hérésie, et comme votre cas en témoigne, ça apporte bien plus de problèmes qu'autrechose !

[SQLpro]

Accessoirement, mise à part pour quelques cas précis où le nombre de caractères est à la fois petit et figé, le type CHAR() est à considérer comme déprécié.
C'est un résidu des bases fichier, et n'a aujourd'hui plus vraiment de raison d'être… Même les performances, qui autrefois était largement meilleures avec ce type, sont discutables en raison de la place perdue (aussi bien sur le disque qu'en mémoire).

Grossomodo, CHAR n'est à utiliser qu'avec des colonnes types genre "classification ABC" ou éventuellement segmentation comptable (quand on utilise des numéros de comptes de taille fixe).

Pour stocker des noms et prénoms, c'est une hérésie, et comme votre cas en témoigne, ça apporte bien plus de problèmes qu'autrechose !

Pas du tout d'accord.

En effet,...

• l'usage systématique de colonnes de type VARCHAR conduit immanquablement à de la fragmentation et des lectures très contre performantes parce que faites en "zig-zag".
• de plus le VARCHAR nécessite 2 octets de plus que le CHAR pour stocker les mêmes informations.
• même sans fragmentation, la recherche est moins efficace que dans un char.
• pour couronner le tout, lors de certaines opérations internes (GROUPAGE, DISTINCT, ORDER BY) il faut aligner les VARCHAR pour éviter des lectures en drapeau ce qui pose des problèmes de performances !

Je ne cesse de montrer dans mes audits ce genre d'horreur qu'est l'utilisation imbécile et systématique du VARCHAR...

A +

[galactica1]

Accessoirement, mise à part pour quelques cas précis où le nombre de caractères est à la fois petit et figé, le type CHAR() est à considérer comme déprécié.
C'est un résidu des bases fichier, et n'a aujourd'hui plus vraiment de raison d'être… Même les performances, qui autrefois était largement meilleures avec ce type, sont discutables en raison de la place perdue (aussi bien sur le disque qu'en mémoire).

Grossomodo, CHAR n'est à utiliser qu'avec des colonnes types genre "classification ABC" ou éventuellement segmentation comptable (quand on utilise des numéros de comptes de taille fixe).

Pour stocker des noms et prénoms, c'est une hérésie, et comme votre cas en témoigne, ça apporte bien plus de problèmes qu'autrechose !

bon j'ai utilisé le type VARCHAR mais désormais je ferai NVARCHAR