Utilisation d'un fichier de langue [Résolu]

[sovo]

Bonjour a tous

Voila ce que je veux faire : j'ai des procédures stocke (près de 150) contenant des messages (erreur et information). les messages sont tous en anglais, et mon application étant passe en multilingue, je voudrais que les messages des procédures stockées suivent aussi.

Pour cela j'ai pense a un fichier de langue (.ini) que je vais charger et récupérer le message pour afficher.

Mais voila je ne sais pas comment m'y prendre, et je ne sais même pas si c'est possible.

Alors je viens vers vous, pour vous pour voir avoir une idée pour la résolution de mon problème.

Merci

[elsuket]

Bonjour,

Ne mettez pas cela dans un fichier, vous n'y gagnerez rien.

Créez plutôt quelques tables :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
CREATE TABLE tb_language
(
	language_id tinyint NOT NULL IDENTITY CONSTRAINT PKtb_language PRIMARY KEY
	, language_name varchar(32) NOT NULL
)
GO
 
CREATE TABLE tb_message
(
	message_id int NOT NULL CONSTRAINT PKtb_message
	, niveau tinyint NOT NULL
	, ...
)
GO
 
CREATE TABLE tb_error_message_translation
(
	error_message_translation_id int NOT NULL IDENTITY CONSTRAINT PKtb_error_message_translation PRIMARY KEY
	, message_id int NOT NULL CONSTRAINT FKtb_error_message_translation__message_id FOREIGN KEY (message_id) REFERENCES dbo.tb_message
	, language_id tinyint NOT NULL CONSTRAINT FKtb_error_message_translation__language_id FOREIGN KEY (language_id) REFERENCES dbo.tb_language
	, translation varchar(1024) NOT NULL
)
GO
 
ALTER	TABLE tb_error_message_translation
ADD	CONSTRAINT UQtb_error_message_translation__message_id__language_id
	UNIQUE (message_id, language_id)
GO

A vous ensuite d'écrire la procédure stockée qui gérera l'ajout de nouveaux messages et leur traduction, ainsi que celle qui vous retourne les traduction en fonction du message et de la langue.
Malheureusement il va falloir vous repalucher les procédures stockées ...

Sachez que vous pouvez en exporter le code dans un seul fichier en suivant ce billet :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
SELECT		M.definition + CHAR(10) + CHAR(13) + 'GO' AS code_proc 
INTO		##PROC
FROM		sys.procedures AS P
INNER JOIN	sys.sql_modules AS M ON M.object_id = P.object_id 
WHERE		P.name NOT LIKE 'dt%' 
AND		P.name NOT LIKE 'sp%' 
 
DECLARE	@bcp varchar(256); 
SET	@bcp = 'bcp "SELECT code_proc FROM ##PROC" queryout C:\Procs.sql -T -c'; 
EXEC	master.dbo.xp_cmdshell @bcp; 
 
DROP TABLE ##PROC;

[sovo]

merci elsuket pour avoir repondu a ma question

lorsque tu dis :

Envoyé par elsuket

Ne mettez pas cela dans un fichier, vous n'y gagnerez rien.

comment je ne gagnerais rien ?? plus lent ?? pas possible ?
si j'ai pense a ca; c'est parceque c'est le système que je maitrise le mieux.


Je trouve intéressante, l'idée de passer par les tables, j'y avais pas pense.


aussi est que je pourrais résoudre les messages qui ont des traitement, un peut comme celui-ci dessous ??

Code :

SET @Msg='Error While Creating Account '+ Convert(Varchar,@CpteJumelle)

[elsuket]

comment je ne gagnerais rien ?? plus lent ?? pas possible ?

Hé si, puisque SQL Server n'est pas un système de gestion de fichiers, mais bien un système de gestion de bases de données relationnelles.
Donc vous vous compliquerez un peu moins la vie en tentant d'accéder aux données.

Par exemple, si vous ajoutez une traduction dans la base de donnés, elle prend effet tout de suite et sans que vous ayez besoin de recharger le fichier dans une application ou par une procédure stockée d'assembly ...

En termes d'intégrité aussi, puisque tout le monde ne pourra pas accéder à ces données comme c'est possible avec un fichier.
Vous pouvez filtrer qui voit quoi
Dans un SGF, vous avez accès à tout ou à rien, peu importe que ce soit en lecture ou en écriture.

si j'ai pense a ca; c'est parceque c'est le système que je maitrise le mieux.

Je vous comprend mais vous faites fausse route.
Si cela vous semble plus complexe au premier abord, gardez à l'esprit que vous en faites côté bases de données (autant le moteur de bases de données lui-même que les outils d'ETL), plus robuste sera votre application.

SQLPro a écrit un très bon article là-dessus; je vous invite à le lire.

aussi est que je pourrais résoudre les messages qui ont des traitement, un peut comme celui-ci dessous ??

Rien ne vous empêche de mettre un paramètre fictif dans votre chaîne, comme @var@ et de le remplacer au moment de lever l'erreur par un REPLACE().

Sachez que vous pouvez passer des paramètres à RAISERROR :

Code :

1
2
DECLARE @message varchar(64) = 'Un petit test de RAISERROR'
RAISERROR('Erreur : %s', 16, 1, @message)

Lèvera une exception dont le message sera : Erreur : Un petit test de RAISERROR

@++

[sovo]

Merci pour les conseils.

J'ai résolu mon probleme