注: 以下の翻訳の正確性は検証されていません。AIPを利用して英語版の原文から機械的に翻訳されたものです。
以下は、Data Connection に関するよくある質問です。
一般的な情報については、Data Connection のドキュメントを参照してください。
SNAPSHOT トランザクションの実行時に取り込みによってデータセット内の行が重複したビルドは指定された時刻に実行されるようスケジュールされていましたが、実行が試みられませんでした。
トラブルシューティングを行うには、次の手順を実行します。
このデータセットとブランチで、ほかの同期が実行中ではありませんか？同じデータセットとブランチで2つの同期を同時に実行することはできないため、ほかのジョブが同時に実行されていないことを確認します。
スケジュールが一時停止されていませんか？このデータセットのスケジュール概要ページで、このスケジュールが一時停止されていないことを確認します。このページには、同期のスケジュールアプリで編集の表示、またはデータセットプレビューのスケジュールの管理オプションからアクセスできます。
この同期の Agent が無効になっていませんか？この同期のソースに関連付けられている Agent に移動し、Agent が無効になっていないことを確認します。
SNAPSHOT トランザクションの実行時に取り込みによってデータセット内の行が重複した同期は実行されましたが、行が重複しました。
Snapshot ではなく APPEND タイプの同期を実行するように選択します。last_upd_in_appl_ts が一意で常に増加する列である場合は、それを対象の列として設定し、その列のほかのすべての値より小さい値を選択します。インクリメンタル同期を実行したとき、どの値が使用されましたか？
トラブルシューティングを行うには、次の手順を実行します。
incrementalMetadata のブロックを確認し、内容が正しいことを確認します。同期後のデータセットに表示されるデータ型が、元のデータ型と異なります。
トラブルシューティングを行うには、次の手順を実行します。
TIMESTAMP の場合、Foundry での結果のデータ型が LONG になっているかどうかを確認します。LONG の場合は、任意のデータ準備ツール（Code Repositories、Preparation、またはほかのアプリケーション）を使用して、そのデータ型を TIMESTAMP にパースする必要があります。これは、データベースの開発元が提供する多くのドライバーで、データ型が最も安全な表現に戻されることによる副次的効果です。DECIMAL で、元のデータベースと精度が異なる場合は、データベース自体に対するクエリで数値を特定の精度とスケールにキャストするか、クエリで列を VARCHAR にキャストし、Foundry で再キャストすることを推奨します。TIME 型の列でデータベースとデータセットの間に秒未満の精度が失われるデータベースには、秒未満の精度を持つ TIME 型の列があり、秒未満の部分がゼロでない値が含まれていますが、データセット内の値には秒単位までの違いしか反映されません。
PostgreSQL や Microsoft SQL Server を含む、ほとんどの JDBC ベースのソースでは、データベース内の TIME 値は、午前0時からの経過ミリ秒数を表す INTEGER として Foundry の出力データセットに反映され、その値は秒単位で切り捨てられます。その結果、データベース内の 05:00:00.000、05:00:00.200、05:00:00.800 などの値は、出力データセットではすべて 18000000 になります。
秒未満の違いを保持するには、以下の Postgres の例のように、同期設定の SQL 文で値を文字列にキャストすることを検討してください。
Copied!1SELECT record_id, CAST(column_with_time_type AS text) FROM table_name
クエリの実行開始後に、そのステータスを確認するにはどうすればよいですか？
トラブルシューティングを行うには、次の手順を実行します。
インクリメンタル（差分）APPEND トランザクションの間にファイルまたは JDBC テーブルのスキーマが変わると、データセットでスキーマの不一致を示すエラーが発生するようになります。Data Connection は JDBC 抽出ではスキーマを推論しますが、ファイルベースの抽出では既存のスキーマを伝播するだけです。この場合、スキーマが同じであれば、スキーマ推論を再度適用する必要があります。APPEND トランザクションの間にスキーマが実際に変わった場合は、新しいスキーマ用に新しいデータセットが必要です。
トラブルシューティングするには、次の手順を実行します。
ファイルベース
ファイルが XLSX または CSV の表形式データであれば、同期済みのデータセットで問題なくスキーマを再推論できる場合があります。このスキーマが以前のスキーマと一致する場合、データセットには問題なく追加の行が追加されます。
スキーマを推論した後もスキーマエラーが発生する場合（データセットプレビューまたは別のアプリケーションで）、この新しいファイルはテーブルの根本的に異なるビューを表しているため、代わりに新しいデータセットに同期する必要があります。
新しいスキーマでデータセットへの追加がすでに行われている場合は、Palantir サポートに問い合わせて、このトランザクションを元に戻すことを推奨します。また、同期の概要ページに移動し、この同期に関連付けられているスケジュールを一時停止して、現在のデータセットへのファイルの同期を一時停止する必要があります。
新しいスキーマを持つ以降のファイルは、元のデータセットとは異なるデータセットに同期する必要があります。そのため、元の同期の情報を新しい同期にコピーし、対象データセットを別のデータセットに置き換えることを推奨します（データセット名に新しいバージョンを記載します）。
また、今後スキーマの不一致エラーが発生して Foundry 内の既存データが破損することを防ぐため、元の同期を削除するのが最善の場合があります。
JDBC
account_transactions_v1.0）。account_transactions_v1.1）に置き換えます。その後、この新しいデータセットを元のデータセットとユニオンすることで、すべてのデータを含めることができます。同期の Job Spec を削除した後、再追加しようとすると権限エラーが発生します。
この問題を解決するには、次の手順を実行します。
同じデータセットに出力する新しい同期を作成します。これにより、対象データセットの既存データを保持しながら、正しい権限を持つ新しい Job Spec が作成されます。
Bootvisor が不明の状態のままになり、停止も起動もできません。
続行する前に、Palantir サポートに問い合わせてセットアップを確認してください。以下の手順を実行すると、この Agent で一時的に同期を実行できなくなります。ダウンタイムを防ぐため、ソースに複数の Agent を確保するか、メンテナンスウィンドウ中にこれらの手順を実行してください。
kill で終了します。./service/bin/init.sh start で Bootvisor を起動します。TLS、mTLS、SSL に関するガイダンス（サーバー証明書またはクライアント証明書を追加すべきかどうかや、CERTIFICATE_VERIFY_FAILED などの一般的な証明書エラーの解決方法を含む）については、証明書と TLSを参照してください。