0

最近、すぐに使用できる Delphi 2009 を入手したため、アプリケーションを完全な Unicode 互換性にアップグレードする作業を進めています。Unicode 文字を受け入れるようにアプリケーションをアップグレードした経験のある方を探しています。具体的には、次の質問のいずれかに回答します。

  • VarChars を NVarchar に、Char を NChar に変更する必要があります。ここに落とし穴はありますか。
  • すべての SQL ステートメントを更新して、SQL 文字列の前に N を含める必要があります。したがって、Update tbl_Customer set Name = 'Smith' は Update tbl_Customer set Name = N 'Smith' になる必要があります。特定のフィールドに対してこれをデフォルトにする方法はありますか。これがまだ必要であることは異常に思えます。
  • これを簡単にするデフォルトを SQLServer に設定することは可能ですか?

ps Oracleコードもアップグレードする必要があります

4

3 に答える 3

1

Oracle では、Unicode 文字列を格納するために を使用する必要はありません。サーバーはUTF-8 でnvarchar格納するように構成できます。varchar2以前に ASCII のみをサポートしていた場合は、透過的である必要があります。'これにより、アプリケーション側でto を検索して置換する必要がなくなりますN'。

ダミアンの指摘については、今は役に立たないかもしれませんが、パラメータ化されていないクエリを取り除くことを本当に優先する必要があります。それらは、メンテナンス、パフォーマンス、および安全性の観点から、システムの障害に他なりません。

于 2008-09-17T10:39:33.737 に答える
1

SQL Server では、nchar/nvarchar の制限が対応する char/varchar の半分であることは明らかです (4000 を超えるすべてを nvarchar(max) に移行しない限り)。

于 2008-09-17T13:17:25.010 に答える
0

ダミアン

あなたの答えがどれほど役立つかわかりません。過去10年間に作成された、大量のSQLクエリを含む700,000行のコンパイル済みコードベースがあります。ほとんどは、データベースのほとんどの更新の基礎となるいくつかの機能に標準化されています。これらは非常に簡単に更新できます。ただし、CustomerName ='％s'のすべてのwhere句もチェックする必要があります。これは、CustomerName = N'％s'になります。

これは本当の答えを必要とする本当の質問です。

于 2008-09-17T10:02:50.127 に答える