v22k
2026 年 9 月 25 日午後 2:48
1
最近、Excel/Power BIでInvantive Bridge Online (OData4) 経由で ExactOnlineREST.Incremental.TransactionLinesIncremental@eol を使用し始めました。私の期待では、最初の完全なロードの後、各リフレッシュで変更された行や以前の取得以降の削除された行などのデルタのみが取得され、処理されることでした。しかし、ログを見ると今期待から少しずれています。これが正常な動作なのか、それとも何か問題があるのか疑問に思っています。
環境
Invantive Bridge Online 26.0.286
増分テーブルの行数は約170,000行
HTTPディスクキャッシュは4時間、Bridgeレスポンスキャッシュは15分
IncrementalLoadEventLogEntriesで見たもの
各リフレッシュの後、ほとんどの場合、行カウントに基づいてリセットが続く: 「現在のキャッシュ行数が計算された許可される最小行数から大きくずれているため、増分キャッシュの完全リロード…」 。その後に*「再構築中。古いデータを再利用しないでください。完全リロード…」*が続きます。
各リフレッシュには*「からに移動したタイムスタンプ」という空の値のログと 「増分結果を更新する必要はありません。以前のバージョンはありませんでした。」*が表示されます。
数回: 「最近のダウンロード用のすべてのデータファイルが見つかりません…2つのデータファイルを期待していますが、0個見つかりました」 。
セッションI/Oで見たもの
デルタ自体は正しく機能しているようです: sync/Financial/TransactionLines?$filter=Timestamp gt …L は変更された行のみを取得しています。
しかし、その後には、フルテーブルの約170ページが続きます。ディスクキャッシュが有効な限り、それらはキャッシュから取得されますが、リフレッシュに60〜80秒かかります。
削除されたAPIは各リフレッシュ時に Timestamp gt 0L および gt 1L からそれぞれ4ページずつ取得されます。これも最後に見たタイムスタンプから始まることを予想していました。
連続するリフレッシュは、同じ Timestamp gt …L 値で開始します。デルタ後にタイムスタンプが進んでおらず、デルタがますます大きくなっているようです。
ディスクキャッシュが期限切れの場合、デルタ後に増分テーブル全体が再度Exactから取得されます（約220回の真の呼び出し、このテーブルだけで3〜8分以上かかります）。
私が気づいたこと $count に正確に対応します。Deleted APIからの3,000以上の削除されたIDを処理した後、約3,000行少なくなります。削除されたとして報告されたIDがExactにまだ存在しており、そのため行数検査が完全リロードアクションを引き起こしているようです。しかし、私はこれを誤解しているかもしれません。
私の質問
各デルタの後に完全なテーブルが再構築されるのは通常ですか？
削除されたAPIが常にタイムスタンプ0から読み取られ、最後に見たタイムスタンプが進まないのは普通ですか？
削除されたIDに関する私の推測は正しいですか、それとも行数の不一致に対して他に説明がありますか？
これは、リリース26.0に関するこのトピック で述べられた増分ファイルに関連していますか？
これが期待された動作でない場合、デルタのみが処理されるように解決する方法を教えてください。
イベントログとセッションI/Oのエクスポートをリクエストに応じて提供できます。
forums
2026 年 9 月 25 日午後 8:38
2
完全に可能なAI生成のテキストを解読することはできません。
完全に再読み込みするのは通常の動作ではありません。これは、アルゴリズムがデータセットが不完全であると判断した場合にのみ発生します。
数千の削除された行も一般的ではありません。
アドバイスとして、下記に記載されているように、リロードリクエストのスクリーンショットを追加することをお勧めします。
Meer inzicht met nieuwe Online Monitoring に記載されているように、Online MonitoringのInvantive Cloudでリクエストの詳細の（匿名化された）スクリーンショットを追加することは可能ですか？
詳細は、このトピックの主題を表すダウンロードリクエストをクリックすると見つけることができます。
ダウンロードリクエストには通常、テーブル名が見えるSQLステートメントがあります。
少なくとも次のデータが両方のカラムで見えるようにしてください：
リクエストIDが表示されているタイトルバー、
左カラムのステータスコード、ネットワークサイズ、パス、時間、
左カラムの一番下にあるエラーコードとエラーメッセージ、
SQLステートメント、テーブル名、パラメータ値を含む右カラム全体。
例えば：
正確に、Invantive Bridge Onlineなどでデータを処理するために使用しているのと同じユーザー名を使用していることを慎重に確認する必要があります。同じユーザー名でInvantive Cloudのウェブサイトにログインしてください。ウェブサイトにログインすると、そのユーザーによるリクエストのみが表示されます。
最初にリクエストを選択して詳細を表示するようにしてください。スクリーンショットには1つのリクエストのみが表示されるはずです。
また、リクエストがodata4、apps、またはmcpのパスを持っていることを慎重に確認してください。これ以外のパスのリクエストは通常、この目的に関連しません。
さらに、Power BI、Power Query、Azure Data Factory、Qlik、またはTableauでエラーメッセージが発生した場合、そのエラーメッセージを持つInvantive Cloudユーザーには電子メールで多くの場合、エラーメッセージとヒントが送信されます。
関連ユーザーのスパムフォルダを support@invantive.eu からのそのような電子メールでチェックすることをお勧めします。
v22k
2026 年 9 月 29 日午後 3:07
3
0HNOTTS4MANND:00000003ここにスクリーンショットがあります:
クエリ:
select ...
from ExactOnlineREST.Incremental.TransactionLinesIncremental@eol
where (Division = :w1 and ((([GLAccount = :w2 or [GLAccount] = :w3) or [GLOAccount] =:w4) or [GLAccount] = :w5))
部門: 3619926
バージョン: Invantive Bridge Online 26.0.334.6277
forums
2026 年 9 月 30 日午後 6:24
4
このキャッシュの再ロードはプロトコルバージョンのアップグレードによって引き起こされました。古いキャッシュはリリース26.0.286の下でプロトコルバージョン7に基づいて構築されていましたが、データはリリース26.0.334から取得されていました。
内部のロギングは、監査テーブルにも反映される可能性がありますが、これを記録しています。
'/SOMEPATH/TransactionLinesIncremental/72070809c7b62ad341e7de06cb24e183.cache' にあるサポートされていないHTTPディスクキャッシュ形式でのペイロードを発見: プロトコルバージョン7ではなく9、圧縮がTrue、暗号化がTrue。
しかし、これは一度きりであり、それ以前には発生していないはずです。分析の結果、「タイムスタンプ」の決定時にバグが発生することが明らかになりました。この動作は正常ではなく、望ましくありません。
この問題を解決するバグフィックスは、今後のリリース27.0で行われ、技術的に可能であればリリース26.0にも含まれる予定です。
forums
2026 年 10 月 1 日午前 11:51
5
この問題を解決する新しいリリースが利用可能です。必要な変更はリリース26.0.340以降およびすべての将来のBETAバージョンで利用可能です。
この新しいリリースはInvantive Cloudで導入されています／されます。
詳細については、以下をご覧ください：
forums
2026 年 10 月 22 日午後 4:38
6
この質問は1週間操作がなかったため、自動的にクローズされました。最後に投稿された回答が解決策としてマークされています。
問題が再発した場合は、別のトピックとして新しい質問を投稿してください。新しい質問には、このトピックのURLを本文に貼り付けてリンクを含めてください。
