Discussion :

[Sagittaire]

Bonjour,

J'aurais voulu avoir votre avis sur un problème précis. Je suis l'utilisateur (donc pas DBA) d'une base. Celle-ci est déclinée dans un environnement de Production, Test et Développement. La base est compossée d'un ensemble de Tables avec des colonnes notamment en varchar. Certaines Tables sont mises à jour régulièrement par des batchs lancé automatiquement par JOBSCHEDULER. J'ai donc un fichier d'alimentation de la Table, un fichier .fmt décrivant ce fichier et une procstoc en base pour le chargement de la Table.

Depuis une mise à niveau récente de cette base en Test et Développement, le chargement d'une colonne en varchar est complétée systématiquement par des blancs.
Exemple : une colonne X varchar(5)
si dans mon fichier j'ai 'TITI', dans ma base j'aurais 'TITI ', donc avec un blanc en fin de zone.

Je n'ai pas ce problème avec ma base en Production, les zones en varchar s'arrêtent après le dernier caractère et ne sont pas complétées par des blancs.

Il n'y a pas de SET ANSI_PADDING d'utilisé dans les différents environnements...

Ce phénomène est présent pour toutes les colonnes en varchar de toutes les tables chargées à batch. Pas de souci quand on insert une ligne manuellement dans une Table...

J'aurais voulu savoir si quelqu'un parmi vous avait déjà été confronté à ce type de comportement d'une zone varchar ?

Merci d'avance pour vos idées

PS : J'espère être dans la bonne section...

[Edit]
Voici par exemple une table posant pb :

Code :

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

1
2
3
4
5
6
7
8
9
10
CREATE TABLE [CODIERS] (
	[COD_ID] [char] (5) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL ,
	[COD_LIBELLE] [varchar] (50) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
	[COD_MULTISEL] [char] (1) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
	CONSTRAINT [PK_CODIERS] PRIMARY KEY  CLUSTERED 
	(
		[COD_ID]
	) WITH  FILLFACTOR = 90  ON [PRIMARY] 
) ON [PRIMARY]
GO

Et voici le fichier servant à alimenter cette table :

Code :

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

1
2
3
4
 
FORMJForme Juridique                                   N
PCIALPosition Commerciale                              N
SADONSuite à donner                                    N

Voici aussi l'extrait de la procstoc chargeant cette table :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
-- Codiers
SET @ls_NomTable = 'Codiers'
SET @ls_DataFile = @is_DataPath + '\' + @ls_NomTable + '.TXT'
SET @ls_FmtFile  = @is_FmtPath  + '\' + @ls_NomTable + '.FMT'
SET @ls_SqlRequete = N'BULK INSERT d02.' + @ls_NomTable + N' FROM ''' + @ls_DataFile + N''' WITH (FORMATFILE=''' + @ls_FmtFile + N''' , MAXERRORS=1, CHECK_CONSTRAINTS)'
PRINT '  Lancement Chargement table '+  @ls_NomTable + ' le ' + convert(char(19), getdate(), 120)
EXEC sp_executesql @ls_SqlRequete
IF @@ERROR = 0
   BEGIN
   PRINT '  ' + @ls_NomTable + left(replicate('.',30),25-len(@ls_NomTable)) + 'OK'+ ' le :' + convert(char(19), getdate(), 120)
   END
ELSE
   BEGIN
   PRINT '  ' + @ls_NomTable + left(replicate('.',30),25-len(@ls_NomTable)) + 'KO le : ' + convert(char(19), getdate(), 120)
   GOTO ERREUR
   END

Après le chargement, la colonne COD_LIBELLE contient les valeurs avec les blancs...

Concernant la version, ce que me donne SQL Query Analyser :
SQL 8.00.194

SGBD : SQL Server 2000

[sillycoder]

C'est effectivement étrange car le type varchar s'adapte en fonction de la chaîne et la stocke en fonction de sa taille. Le comportement que tu décris est pourtant typique du type char qui code une chaîne avec une taille fixe.

Par exemple TITI donne 'TITI ' en char(5) mais 'TITI' en varchar(5).
Tout comme TO donne 'TO ' en char(5) et 'TO' en varchar(5).
Es-tu certain que le type des champs en question n'est pas plutôt char avec ta base de test ou production ?

[al1_24]

Le problème se situe sans doute au niveau des procédures de chargement des fichiers.
En précisant le SGBD que vous utilisez et sa version, les réponses proposées seront adaptées aux spécificités et limitations de celui-ci.
Conseils à lire avant de poster sur ce forum

[Sagittaire]

Le problème se situe sans doute au niveau des procédures de chargement des fichiers.
En précisant le SGBD que vous utilisez et sa version, les réponses proposées seront adaptées aux spécificités et limitations de celui-ci.
Conseils à lire avant de poster sur ce forum

J'ai mis à jour mon premier post avec un exemple et je vais lire plus en détail le lien afin d'être le plus exhaustif possible par rapport à mon problème

[Sagittaire]

C'est effectivement étrange car le type varchar s'adapte en fonction de la chaîne et la stocke en fonction de sa taille. Le comportement que tu décris est pourtant typique du type char qui code une chaîne avec une taille fixe.

Par exemple TITI donne 'TITI ' en char(5) mais 'TITI' en varchar(5).
Tout comme TO donne 'TO ' en char(5) et 'TO' en varchar(5).
Es-tu certain que le type des champs en question n'est pas plutôt char avec ta base de test ou production ?

C'est étonnant en effet car c'est un comportement de char et non de varchar mais les colonnes sont bien en varchar...

[al1_24]

Concernant la version, ce que me donne SQL Query Analyser :
SQL 8.00.194

C'est intéressant en effet.
Mais de quel SGBD s'agit-il ?

[Sagittaire]

Je croyais l'avoir indiqué, à tord

SGBD : SQL Server 2000 sous Windows 2000 Advanced Server
S'il faut plus d'info sur la version, il faudra me dire comment trouver l'info

Rajout dans le post 1 de l'extrait de la procstoc de chargement. La procstoc servant au chargement de toutes les tables, j'ai extrait uniquement la partie concernant la Table donnée en exemple...

[Sagittaire]

Pb résolu... En fait il manquait bien le SET ANSI_PADDING OFF lors de la création des tables.

Si cela peut servir à d'autre