2012-02-10 7 views
1

Windows-ANSI(Windowsコードページ1252)としてエンコードされたDBFファイルがあります。私はODBCドライバを使用して、このファイルをテーブルとしてSQL Serverデータベースにインポートしています。私がすると、いくつかの文字情報が失われます。Windows-Ansi DBFをSQL Serverにインポートすると文字データが失われる

最初に、DBFファイルが期待どおりにエンコードされていることを確認するために、ファイルを16進エディタで開き、問題の文字を検索しました。これはコードページ1252の「小文字」であり、ファイル内の0x95に格納されていたので、少なくともその文字については、エンコードが期待どおりであるように見えます。

私は検索して、varcharカラムではなくnvarcharにインポートすると違いがあると言っている人がいるので、問題のある文字を含むカラムをnvarcharに再マップしました。

それはにインポートされたデータベースは、「順序SQL_Latin1_General_CP1_CI_AS」との照合を持っている私は、インポートを行うと、これはWindowsコードページ1252

に相当する必要があることを示し、「CP1」MSDNに読んページから0xf2または0x5625としてインポートされています。私はなぜこの点まで様々な輸入があるのか​​について何らかの理由を見いださなかった。

誰かがこのような問題に遭遇しましたか?あなたはそれを解決するために何をしましたか?私が探しているべきことや、私がまだ行っていないことを試してみるべきことは何ですか?

+0

私はこれをさらに掘り下げて、0xB7の値が0x5625に変換されていることを発見しました。 ODBCドライバをさまざまなソース(ExcelとVBアプリケーション)に接続し、同じ問題が発生したので、これはODBCのものと仮定しています。また、0x5625、2 + 5 = 7および5 + 6 = Bの値については注意が必要です。 – Andrew

+0

もう一度コメントしてください。 B7の0x5625の値はちょうど偶然かもしれません。これは、SQLサーバーのnvarcharにデータをインポートする場合にのみ発生します。 ODBC接続の他のアクセスは0x2Bを生成します。私は0から255までのすべての値を調べ、ODBCが0x80以上の値を間違って報告しているようです。 – Andrew

答えて

1

これは古いドライバの問題であるようです。新しいDBFドライバにアップグレードすると文字の問題は解決しましたが、別の問題が発生しました。新しいドライバには、列スキーマ内の「序数」情報が不足しているため、DTSウィザードで使用することはできません。少なくとも、これを行う方法は見つかりませんでした。

Microsoft Visual FoxPro OLEDBドライバをインストールすると、問題なく動作します。インストールが完了すると、DTSウィザードでデータソースとして表示され、直接インポートに使用できます。これは私のキャラクターの問題を解決し、私は私のインポートを行うことができました。