WebSurfer's Home

トップ > Blog 1   |   ログイン
APMLフィルター

LocalDB の照合順序

by WebSurfer 2020年9月24日 11:28

Microsoft LocalDB の照合順序はデフォルトで SQL_Latin1_General_CP1_CI_AS になるそうです。今更ながらですが調べてみたらそうなってました。

LocalDB の照合順序

Microsoft の Blog の記事「[SQL Azure] Unicode型列(NCHAR/NVARCHAR) に格納されるデータが “?” になる」によると、SQL Azure も同じだそうです。

なので、その記事にも書いてありますが、以下のような N プレフィックスを使わない SQL では文字化けします。

INSERT INTO [Table] ([Name]) VALUES ('あいうえお')

知ってました? 何をいまさらと言われそうですけど。(汗)

SQL 文をパラメータ化し ADO.NET + SqlClient を利用して INSERT, UPDATE 操作を行えば、内部的に N プレフィックスが付与された SQL 文に変換されて実行され、文字化けの問題は起こらないので、気が付かないかもしれません。(詳しくは先の記事「パラメータ化の副次的な効用」参照)

Visual Studio を使って ASP.NET プロジェクトを作る際[個別のユーザーアカウント]を選ぶと、ASP.NET Identity のユーザー情報のストアはデフォルトで LocalDB を使う設定となり、EF Code First で生成されるデータベースの照合順序も同じく SQL_Latin1_General_CP1_CI_AS になります。

自分でモデルを定義してそれをベースに EF Code First でデータベースを生成する場合も、接続文字列で LocalDB に接続する設定がされていると当然 LocalDB にデータベースが生成されますが、同様に照合順序は SQL_Latin1_General_CP1_CI_AS になります。

ASP.NET MVC アプリでは Linq to Entities を使って DbContext クラスを継承したコンテキストクラスを操作してデータベースとのやり取りを行うケースが多いですが、そういう場合も内部的に N プレフィックスが付与された SQL 文に変換されて実行されるようで、文字化けの問題は起こらなかったです。

Tags: ,

SQL Server

About this blog

2010年5月にこのブログを立ち上げました。主に ASP.NET Web アプリ関係の記事です。

Calendar

<<  2020年9月  >>
303112345
6789101112
13141516171819
20212223242526
27282930123
45678910

View posts in large calendar