Bonjour,
 
J'ai un comportement complètement erratique sur une base SQL server, je suis curieuse de savoir si vous avez déjà rencontré ça.
 
J'ai une table, avec un champ char(2) que j'essaie de requêter :  
 

ça me renvoie la valeur 'T ' (avec un espace après le T).
 
Normal, me direz-vous, c'est un char(2) donc il me renvoie 2 caractères.
 
Mais quand je fais :

Là, ça me renvoie 'T' sans espace    
 
 
Mais ça n'est pas fini !

>> Pas d'espace non plus    
 

>> Pas d'espace, ni dans phonetype_id, ni dans test    
 
 
Sachant que j'ai de vieilles copies de cette base, où ça me renvoie 'T' sans espace dans tous les cas...
Mais évidemment, c'est uniquement sur cette table, parce que sur d'autres champs char(2) d'autres tables, ça me renvoie bien 2 caractères.
 
J'ai l'impression d'être entrée dans une dimension parallèle

Colonne NOT NULL ou NULL ?
Pas de paramètre particuliers (ANSI_PADDING et cie) selon les cas ?
Tu es sûre que tu as bien juste un seul caractère dans ta colonne (comment tu fais pour sortir les résultats pour bien mettre en évidence le ou les blancs ?) et pas que parfois l'espace serait à gauche à ton insu ou un truc comme ça, qui du coup fait qu'il n'y en a pas à droite ?
Possible d'avoir un exemple complet pour reproduire le cas ?
 
Perso je ne m'amuse jamais avec les trucs à largeur fixe, trop de problèmes à gérer par la suite

NULL.
 

Ah bon sang de bois, le ANSI padding status !    
Effectivement, il est à false sur ce champ alors que sur mes autres champs il est à true. Je ne savais pas qu'on pouvais le mettre pour une colonne spécifiquement, je pensais que c'était une option globale de la base  
 
Ceci dit, cela n'explique pas pourquoi il y a un cas où il me le renvoie avec le padding quand même    
Ni pourquoi ça ne fait pas ça dans mes vieilles bases...    
 

Au départ, je m'en suis rendue compte en débuggant mon appli .Net qui utilise EntityFramework pour accéder à la bdd. Je voyait bien "T" et "T " dans les variables du debugger, mais je soupçonnais un bug d'EF donc je suis passée directement sur SSMS.
En copiant/collant les résultats de SSMS dans Notepad++ pour voir tous les caractères, il n'y a pas de doute permis.
 

Malheureusement je n'ai pas la main sur cette base, qui est un progiciel fourni par un tiers, je ne fais que requêter dessus.
 
Et les trucs à largeur fixe, c'est peut-être le moins moche dans cette base. Imaginez plusieurs centaines de tables, et pas une seule clé étrangère  

Honnêtement je ne sais pas t'expliquer pourquoi le comportement diffère selon la requête, je ne suis pas DBA.
Ce genre de lecture peut peut être aider à y voir plus clair : https://sqlstudies.com/2017/06/15/t [...] -shouldnt/
Je comprend bien que tu ne maitrises pas le schéma et je prêche peut être déjà une convaincue, mais c'est le genre de bizarreries et de contraintes qui me font fuir les champs à taille fixe. Pour moi ces types sont un archaïsme du début des SGBDR, qu'on est venu enrichir après avec ces bidouilles optionnelles de padding.
Je préfère un bon vieux VARmachin partout où je stocke du texte ou du binaire.
Après encore une fois je ne suis pas DBA .

Ok, je voulais juste être sûr que c'est pas un souci de lecture ambigüe. Perso quand je fais ce genre de chose je viens encadrer le champ avec des guillemets, apostrophes ou ce que tu veux lors du SELECT comme ça si il y a un machin inattendu autour de la valeur significative il ressort.

J'ai pas besoin d'imaginer, le client pour lequel j'interviens actuellement en a une tout pareil. Sur lequel ils gèrent en plus un schéma dynamique à coups de concaténation de bouts de requêtes en procédural (un nouveau type de bidule à stocker -> une table qui apparait par magie) .

C'est ce que j'ai essayé de faire (cf. ma dernière requête), mais ça ne donne pas le même résultat, c'est un truc de ouf.  
 
Enfin bref, j'ai ajouté un trim côté C# pour avoir toujours la même chose quoi que me renvoie SQL Server, et puis c'est marre    
 
Mais c'est quand même hyper mystérieux, comme comportement    
 

 
Y'a des gens qu'on ne devrait jamais laisser s'approcher d'une base de données