OleDb.CurrencyとOleDb.Decimalのどちらがロケール対応ですか。

ado ado.net localization oledb

これは2つあります。 AccessデータベースとMS Access Currencyフィールドを含むテーブルがあります。 米国の私の顧客は1.23のような小数値を使用し、エクアドルの私の顧客は1,23のような小数値を使用します。

私はいくつかのADOレガシコードを持っていて、タイプadDecimalとタイプadCurrencyでADODBパラメータを作成してみました。 どちらの場合も、私のADODBコマンドが実行された後、Accessのデータは、アメリカでは1.23(予想)、エクアドルでは123.00(予想外)となります。

私の.NETコードでは、OleDb.Currency型とOleDb.Decimal型のOleDbパラメーターを使用してみました。 OleDb.Currencyはロケール対応ですが、OleDb.Decimalは対応していないようです。

私の頭がクラクラします。 誰かが私のレガシーコードの国際通貨に対する正しいADOの使い方と、コードベースが進むにつれて.NETパラメータを書く正しい方法を知っていますか?

ありがとうございます。

  1  0


ベストアンサー

わかりましたので、さらに掘り下げた後は、 “通貨”タイプが “10進”タイプよりも優先されるようです。 つまり、ADOまたはOleDb.CurrencyにadCurrencyを使用すると、MS Accessの通貨フィールドに保存されている10進値に対して機能します。

万が一のためにこれが他の誰かのために起こる – 私は次のようにADOの場合にひどく奇妙なふるまいを見つけました:

私のコードは新しいADODBコマンドをインスタンス化し、adCurrencyとしてタイプされたものも含めてParametersコレクションをセットアップしました。 それから私は私のデータベースの複数の記録を更新し始めた。 次の更新ブロックが開始される前に、更新ごとに同じコマンドオブジェクトを再利用し、すべてのパラメータフィールドを0にリセットするメソッドを呼び出しました。 これは私の分野で悪いデータをもたらしました(上記の最初の問題を見てください)。 私はこれを直すためにたくさんのことを試みたが失敗した。 動作が関連していないことを確認するためだけに、ResetParametersメソッドの呼び出しもコメントアウトしました。

修正:コマンドオブジェクトを再利用するのではなく、各更新ブロックの前に新しいコマンドオブジェクトを新しくすることにしました。 突然、ロケールの設定にかかわらず、すべての10進数値がAccessに適切な方法で表示されました。

要約すると、Executeメソッドを呼び出した後に、後続の更新のadCurrencyパラメータが破損しているように、コマンドオブジェクトに何か変更が加えられたようです。 ちなみに、結果は次のとおりです。4,32の値が432としてAccessに表示されます(これがエクアドルの通貨フォーマットです)。 私のコードはそれほど複雑ではなかったのでここには掲載しませんが、これをかなり難しいと思っている2人のメンバーがいました。 実際、新しいインスタンスを作成するというアイデアは、単一の更新プログラムと、テストで期待されたとおりに動作する正確なコードだけを呼び出すテストアプリケーションを作成したときに生まれました。

ローカライズされたアプリを作成している場合は、ADOコマンドオブジェクトを複数の更新に再利用するように注意してください。

0


内部型はロケールを認識しません。それらは単なる数値です。 ロケールは、入力からキャプチャしてウィンドウまたはレポートに表示するタイミングに影響します。

0


@エドゥアルド、フォーマットについてあなたが言っていることを理解しています。 この場合、私はデータをUIやいかなる出力にも表示しません。 コードからデータベースの更新を完全に発行すると、予期しない動作が発生します。

私はJet(Accessデータベースに使用される)のようなプロバイダで低レベルで何が起こるのかあまりよく知らない。 コマンドパラメータは、後で解析される実際のSQL文字列に変換されますか。それとも、パラメータは直接何らかの方法で使用されますか。 よく分かりません。

私が確信していることは、私が見ている振る舞いは、数値パラメータが適切なMS Accessタイプにスロットされるように、プロバイダーロジックの作者が “currency”と “decimal”タイプを区別することを示しているということです。 間違ったパラメータタイプを使用すると、内部で変換が行われ、結果が乱されます。

一見より一般的な問題(および修正方法を見つけるのがより簡単な問題)は、日付を扱うことです。 例としてエクアドルを再び使用すると、その地域の日付フォーマットはアメリカの月/日/年ではなく日/月/年です。 このようなSQL文字列はうまく機能しません。

お客様の更新設定DateOfBirth =#03/06/1970#

SQLパーサーは常にこの日付を3月6日と読みます(米国に行きます)が、Ecudaorでは実際には6月3日を意味します。 これを修正するには、日付をSQL文字列に追加する前に、常に日付を普遍的に受け入れられている形式に変換します。

お客様の更新設定DateOfBirth =#1970-06-03#(1970年6月3日)

通貨にまつわる「ごちゃごちゃ」はもう少し微妙です – そして私のADOパラメータがループの繰り返しの間に振る舞っていなかったという事実(上の受け入れられた答えを見てください)はかなり奇妙でした。

0


データベースMSAccessの列の型を宣言するには、DecimalではなくDoubleを使用してください。 それは機能し、地域の設定とは無関係です。

0


タイトルとURLをコピーしました