Problèmes avec Turkish SQL Collation (turc "I")

J'ai des problèmes avec notre database MSSQL définie à l'une des collations turques. Étant donné le problème du "Turc I", aucune de nos requêtes contenant un "i" ne fonctionne correctement. Par exemple, si nous avons une table appelée "Unit" avec une colonne "UnitID" définie dans ce cas, la requête "select unitid from unit" ne fonctionne plus car le minuscule "i" dans "id" diffère de la capitale définie Je dans "UnitID". Le message d'erreur indiquerait "Nom de colonne invalide 'unitid'."

Je sais que cela se produit parce qu'en turc, la lettre i et moi sont considérées comme des lettres différentes. Cependant, je ne suis pas sûr de savoir comment résoudre ce problème? Ce n'est pas une option pour parcourir tous les 1900 SP dans la DB et corriger le boîtier des "i".

Toute aide serait appréciée, même des suggestions d'autres collations qui pourraient être utilisées à la place du turc mais soutiendraient leur jeu de caractères.

Il s'avère que la meilleure solution était en fait de refactoriser tous les SQL et le code.

Au cours des derniers jours, j'ai écrit une application de refactoring pour corriger tous les procés stockés, les fonctions, les vues, les noms de arrays pour être cohérent et utiliser le bon boîtier, par exemple:

select unitid from dbo.unit

serait changé en

 select UnitId from dbo.Unit

L'application passe ensuite par le code et remplace toutes les occurrences du proc stocké et de ses parameters et les corrige pour correspondre au cas défini dans le DB. Toutes datatables de l'application sont définies sur des parameters régionaux invariants (grâce à FXCop pour indiquer toutes datatables), cela évite que les appels du code soient sensibles à la casse.

Si quelqu'un voudrait l'application ou des conseils sur le process, vous pouvez me contacter sur [email protected].

Peut-être que je ne comprends pas le problème ici, mais n'est-ce pas plus probable parce que la database est sensible à la casse et votre requête ne l'est pas? Par exemple, sur Sybase, je peux faire ce qui suit:

 USE master GO EXEC sp_server_info 16 GO

Ce qui me dit que ma database est insensible à la casse:

 atsortingbute_id atsortingbute_name atsortingbute_value 16 IDENTIFIER_CASE MIXED

Si vous pouvez modifier le classment que vous utilisez, essayez l'environnement local Invariant. Mais assurez-vous que vous n'avez pas d'impact sur d'autres choses comme les noms et adresses des clients. Si un client a l'habitude d'être insensible à la casse en cherchant son propre nom, il ne l'aimera pas si ı et je cesse d'être équivalent, ou si and et stop cessent d'être équivalents.

Pouvez-vous changer le classment de la database par défaut: cela laissera toutes vos colonnes de text avec le colllation turc?

Les requêtes fonctionneront mais datatables se comporteront correctement. En théorie…

Il y a quelques getchas avec des tables temporaires et des variables de table avec des colonnes varchar: vous devrez append des clauses COLLATE à celles-ci

Je me rends count que vous ne voulez pas passer par toutes les procédures stockées pour résoudre le problème, mais peut-être que vous seriez d'accord pour utiliser un outil de refactorisation pour résoudre le problème. Je dis jeter un oeil à SQL Refactor . Je ne l'ai pas utilisé mais j'ai l'air prometteur.

J'ai développé tellement de systèmes avec le soutien de la Turquie et c'est un problème bien connu comme vous l'avez dit.

Meilleure pratique pour modifier vos parameters de database en UTF-8, et c'est tout. Cela devrait résoudre tous les problèmes.

Vous pouvez rencontrer des problèmes si vous souhaitez prendre en charge la sensibilité à la casse dans (ı-I, i-İ) qui peut être problématique à prendre en charge dans SQL Server. Si toute l'input provient du Web, assurez-vous que UTF-8 est aussi bien.

Si vous conservez votre input Web UTF-8 et les parameters SQL Server comme UTF-8, tout devrait se passer sans problème.

Changer les parameters régionaux de votre machine en anglais (US) sauve complètement la journée!