回答編集履歴
11
追記
test
CHANGED
|
@@ -4,6 +4,8 @@
|
|
|
4
4
|
そうではなく、「一つの更新クエリーについて」の話なら、クエリー内での参照元がクエリーである場合、参照元のクエリーが完結していない状態で結果が表示されることはあります。
|
|
5
5
|
そうなる理由として、例えばクエリーやテーブルを開いた際に、早く開くように、表示されていない部分は遅延する動きと同等な動作をしているのだと推測されます。
|
|
6
6
|
SQLチューニングによる高速化により改善されたように見えたとしても完全ではなく、結局ネットワークの負荷などが生じると発生したりします。
|
|
7
|
+
※そもそも、リンクテーブルを参照し結合した場合に有効なインデックスはリンクテーブルそのものに設定する疑似インデックスです。
|
|
8
|
+
SQLServerでのインデックスの効果を得られるのは、パススルークエリーです。
|
|
7
9
|
|
|
8
10
|
回避策としては、
|
|
9
11
|
A.更新クエリー経由ではなく、直接DBを更新する
|
10
推敲
test
CHANGED
|
@@ -3,6 +3,7 @@
|
|
|
3
3
|
|
|
4
4
|
そうではなく、「一つの更新クエリーについて」の話なら、クエリー内での参照元がクエリーである場合、参照元のクエリーが完結していない状態で結果が表示されることはあります。
|
|
5
5
|
そうなる理由として、例えばクエリーやテーブルを開いた際に、早く開くように、表示されていない部分は遅延する動きと同等な動作をしているのだと推測されます。
|
|
6
|
+
SQLチューニングによる高速化により改善されたように見えたとしても完全ではなく、結局ネットワークの負荷などが生じると発生したりします。
|
|
6
7
|
|
|
7
8
|
回避策としては、
|
|
8
9
|
A.更新クエリー経由ではなく、直接DBを更新する
|
|
@@ -11,6 +12,5 @@
|
|
|
11
12
|
B.参照元のクエリーをテーブルに落とし込み、データを物理的に確定させ、その結果を参照するようにする。
|
|
12
13
|
※クエリー内で参照しているクエリーを展開して、一つのクエリーにしても改善しなかったと記憶しています。
|
|
13
14
|
※ネストが無いようにSQLを書き換える事が可能なら改善するかもしれませんが、集計があったりすると処理的に書き換え出来なかったりします。
|
|
14
|
-
※チューニングによる高速化により改善されたように見えたとしても完全ではなく、ネットワークの負荷などが生じると発生したりします。
|
|
15
15
|
|
|
16
16
|
A案推奨です。
|
9
推敲
test
CHANGED
|
@@ -5,7 +5,7 @@
|
|
|
5
5
|
そうなる理由として、例えばクエリーやテーブルを開いた際に、早く開くように、表示されていない部分は遅延する動きと同等な動作をしているのだと推測されます。
|
|
6
6
|
|
|
7
7
|
回避策としては、
|
|
8
|
-
A.クエリー経由ではなく、直接DBを更新する
|
|
8
|
+
A.更新クエリー経由ではなく、直接DBを更新する
|
|
9
9
|
[【MS Access】パススルークエリからストアドを実行したりUPDATE文を実行する方法](https://www.depthbomb.net/?p=6249)
|
|
10
10
|
|
|
11
11
|
B.参照元のクエリーをテーブルに落とし込み、データを物理的に確定させ、その結果を参照するようにする。
|
8
追記
test
CHANGED
|
@@ -11,5 +11,6 @@
|
|
|
11
11
|
B.参照元のクエリーをテーブルに落とし込み、データを物理的に確定させ、その結果を参照するようにする。
|
|
12
12
|
※クエリー内で参照しているクエリーを展開して、一つのクエリーにしても改善しなかったと記憶しています。
|
|
13
13
|
※ネストが無いようにSQLを書き換える事が可能なら改善するかもしれませんが、集計があったりすると処理的に書き換え出来なかったりします。
|
|
14
|
+
※チューニングによる高速化により改善されたように見えたとしても完全ではなく、ネットワークの負荷などが生じると発生したりします。
|
|
14
15
|
|
|
15
16
|
A案推奨です。
|
7
推敲
test
CHANGED
|
@@ -10,5 +10,6 @@
|
|
|
10
10
|
|
|
11
11
|
B.参照元のクエリーをテーブルに落とし込み、データを物理的に確定させ、その結果を参照するようにする。
|
|
12
12
|
※クエリー内で参照しているクエリーを展開して、一つのクエリーにしても改善しなかったと記憶しています。
|
|
13
|
+
※ネストが無いようにSQLを書き換える事が可能なら改善するかもしれませんが、集計があったりすると処理的に書き換え出来なかったりします。
|
|
13
14
|
|
|
14
15
|
A案推奨です。
|
6
推敲
test
CHANGED
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
ラグというのが、「複数の更新クエリーを実行し、それぞれのクエリーが前のクエリーの結果を参照している」という事に対してのものなら、
|
|
2
2
|
クエリーの実行を、非同期型の`DoCmd`ではなく、同期型の`Execute`を使用して下さい。
|
|
3
3
|
|
|
4
|
-
そうではなく、「一つの更新クエリーについて」の話なら、クエリーの参照元がクエリーである場合、参照元のクエリーが完結していない状態で結果が表示されることはあります。
|
|
4
|
+
そうではなく、「一つの更新クエリーについて」の話なら、クエリー内での参照元がクエリーである場合、参照元のクエリーが完結していない状態で結果が表示されることはあります。
|
|
5
5
|
そうなる理由として、例えばクエリーやテーブルを開いた際に、早く開くように、表示されていない部分は遅延する動きと同等な動作をしているのだと推測されます。
|
|
6
6
|
|
|
7
7
|
回避策としては、
|
5
推敲
test
CHANGED
|
@@ -1,8 +1,7 @@
|
|
|
1
1
|
ラグというのが、「複数の更新クエリーを実行し、それぞれのクエリーが前のクエリーの結果を参照している」という事に対してのものなら、
|
|
2
2
|
クエリーの実行を、非同期型の`DoCmd`ではなく、同期型の`Execute`を使用して下さい。
|
|
3
3
|
|
|
4
|
-
そうではなく、「一つの更新クエリーについて」の話なら、クエリーの参照元がクエリーである場合、
|
|
4
|
+
そうではなく、「一つの更新クエリーについて」の話なら、クエリーの参照元がクエリーである場合、参照元のクエリーが完結していない状態で結果が表示されることはあります。
|
|
5
|
-
参照元のクエリーが完結していない状態で結果が表示されることはあります。
|
|
6
5
|
そうなる理由として、例えばクエリーやテーブルを開いた際に、早く開くように、表示されていない部分は遅延する動きと同等な動作をしているのだと推測されます。
|
|
7
6
|
|
|
8
7
|
回避策としては、
|
4
推敲
test
CHANGED
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
ラグというのが、「複数の更新クエリーを実行し、それぞれのクエリーが前のクエリーの結果を参照している」という事に対してのものなら、
|
|
2
2
|
クエリーの実行を、非同期型の`DoCmd`ではなく、同期型の`Execute`を使用して下さい。
|
|
3
3
|
|
|
4
|
-
そうではなく、一つの更新クエリーについての話なら、クエリーの参照元がクエリーである場合、
|
|
4
|
+
そうではなく、「一つの更新クエリーについて」の話なら、クエリーの参照元がクエリーである場合、
|
|
5
5
|
参照元のクエリーが完結していない状態で結果が表示されることはあります。
|
|
6
6
|
そうなる理由として、例えばクエリーやテーブルを開いた際に、早く開くように、表示されていない部分は遅延する動きと同等な動作をしているのだと推測されます。
|
|
7
7
|
|
3
推敲
test
CHANGED
|
@@ -1,5 +1,6 @@
|
|
|
1
1
|
ラグというのが、「複数の更新クエリーを実行し、それぞれのクエリーが前のクエリーの結果を参照している」という事に対してのものなら、
|
|
2
2
|
クエリーの実行を、非同期型の`DoCmd`ではなく、同期型の`Execute`を使用して下さい。
|
|
3
|
+
|
|
3
4
|
そうではなく、一つの更新クエリーについての話なら、クエリーの参照元がクエリーである場合、
|
|
4
5
|
参照元のクエリーが完結していない状態で結果が表示されることはあります。
|
|
5
6
|
そうなる理由として、例えばクエリーやテーブルを開いた際に、早く開くように、表示されていない部分は遅延する動きと同等な動作をしているのだと推測されます。
|
2
推敲
test
CHANGED
|
@@ -1,4 +1,7 @@
|
|
|
1
|
+
ラグというのが、「複数の更新クエリーを実行し、それぞれのクエリーが前のクエリーの結果を参照している」という事に対してのものなら、
|
|
2
|
+
クエリーの実行を、非同期型の`DoCmd`ではなく、同期型の`Execute`を使用して下さい。
|
|
3
|
+
そうではなく、一つの更新クエリーについての話なら、クエリーの参照元がクエリーである場合、
|
|
1
|
-
|
|
4
|
+
参照元のクエリーが完結していない状態で結果が表示されることはあります。
|
|
2
5
|
そうなる理由として、例えばクエリーやテーブルを開いた際に、早く開くように、表示されていない部分は遅延する動きと同等な動作をしているのだと推測されます。
|
|
3
6
|
|
|
4
7
|
回避策としては、
|
|
@@ -9,4 +12,3 @@
|
|
|
9
12
|
※クエリー内で参照しているクエリーを展開して、一つのクエリーにしても改善しなかったと記憶しています。
|
|
10
13
|
|
|
11
14
|
A案推奨です。
|
|
12
|
-
#以前から極力DB(SQLServer)側に処理を寄せた方が良いと提言しているつもりですが、目先の問題に手間が少ない方法を取ってしまうとその対応によって新たな問題が生じてしまい、今回のように沼に嵌ってしまいますよ。
|
1
推敲
test
CHANGED
|
@@ -5,7 +5,7 @@
|
|
|
5
5
|
A.クエリー経由ではなく、直接DBを更新する
|
|
6
6
|
[【MS Access】パススルークエリからストアドを実行したりUPDATE文を実行する方法](https://www.depthbomb.net/?p=6249)
|
|
7
7
|
|
|
8
|
-
B.参照元のクエリーをテーブルに落とし込み物理的に確定させ、その結果を参照するようにする。
|
|
8
|
+
B.参照元のクエリーをテーブルに落とし込み、データを物理的に確定させ、その結果を参照するようにする。
|
|
9
9
|
※クエリー内で参照しているクエリーを展開して、一つのクエリーにしても改善しなかったと記憶しています。
|
|
10
10
|
|
|
11
11
|
A案推奨です。
|