<p>で、更新対象がマスタ-ディテールタイプなのですが、マスタ側を削除したらディテール側も削除したいので、TUpdateSqlを二つ使って...とやり始めて、2つめのTUpdateSqlによる更新が何度やってもうまくいかない。<br />
仕方なく、TUpdateSqlが入ってるDBTablesユニットを解読して、以下の問題箇所を発見。</p>
<pre><strong>procedure</strong> TUpdateSQL.ExecSQL(UpdateKind: TUpdateKind);<br /><strong>begin</strong><br />  <strong>with</strong> Query[UpdateKind] <strong>do</strong><br />  <strong>begin</strong><br />    Prepare;<br />    ExecSQL;<br />    <strong>if</strong> RowsAffected &lt;&gt; 1 <strong>then</strong> DatabaseError(SUpdateFailed);<br />  <strong>end</strong>;<br /><strong>end</strong>;</pre>
<p><br />
でこの RowsAffected が比較している&quot;1&quot;ってどう意味だったっけ？とヘルプを引くと...</p>
<blockquote>最新の問い合わせで実行対象だった行の数を返します。<br />
(中略)<br />
RowsAffectedプロパティを調べると，<em>最新の問い合わせ処理で何行が更新または削除された</em>かがわかります。1行も更新または削除されなかった場合，RowsAffectedの値は0になります。<strong>エラーが原因でSQL文が実行されなかった場合は，RowsAffectedの値は-1</strong>になります。後者の場合は，通常，その前に例外が生成されます。</blockquote>
<p>とある。ということは、ディテール側が0件だった場合にはRowsAffectedプロパティは0な訳で...<br />
というか、キャッシュアップデートの更新は常に1件が対象？<br />
まあ、1レコードの更新には1件のUpdateSqlが実行されるので、1件かもしれない。</p>
<p>&nbsp;</p>
<p><em>仕方ないので、2個目のUpdateSqlを実行する際には、例外構文で例外クラスがEDatabaseErrorの時にはRowsAffectedが-1でない時以外はエラーを無視する</em>ようにしてしまいました。</p>
<p>この処理を見ていて思ったのは、キャッシュアップデートの範囲。TQueryなどDataSetがキャッシュしてたら別のQueryから更新をかけたらそ の更新はキャッシュされないのか？とか考えたが、TUpdateSqlの処理を見ていてうまくいくことから、データベースコンポーネントかセッションコン ポーネントあたりでキャッシュしてるようだ。</p>
<p>ということは、データベースコンポーネントかセッションコンポーネントを複数プログラムに追加したら、片方はキャッシュでもう片方は直でということが出来そうだ...</p>