Quels problèmes faut-il anticiper pour avoir différents classements entre les serveurs SQL de développement et de production?

Question

Sous-interrogation "Unable to update sys.columns - any other approach?" mentionne vaguement les problèmes de déploiement sur le serveur avec un classement différent. Le problème est que, par défaut, le classement SQL Server est déterminé (lors de l'installation) par Windows Options régionales et linguistiques -> Avancé -> "Sélectionnez une langue pour correspondre à la version linguistique du programme non-Unicode que vous voulez utilisez "dans le Panneau de configuration. Par conséquent, cette différence dans les classements entre les serveurs SQL de développement et de production/client est assez fréquente.
Par exemple, mais juste par exemple, j'ai le classement Cyrillic_General_CI_AS qui vient de Windows sur mon serveur SQL local et j'ai des clients ayant des serveurs avec un classement en hébreu. Ainsi, quels problèmes/problèmes le développeur devrait-il anticiper devoir développer avec un classement et, éventuellement, ne sachant même pas quel est le classement du client/client sur SQL Server?

Mise à jour:

Disons que cette situation typique est que je ne développe pas la base de données à partir de zéro ou installer la production SQL Server au client. La situation typique est que je me connecte/déploie à SQL Server sur un serveur partagé ou dédié et/ou reçois une sauvegarde de la base de données.

Update2:
@ u07ch,
ma machine dev est en cours d'exécution sur en-us Windows XP Pro SP3 (anglais) et en-us SQL Server (en anglais).
Plz Voir ma question d'où vient le classement par défaut de SQL Server ("Sélectionnez une langue pour correspondre à la version linguistique du programme non-Unicode que vous voulez utiliser").

Je ne pouvais pas comprendre comment on "n'utilise jamais de tables temporaires ou de toute autre chose qui utilise TEMPd".
TempDB est utilisé pour la plupart des opérations dans SQL Server, même pour stocker les résultats intermédiaires des sélections.

@Damien_The_Unbeliever,
Je ne pense pas que CS_AS est maladroit. A MON HUMBLE AVIS. c'est CI-AI qui est gênant.

Si au scénario (à la main ou par SSMS) alors je bosse inévitablement contre Collations are scripted either for all columns or for none

Update3:
Ma question dit explicitement, et mes mises à jour réitèrent, que je ne pas utiliser des collations cyrilliques (ou même pages de codes) de toute façon, mais mon SQL Server et bases de données ont Cyrillic_General_CI_AS comme collation par défaut en raison de la configuration par défaut de SQL Server liée aux dépendances sur la configuration de Windows.
La logique sous ceci est, BTW, difficile à expliquer ou comprendre mais c'est simplement le statu quo dans les configurations de SQL Server ...
Mais le résultat est que cette dépendance assure pratiquement différents classements (par défaut) de serveurs SQL dans différents pays . Quelle est l'essence de cette question ...

Answer 1

Si vos clients ne disposent pas déjà d'un serveur SQL en hébreu et que vous effectuez l'installation à partir de zéro, le classement SQL Server est configurable par le DBA lors de l'installation en sélectionnant l'option d'installation personnalisée; vous arrivez finalement à un onglet de concepteur de collation en 2005/8. S'il est trop tard pour cela, alors si vous n'utilisez jamais de tables temporaires ou quoi que ce soit qui utilise TEMPdb, ou si vous êtes tous unicode ou si vous avez la logique SQL qui rejette tous les classements en cours d'exécution, je pense que vous n'aura pas besoin de s'inquiéter à ce sujet. En supposant que ce ne soit pas le cas (comme dans nos bases de données), vous devrez exécuter la base de données dans le classement local sur le serveur SQL afin d'éviter les conflits de classement. Pour ce faire, vous devez sortir le script SQL avec les paramètres de classement et l'exécuter dans le nouveau serveur afin qu'il récupère le classement local. La dernière chose à vous inquiéter est que si vous avez besoin de récupérer les données du client sur votre système local exécutant cyrillic, vous aurez besoin d'un serveur de collation hébreu ou DTS/SSIS toutes les données d'une sauvegarde dans un local copie de collation dans vos bureaux afin d'exécuter les données.

Answer 2

Si vous savez que vous allez devoir faire face à différents classements, alors le meilleur conseil que j'ai entendu est de vous assurer que la collation que vous développez est aussi gênante que possible. Je modifierais donc votre configuration de développement pour utiliser un classement sensible aux majuscules et aux accents (CS_AS, pas CI_AS) à tout le moins. De cette façon, toutes les hypothèses liées au classement que vous faites dans votre code devraient apparaître en cours de développement, plutôt que lors de la publication en production.

Je m'assurerais également que tous les scripts sont écrits à la main (ou que vous désactivez les options de script dans SSMS qui incluent les classements), et toutes les versions en production sont effectuées par script, plutôt que par ex. Assistant d'importation/exportation ou en restaurant des bases de données. De cette façon, la base de données de production devrait avoir les options de classement souhaitées par les utilisateurs finaux.