今回新たにAzure上にSQLserverを立てました。
これまでいくつか作ってきたのですが、全て僕個人が使う範囲での物。
しかしながら今度のは僕以外の人が使用するので、色々とややこしくなったのでメモを。
普段SQLserverを扱う時には、便利なManagement Studioを使っています。
データを入れる時には自分のプログラム経由。
つまり殆ど直でのやりとり。
が、今回はフロントエンドがAccess。
リンクテーブル経由での運用になります。
そうなると、文字コード関連で悩むはめになるんですよ。
データベース作成時に何も指定しなければデフォルトの文字コードは「SQL_Latin1_General_CP1_CI_AS」になるはず。
Accessにてリンクテーブルをアチコチ繋ぎまくっていると文字化けの温床になる可能性大。
現状ODBC経由でSQLserver、その他データベース、他のAccessとカオスな構造になっており、なるべくならトラブルは減らしておきたい。
しかもこの文字コードだと日本語を扱う時にはNプレフィックスを使う必要もあって手間だったりします。
このように。
もしNがついていないと、Where文にはヒットしません。
他の人が使う事を考えると出来るだけこれは避けたいなと。
なので初めてこの文字コードを使う事にしてみた。
「Japanese_Bushu_Kakusu_100_CI_AS」
・Collation and Unicode Support
これであればNプレフィックスは不要になる。
（ちなみに、1つめは佐賀競馬場のレースで、下段のはJRAのレース）
Accessでもインサート他で文字化けも起こらない。
でもね。
「補助文字 (_SC) を含む照合順序を使用しているデータベースでは、 SQL Server レプリケーションを有効にすることはできません。」
という注意書きもあります。
あるのだけれどもAzureでレプリケーションを設定したら、出来てしまいました。
・・・よく分からん。
2017以降では解決されたとかでしょうか。
他にもtext型等の制約はチョイチョイあります。
それでもまだこの文字コードの方がメリットが大きい。
どんな落とし穴があるのか？もっとテストしないと見えてこないのかも。
6時間ほどアレコレとテストをしてみて今のところ問題ナシです。
このまま進めてしいいのか迷うなあ。
see more info at JRDV.sp