- このトピックには5件の返信、1人の参加者があり、最後に
により2年、 12ヶ月前に更新されました。
-
投稿
-
お世話になっております。
会社は転々としていますが、A5は10年以上愛用させていただいています。今回の症状について、
バグなのか仕様なのか、あるいは設定不足なのかご教示ください。今回、主キーのある品目マスタテーブルm_himmoku(475万件)から
SELECT * FROM m_himmoku WHERE himmoku_cd = ‘94053197-B0’
で検索した結果セットのうち１セルを手で直接編集＋確定処理をさせると
３分ほどハングアップ後、ダイアログ”Update failed. 4324881 records.”の文字と共に
約430万件に対して１セル編集した内容と同じ更新がかかってしまいました。主キーのあるテーブルであれば
本来結果セットを直接編集しても該当レコードしか編集されない想定ですが
主キーあるのに、なぜほぼ全件動こうとしたのか、今後の予防のために何を見ればいいのかをお教え下さい。【環境】
DB：Oracle 19c
A5：Ver 2.17.4【その他切り分けた事】
・同じ操作を再実施・・症状再発
・同僚PCのVer 2.13.0で同じ操作・・発生せず
・同テーブルを別のWhere条件に変更・・症状再発
・同テーブルの別レコード、別カラムを変更・・症状再発
・別テーブルを同じ操作・・発生せず
・オートコミット、Transaction後の操作による違い・・いずれも症状再発。私の環境で、本テーブルへの同じ操作で発生率１００％のまま置いています。
SKさんこんにちは。
おそらく不具合と思うのですが、こちらで現象を再現できていないので確認させてください。
・接続はOCI経由 or 直接接続
・テーブルの主キーは単一カラム？ 複数カラム？
・可能ならば主キーの構成（データ型）を教えてください。
・トリガーなどはないでしょうか？
・テーブルエディタでは発生するのでしょうか？
・テーブルエディタでは主キー項目の背景色はピンク色で表示されていますか？
以上よろしくお願いいたします。回答ありがとうございます。
以下、回答します。 追加の情報で少し長文になってます。すみません。・接続はOCI経由 or 直接接続
⇒OCI経由です。・テーブルの主キーは単一カラム？ 複数カラム？
⇒単一カラムです。・可能ならば主キーの構成（データ型）を教えてください。
⇒NVARCHAR2(12)・トリガーなどはないでしょうか？
⇒ 同スキーマにてトリガーはありますが、本テーブルは関係ありません。・テーブルエディタでは発生するのでしょうか？
⇒試したところ、発生しませんでした。
（[条件を指定して開く]にて同じ項目のみを表示させて同じ操作にて発生せず。
その後、Select文で同じWhere条件での結果セットでは再発を確認。）・テーブルエディタでは主キー項目の背景色はピンク色で表示されていますか？
⇒ピンク色で表示されています。
（結果セットでの表示は黄色です。
結果セットの場合は再現しない他のテーブルも黄色です。）■追加情報
PKの構成確認でいくつか気になる事があったので追加情報です。
本テーブルはCreateTable時にはPKを作っていなかったように見えます。
※本テーブル以外にも同じ法則のテーブルは複数ありましたが。。。【１】
[ソースをSQLで開く]から開いた画面にて、
—————————————————–
CREATE TABLE “XXXX”.”M_HIMMOKU”(
”HIMMOKU_CD” NVARCHAR2(12) COLLATE “USING_NLS_COMP” NOT NULL ENABLE,
中略1
CONSTRAINT “M_HIMMOKU_UK1” UNIQUE (“AAAAA”, “BBBBB”)
中略2
)
中略3
CREATE INDEX “XXXX”.”M_HIMMOKU_IDX1″ ON “K_ESPO”.”M_HIMMOKU” (“HIMMOKU_CD”, “CCCCC”)
中略4
ALTER TABLE “XXXX”.”M_HIMMOKU” ADD CONSTRAINT “M_HIMMOKU_PK” PRIMARY KEY (“HIMMOKU_CD”)
USING INDEX “XXXX”.”M_HIMMOKU_IDX1″ ENABLE
—————————————————–
だいたいのテーブルの場合はPKはCreate文の中に記載がありましたが本テーブルはalter tableで表示されていました。【２】
↓ テーブルエディタを開いた後の[インデックス]タブにて
——————————————-
No|インデックス名|カラムリスト|主キー|ユニーク
1|M_HIMMOKU_IDX1|HIMMOKU_CD,CCCCC|Yes|null
2|M_HIMMOKU_IDX2|略|null|null
3|M_HIMMOKU_IDX3|略|null|null
4|M_HIMMOKU_IDX4|略|null|null
5|M_HIMMOKU_PK|HIMMOKU_CD|null|Yes
6|M_HIMMOKU_UK1|AAAAA,BBBBB|null|制約
——————————————-
※nullは実際の表示は空欄でしたが、曖昧回避のためnullと表記。↓ テーブルエディタを開いた後の[制約]タブにて
——————————————-
No|制約名|種類|制約定義
1|M_HIMMOKU_PK|PRIMARY KEY|HIMMOKU_CD
2|M_HIMMOKU_UK1|UNIQUE|AAAAA,BBBBB
3|SYS_C0027808|CHECK|”HIMMOKU_CD” IS NOT NULL
4|SYS_C0027809|CHECK|”CCCCC” IS NOT NULL
——————————————-インデックスタブではM_HIMMOKU_IDX1がピンク背景
制約タブではM_HIMMOKU_PKがピンク背景後からAlter TableでPrimary Keyの記載のあるテーブルの場合はいずれも[インデックス]タブのPK表記がおかしかったです。
ただ、この法則時のテーブルをSelect文からの更新をかけた場合は再現はしませんでした。（ＰＫが単一カラムなのは問題のテーブルだけで他は複数カラムという違いはありますが、、）テーブルによってＰＫがこうなっている状況について構築当時の情報はほとんどなく、現状のテーブル設計書は手元にあるものの当時のCreateTableの原文はわからないです。
ただ他に必要情報あれば現行情報はなるべく提供したい所存です。SK さんこんにちは。
詳細な情報ありがとうございます。ただ、現状再現できていません。DB接続ライブラリのソースコードをみても、少なくともWHERE句なしのUPDATE文が生成されるようなことはなさそうです。 Version 2.18.0 beta 30で内部的な更新のSQLをログファイルに出せるようにしてみました。
A5M2.exe と同じフォルダに、A5M2.log というからファイルを作成すると、内部的なログファイルを出力するようになります。
お試しいただき、どのようなUPDATE文が生成されるか（意図されたSQLが生成されるか）確認できますでしょうか？回答ありがとうございます。
64bit版の2.18.0 beta30を使ってみました。
・そもそも症状が発生しませんでした。
・ちなみにA5M2.exeと同じ階層にA5M2.logを空フォルダで作成しましたが、特に何も書き込まれませんでした。（更新日時も変わらず）ログに関してオプション設定など何か必要でしょうか。
私の環境はWin10 21H2です。（自動でトランザクションを貼る設定以外は初期値です）切り分けで 2.17.2 と 2.18.0 beta1 で発生するか見てみますが日が空きますので
いったん上記にてご報告です。
