2

パイプ区切りファイルから抽出して、SQL Server2008R2データベーステーブルに挿入しています。私の整数列の1つに、テーブルに到達するまでに正しい値が含まれていません。

最初のオブジェクト（フラットファイルソース）の直後にデータビューアーをデータフローに追加し、メモ帳で開いたソースファイルとデータを並べて比較できます。私の文字列列はすべてOKですが、これらの一意の7桁の整数は、3つの値のいずれかに置き換えられます（ただし、元のファイルには16Kの一意の行があります）。新しい値は、置き換えているものと同じ形式と範囲のように見えますが、ソースファイルには表示されません。実際には、どこかにキャッシュされているように見えます。

詳細情報：ソースの外部列は50文字の文字列で、出力列は4バイトの整数です。ファイルソースの接続文字列は、インポートディレクトリで候補ファイルを検索する以前のスクリプトによって設定された変数に基づく式によって設定されます。前または後のいずれかにデータを変換または変更する他のタスクはありません。このパッケージは、データを処理するための別のプロセスの純粋な抽出プロセスです。置換されている値は、パッケージファイルのXMLに表示されません（データを混乱させていた古いコードが残っている場合に備えて検索しました）。

タスクを再現でき、すべてが機能しているように見えますが、これを説明するプロパティに違いは見られず、再び壊れるのではないかと心配しています。ここで何が悪いのかを本当に理解したいと思います。

このようなデータを「破損」させる可能性のあるアイデアはありますか？

4

2 に答える 2

1

これは、コード ページの問題である可能性があるようです。2つのオプションを提案します

  1. 接続マネージャーのデータ型を char 50 から整数に変更します
  2. 元の 50 文字の文字列としてインポートしてから、データ変換変換を実行してみませんか。
于 2012-11-08T19:19:49.270 に答える
0

申し訳ありませんが、先に返信できませんでした。ソースと外部のデータ型と変換のさまざまな組み合わせを試しましたが、成功しませんでした。時々、列が空であるか、私が言及した3つのガベージ値の1つでした。興味深いのは、掘り下げた後、同僚が16進数の3つの値が4d0000、4e0000、4f0000であることに気づいたことです。何を読み込めばよいかわかりませんが、値自体はあまり意味がないようです。ある種のカラーコードです。私はそれらが秘密のエラーコードになることを望んでいました。とにかく、うまくいったように見えるのは、列を完全に削除し、それらを8バイトのint（外部と出力の両方）として追加し直すことでした。数日中にもう一度確認し、コードページのアイデアを調べます。他に何か見つかった場合は、この質問を更新します。ありがとう！

于 2012-11-09T22:52:44.843 に答える