> ホーム > サポート > Data Integrator FAQ

Support

会社

Pervasie Data Integrator FAQ

[ 質問に戻る ]

エンジンプロファイルをONにすると、メモリを使い切ってMap Designerが異常終了する場合があります。
エンジンプロファイルをONにすると、実行時にプロファイリング処理を行いますが、この処理で作成するプロファイル出力ファイルはプロファイル情報をメモ リ内でまとめてから出力するようになっています。このため、実装メモリ量、件数、マップで使用している関数やスクリプトの種類や数によってはメモリを使い 切ってしまうことがあります。

エンジンプロファイルをONにするときは、データ件数が多い実運用環境ではなく、処理件数を絞ったテスト環境で実行されることをお勧めいたします。また、実装メモリが少ないマシンでは、メモリを増設することもお勧めいたします。

(2008/07/17)#002

トップへ戻る

パブリックなプロセス変数を用意してプロセスから呼び出すマップでこのプロセス変数をQueryStatisticのReadsの格納先として使用していますが、常に件数が0になり、正しい件数を受け取ることができません。
QueryStatisticのReadsやRejectsなどの件数情報の格納先としてパブリックなプロセス変数を直接使うことはできません。このた め、マップでのみ有効なグローバル変数を用意してこれを格納先としてください。格納後、マップ内でこのグローバル変数からパブリックなプロセス変数に値を 代入してください。

(2008/07/17)#003

トップへ戻る

TLookup関数での説明ではキー長は31文字ということですが、キーが漢字(エンコードはシフトJIS) の場合、15文字ではマッチせず、10文字以下の場合しかマッチしない現象が発生します。シフトJISは1文字で2バイトつまり半角文字2文字なので漢字 なら15文字までキーとして識別できるのでは?
TLookup関数ではルックアップファイルのためにインデックスを作成しますが、このときキーをUTF-8でエ ンコードします。このため、キーが漢字の場合は内部的には3バイトで扱われてしまうために漢字は元のエンコードに関係なく10文字までしかキー値としては 認識できません。

ILookup関数を使用すれば、全てをメモリ上で展開するためこのようなキー長の最大が31文字という制約がありませんので、ILookup関数の使用をご検討ください。

(2008/07/17)#004

トップへ戻る

BinaryコネクタでCR-LFつきのUnicodeエンコーディングされたテキストファイルを読み込むと、Record SeparatorでCR-LFを指定しても正しくレコードを認識しません。
BinaryコネクタでUnicodeエンコーディング(UCS-2、UTF-8など)を指定した場合、レコード区切りとしてCR-LFを正しく認識でき ません。CR-LFで区切られたレコードを持つUnicodeエンコーディングされたファイルはUnicode(Fixed)コネクタをご使用ください。

(2008/07/17)#005

トップへ戻る

8.6.6.58を使用していますが、ヘルプに記載されているCharFieldWidthsプロパティがUnicode(Fixed)コネクタのプロパ ティリストに存在しません。Unicode(Fixed)コネクタは文字列データをバイトで扱っているのでしょうか、それとも文字数で扱っているのでしょ うか?
PDI8.12.1.xまではUnicode(Fixed)コネクタは指定されたエンコードに基づいて以下のように自動的に文字列の扱いを設定して動作します。このため、ヘルプに記載があるものの実際のコネクタのプロパティリストには表示されない仕様になっていました。
ex.)
UTF-8,UTF-16,UCS-2の場合はTrue (文字数単位)
 上記以外のエンコードはFalse (バイト単位)

なお、8.14.1.16以後はヘルプファイルの記載とおりにコネクタのプロパティリストにも表示されるようになりました。ただし、エンコードが UTF-8,UTF-16,UCS-2の場合はFalse (バイト単位)を指定してもこれらのエンコードの場合は必ず文字数単位で扱います。そのため、False (バイト単位)を指定してもデータパーサーではこれらのエンコードは取り扱うことができませんので、ご注意ください。

(2008/07/17)#006

トップへ戻る

Oracleの30桁の数値を扱えるNumber型データフィールドを「クエリステートメント」で以下のようなSelect文を記述して取り扱うと、出力 結果が30桁ではなく、15桁で丸められた数字列になってしまいます。「クエリステートメント」を使わず「テーブル/ビュー」でテーブル名を指定してこの フィールドを扱った時には30桁正しく出力されます。
ex.)
SELECT ta.key1,
CAST(NVL2(tb.key1,tb.kosu,ta.kosu) as Number(30,4)) AS kosu
FROM tab_a ta, tab_b tb
WHERE ta.key1 = tb.key1(+)

(注) 上記Select文で、tb.kosuとta.kosuのフィールドが30桁のNumber型フィールド
直接テーブルデータを扱う「テーブル/ビュー」ではなく、「クエリステートメント」でSQL文で数値を加工した場合、OCIがデータ型を長い桁数が扱える Number型ではなく、Double型として通知してくるためにPDI内部ではDouble型データとして扱わざるをえません。このため、Double 型の仮数部15桁の有効数桁数で丸めが発生してしまいます。これは仕様上避けられず、Oracleコネクタ、ODBCコネクタのいずれを使用しても発生し てしまいます。

数値型として受け取ると、上記のように長い桁数のNumber型でCASTしてもDouble型としてしか認識できないため、数値として正しい桁数で受け 取ることができません。以下のように十分な桁数が格納できる文字列型にCASTして数字文字列として受け取るようにしてください。

SELECT ta.key1,
CAST(NVL2(tb.key1,tb.kosu,ta.kosu) as varchar2(100)) AS kosu
FROM tab_a ta, tab_b tb
WHERE ta.key1 = tb.key1(+)

このような長い数値を返す関数の他、長い数値を返すフィールドを持つViewや副問い合わせの場合も本来の長い桁数のNumber型ではなく、OCIからはDouble型で通知されるため、数値型ではなく、文字列型にCASTしてデータを受け取る必要があります。

(2008/07/17)#007

トップへ戻る

リジェクト先にAccessコネクタを使用したときに「マップ」タブの「次のレコード」アイコンを押すと、
「cmdmove_Click(spectab.frm) で Unable to connect to target for reject data:
encoding=OEM;commitfrequency=0;systemtables=False;
views=True;synonyms=False;maxdatalength=1048576;
identityinsert=False;Database='C:\Access\Samples1.mdb';Table=Test1; (25521)」
というようなリジェクト先に接続できない旨のエラーが発生します。
これはリジェクト先にAccessコネクタを使用すると、排他的にmdbファイルをオープンするために発生する問題で、
「マップ」タブ右下のレコード移動アイコンボタンのいずれかを押したときに発生します。
リジェクト先にAccessコネクタを使用する場合は、これらのレコード移動ボタンを押してレコード内容の確認を行わないでください。

なお、リジェクト先mdbファイルをAccessコネクタではなく、ODBC 3.xコネクタを使用して、mdbファイルをODBCデータソースとして
定義しておけば、このような排他的なオープンを行いませんので、レコード移動ボタンを押して内容を確認することができます。
ODBC 3.xコネクタのご使用もご検討ください。

(2008/07/17)#008

トップへ戻る

Accessターゲットコネクタを更新モードで使用したときに、更新対象が1万件程度になると「データソースを開くときのエラー」が発生します。更新ではなく、レコードを追加するときは発生しません。
これはAccessターゲットコネクタが使用するマイクロソフト社のACCESS OLEDB Provider内で、更新のために使用するRecordsetのレコード数が9493以上だと、このエラーが発生します。このため、この件数以下で更新 処理を行うか、Accessターゲットコネクタを使用せずにmdbファイルをODBCデータソースとして定義してODBC3.xターゲットコネクタを使用 してください。

(2008/07/17)#009

トップへ戻る

8.6.6.58を使用してSalesforce.com(SFDC)とデータをやり取りしていますが、通信エラーが多発したり、また、まれに読み書きするデータ件数と処理件数があわないことがあります。
8.6.6.58以前のPDIのSalesforceコネクタは内部的に通信異常が発生してもこれをリトライ処理 する機能がないため、通信エラーが多発したり、まれにデータを取りこぼす場合がありました。使用しているPDIが8.12.1.x以降でなければPDIの バージョンを8.12.1.x以降のものに変更してください。8.12.1.x以後では通信異常時に内部的なリトライ処理を行うようにコネクタが改良され ていますので、通信エラーによる問題が軽減します。

(2008/07/17)#010

トップへ戻る

Salesforce.com(SFDC)から日時データ(Datetime型)を受け取り、CDate関数 やTimeValue関数に引数として渡していますが、8.6.6.58までは、これらの関数はUTC(GMT)の時間を返していました。 8.12.1.x以後はこれらの関数から返される時間がWindowsの「タイムゾーン」で設定したローカル時間になってしまいますが?
8.6.6.58まではSalesforce.comコネクタから返されるDatetime型の日時文字列が W3C-DTFの形式(タイムゾーンはZのUTC)でありながら、格納されている時間がUTCからかけ離れた時間(タイムゾーンの時差を含んだもの)に なっていました。このため、W3C-DTFでありながら他社の処理系にはそのまま渡せないなどの問題あった他、CDate関数やTimeValue関数に 渡して使用した場合にはマップを動かすマシンのタイムゾーンごとに時差の補正処理が必要になるなどの問題がありました。

8.12.1.x以後ではこれらの問題を解消し、Salesforce.comコネクタから返されるDatetime型の日時文字列は正しいW3C- DTFとなり、マシンのタイムゾーンに関係なく同じ値になりました。このため、Datetime型の日時文字列を他社の処理系でも正しく扱えるようになっ た他、Salesforce.comコネクタから返されるDatetime型をCDate関数やTimeValue関数に与えると、返される値は Windowsの「タイムゾーン」で設定したローカル時間となりますので、受け取り後の時差の補正処理も不要になりました。

(2008/07/17)#011

トップへ戻る

PDIをより新しいビルドに入れ替える場合、例えば、8.6.6.58から8.12.1.60に変更するようなときは、既存のマップやスキーマ、プロセスのファイルなどを作り直す必要はありますか?
PDI8.xシリーズでは上位互換性がありますので、8.6.6.xで作成されたマップ、スキーマ、プロセスのファイルはそのまま8.12.1.xで読みんでデザインしなおしたり、実行させたりすことが可能です。

(2008/07/17)#012

トップへ戻る

Windows Vistaでは使用できませんか?
まことに申し訳ありませんが、PDIは現状ではWindows Vistaではご使用いただけません。
次期リリース PDI9.2J で対応する予定です。

(2008/07/17)#013

[ 質問一覧に戻る ]


Copyright ©  2007 Data on Demand Software Corporation. All Rights Reserved.