MS Access Update SQLクエリレコードの量が極端に遅く、掛け算されました。

Question

このクエリをより効率的に/正しく実行する方法がわかりません。ここで最初のクエリであると、私は関与しているテーブルを記述することができます。

UPDATE agg_pivot_test AS p 
LEFT JOIN jd_cleaning AS c 
    ON c.Formerly = IIF(c.Formerly LIKE '*or*', '*' & p.LyFinalCode & '*', CStr(p.LyFinalCode)) 
SET p.CyFinalCode = c.FinalCode 
WHERE p.CyFinalCode IS NULL AND c.Formerly IS NOT NULL; 

agg_pivot_testは、データの200行を持っており、唯一の99はWHERE p.CyFinalCode IS NULLの基準に適合する。 JOINには説明が必要です。何人かの天才がFormerlyを使用して去年のデータを今年のデータにリンクさせることを決めたので、それはIIFです。これは文字列です。複数の項目が1つに統合され、「or」（つまり、632 or 631 or 630など）が使用されることがあるためです。だから今年のデータと一致させたい場合は、Formerlyを使って昨年のLyFinalCodeとマッチさせる必要があります。だから、今年のコードは629かもしれませんが、632、631、または630だったアイテムを新しいコードにマップするには、Formerlyを使用する必要があります。理にかなっている？そのため、ONにはIIFが含まれています。また、Formerlyは文字列で、LyFinalCodeは整数です...楽しいです。

とにかく、クエリを実行すると、再び1807レコードが更新され、200レコードしかなく、条件を満たすレコードは99レコードだけになります。

何が起こっているのか、それを修正する方法についてのご意見はありますか？

Answer 1

興味深い問題です。私はこれまでにまったく同じようなことに出会ったことはないと思う。

私は、CyFinalCodeがヌルであり、ジョインステートメントで複数回マッチしているため、ジョイン式が行マッチのデカルト積を計算していることを推測しています。これが、行更新メッセージ。私は複数の行の一致について不平を言うアクセスを期待していたので、行の一致は更新ステートメントの1：1に過ぎないはずです。

私は、（この結合で）select文としてクエリを書き直し、出力がどのように出力されるのかを確認することをお勧めします。ような何か：

SELECT p.*, c.* 
FROM agg_pivot_test p LEFT JOIN jd_cleaning c 
    ON c.Formerly = IIF(c.Formerly LIKE '*or*', '*' & p.LyFinalCode & '*', CStr(p.LyFinalCode)) 
WHERE p.CyFinalCode IS NULL AND c.Formerly IS NOT NULL 

私も変更提案に傾いている "... & p.LyFinalCode & ..." と "... & CStr関数（p.LyFinalCode）& ..." - しかしなぜそれが違いを生むべきか私は本当に見ることができません。

私は少し参加変更される示唆して考えることができる唯一の他の事：（必ずしも優れていることが保証され、このありえない - それはあるかもしれないが）あなたの文の構文を考える

UPDATE agg_pivot_test AS p LEFT JOIN jd_cleaning AS c 
    ON (c.Formerly = CStr(p.LyFinalCode) OR InStr(c.Formerly, CStr(p.LyFinalCode)) > 0) 

を（、IこのSQLがODBCを介してアクセスされていると仮定します;この場合、これはうまくいくはずです.SQLがサーバ側で実行されている場合、InStrをSubStringに変更する必要があります）