2010-01-05 7 views
2

J'ai un problème que j'essaie de résoudre. Nous avons un SQL Server 2005 exécutant un système ERP commercial. L'implication pour cela est que nous ne pouvons pas changer la structure de la base de données et que tous les champs de caractères sont CHAR ou VARCHAR plutôt que des types Unicode (NCHAR, NVARCHAR).SQL Server 2005 CodePage Problème

Nous avons également plusieurs instances du logiciel ERP, en fonction du pays. Chaque pays possède sa propre base de données sur le même serveur de base de données, ce qui entraîne des variations dans les noms de tables en fonction de l'instance du logiciel ERP en cours d'exécution. Par exemple, la table client US s'appelle US_CUSTOMER et celle du Royaume-Uni est GB_CUSTOMER. Nous avons créé une base de données distincte qui reflète essentiellement les tables système ERP avec des synonymes, puis les vues qui gèrent toutes nos transactions SQL par rapport à ces synonymes. Cela a été fait pour utiliser LINQ TO SQL. Merci d'avoir lu jusqu'ici :)

Le problème que nous avons est que nous sommes en train de mettre en œuvre le chinois simplifié pour l'application. Dans le système ERP client, ils définissent la page de codes pour le système ERP de sorte que lorsque le système ERP écrit dans les tables de base, les données sont écrites en multi-octets. Ma question est comment puis-je obtenir cette information multi-octets traduit en chinois simplifié? Je voudrais pouvoir le faire au niveau de la base de données, puisque j'ai une application Web et des rapports SSRS qui doivent en tirer profit.

Des idées ou des instructions? Je ne pense pas que je puisse changer la page de codes, puisque plusieurs pays utilisent le même serveur de base de données (bien que différentes bases de données).

Merci à l'avance

Répondre

0

Ce que nous avons fini par faire pour cela en train d'écrire une fonction CLR qui peut être appelé à partir de notre instruction SQL. Nous passons dans la chaîne et la page de code désirée et obtenons une chaîne convertie retournée. La performance n'est pas ce que nous espérions, mais elle semblait être le seul chemin que nous pouvions trouver.

1

disons-nous que 2 caractères varchar sont utilisent pour stocker 1 caractère unicode?

Si oui, essayez de CAST en binaire à nvarchar etc (ou quelque chose de similaire)

Sinon, regardez les clauses COLLATE pour forcer les données?

Edit:

Une fonction CLR pourrait être votre seul pari d'utiliser la suggestion de Remus MultiByteToWideChar

+0

Oui, deux caractères varchar pour stocker 1 caractère Unicode. –

+1

cast Je ne pense pas que ça va marcher. Il va lancer chaque octet individuel dans l'ensemble multi-octets à son équivalent unicode. La traduction correcte est en passant par 'MultiByteToWideChar' http://msdn.microsoft.com/en-us/library/cc500362.aspx et je ne pense pas que cette fonctionnalité est disponible en tant que T-SQL –

+0

@Remus: c'était un long shot de toute façon ,,, – gbn