「処理に失敗しました.他のユーザか処理によってレコードが変更されています」について
皆様、よろしくお願いいたします
・NG現象を記します
オンラインプログラムにてバックタスク（サブ）をCALLしデータ更新行っているのですが
３ヵ月に１度位のペースで下記エラーが発生しデータ更新が正しく行われません
「処理に失敗しました.他のユーザか処理によってレコードが変更されています.データソース: ・・」
・環境概要を記します
サーバーはオンプレミスです（Windows Server 2012R2）
クライアントはWindows 10Pro. 64bitです
データベースはMicrosoft SQL Server2017 64bitです
・プログラム概要を記します
オンラインタスクのトランザクションモードはD=遅延です
バッチタスク（サブ）のトランザクションモードはＷ=親と同一です
・お願い
エラーが発生する原因やアドバイス等、ご教示頂ければ助かります
以上、よろしくお願い申し上げます。
-
こんにちは Puです
便乗質問で申し訳ありません。
RIAでもないオンラインタスクでトランザクション＝遅延を使う目的ってなんなんでしょうか？
後学の為お教え頂ければと
でわ～でわ～
-
ISHIJIMA様
早速のご教示ありがとうございます
学習書を一度読んでみます。
-
> 「処理に失敗しました.他のユーザか処理によってレコードが変更されています.データソース: ・・」
このメッセージはですね、エラーというよりアドバイスというような感じのメッセージです。
その文面にありますように、データベースに更新内容を書き込もうとしたら、途中で誰かが割り込んでデータを更新していたから、安全のために上書き更新をやめておくね！といった感じの内容です。
もっと厳密に言うと、遅延トランザクションにおいては最初にMagicキャッシュにオリジナルデータを読み込んだあと、データを編集してDBに上書き更新を行う前に、もう一度DBからオリジナルデータを再読み込みして、それが最初にキャッシュに入れたデータと同じものであったかどうかを判定します。同じであることが確認されれば安心して上書き更新しますが、異なっていた場合は他の誰かが、あるいは他のタスクのどれかが作業の途中で割り込んでデータを更新しているから、安全のために上書き更新は止めておくね！といった感じの流れになるわけです。
このあたりの理屈は、マジック社が主催している「Magic xpa RIAトレーニングコース」を受講するとよく分かりますよ。RIAでなくても、クラサバでも理屈は同じです。
-
> RIAでもないオンラインタスクでトランザクション＝遅延を使う目的ってなんなんでしょうか？
オンラインタスクのデフォルト設定が「遅延」になっているからだと思います。「物理」はDBが持つトランザクションをMagicからコールしているだけでして、「遅延」はMSEが独自に開発した進化したトランザクションだからですね。
「物理」はせいぜい数十人が限度のトランザクションですが、「遅延」は数万人のインターネット環境でも対応できます。
-
こんんちは Puです
C/S環境で数万人って考えられませんので
やはりRIA等、インターネット環境での利用でしょうね
でわ～でわ～
-
> C/S環境で数万人って考えられませんので
> やはりRIA等、インターネット環境での利用でしょうね
PuさんのあとにISHIJIMAさんがおっしゃっている通りです。「物理」だと、放置が原因がで永久ロックになってしまうケースがありますし、「ロックしているのは誰だ！手を挙げろ！」と叫べば済む範囲内でのアプリになりますが、ユーザ数が数十人を超えてくると、「手を挙げろ！」では済まなくなってきます。
「数万人」と書いたのは、理解を深めてもらうための拡張表現です。「数百人」と表現すればその差異が分かりにくいですからね。
-
> それを考えると遅延はよくできています
「遅延」が出たばかりの頃はそれを嫌う人が多かったようですが、ここに来てやっとその良さが理解され始めてきたようですね。
私も、RIA、クラサバを問わず「遅延」を推奨しています。
-
さらに補足です。
Btrieveの頃は「レコード単位の排他」しかできませんでしたので「物理」がメインでしたが、SQL系列は「カラム単位の排他」ができますので「遅延」が最適であるとも言えます。これについても、マジック社主催の「Magic xpa RIAトレーニングコース」でその理由を懇々と説明しています。RIAトレーニングの教材は本当によくできていると思います。
-
私はクラサバでは物理トランザクションしか使っておりませんが、今回のスレッド勉強になりました。
ちなみにINIファイル、SpecialDefaultTransactionMode = P を有効化して開発しております。
Web系だと、編集に入ります！の動作の後、編集に入る作りが多いような気がするのですが
編集に入ります！の時に、排他情報でも作っているのだろうな、と想像したりします。
排他情報が1時間前から消えていない分は、バッチで定期的に消すなど必要なのですかね。私は伝票入力系は、編集に入る際は、排他情報を作成しております。
Lock関数をうまく活用すれば、排他情報データを作る必要も無いのでしょうけど
Lock関数は伝票編集排他では活用しておりません。
あるRIAのシステムで、同じ伝票を二人で同時に編集で呼び出せたので、あれれ？と思いましたが
保存する際に、他で編集されていたので、キャンセルします、といったメッセージが表示されるのか
また試してみたいと思います。
同時に同じ伝票を編集する事が稀だとすれば、遅延をうまく活用するのは有りなのでしょね。
（まだ活用していませんけども。）
-
> RIAトレーニングの教材は本当によくできていると思います。
この教材を作ったと思われるマジック社のWさんは、本当に優秀な技術者ですね。尊敬しています。
-
ISHIJIMA様
E=イベント 式 Idle() >= 12000 ・・・20分放置したら
イベント実行 取消終了
等を伝票入力PGなどに組み込むのもいいのかもしれないですね。
（これはやった事ありません。）
-
> 同時に同じ伝票を編集する事が稀だとすれば、遅延をうまく活用するのは有りなのでしょね。
「レコード単位の排他制御」という概念から離れて、「カラム単位の排他制御」という視点から見ると、時代が変わってきますよ。RIAのトレーニングの教材の中で懇々と説明されています。
-
子供会のデータがあったとして、
Ａさんは 小学校 という値を 中学校 へ変更。
Ｂさんは同じタイミングで同じレコードを ５年生 という値を ６年生 へ変更。
中学校６年生といった保存になる事もありうるのですか？
（カラム単位の排他制御を知らないので、私は学習が必要です。）
-
> （カラム単位の排他制御を知らないので、私は学習が必要です。）
私も「カラム単位の排他制御」というのを、Magic V10がリリースされた13年くらい前に初めて知ったときは、目からうろこでした。
-
こんんちは Puです
なるほど勉強になりました。
遅延便利ですね。
WEBアプリの場合カラムに更新日付と更新時間を持たして
UPDATE時変更前と比較するロジック記述していますが
Magicの遅延はMagicエンジンがやってくれるので生産性あがりますね。
おまけにメッセージまで出力してくれるし、至れり尽くせり。
でわ～でわ～
-
Puさん、まさか提灯を掲げたわけじゃあないですよね？笑
大阪は吉村知事が優秀でうらやましいです。
-
丹田さん、いえいえ
遅延が出た時、.netのDATASETの考えに近いなぁと感心していまして
遅延=RIAと言う固定概念でした(^^;
c/sのオンラインタスクで遅延は目から鱗でした。
>大阪は吉村知事が優秀でうらやましいです。
ありがとうございます。たこ焼き食べに来てください。
でわ～でわ～
-
tanda様
ありがとうございます
とても分かりやすかったです
感謝しております。
サインインしてコメントを残してください。
コメント
18件のコメント