RIAのレコードレベルでのサーバへのアクセスについて
- このフォーラムに新しいトピックを立てることはできません
- このフォーラムではゲスト投稿が禁止されています
cotoapli
投稿数: 25
投稿数: 25
RIAのプログラムについてですが、もともとオンラインプログラムでレコードレベルで採番する仕組みがあったのですが、ＲＩＡになるとレコードレベルでサーバの採番ファイルを更新するようなロジックは、エラーになりますよね。ＲＩＡだけに理屈は分かるのですが、回避策が思いつきません。皆さんはレコードレベルでサーバへのアクセス講師が必要な場合は、どのようなロジックを採用されていますか？
障害ではないのですが、どなたかご教授頂けますでしょうか。
よろしくお願いします。
障害ではないのですが、どなたかご教授頂けますでしょうか。
よろしくお願いします。
投票数:0
平均点:0.00
nobukoshi802
投稿数: 118
投稿数: 118
採番テーブルに対しては、Stored Procedureを使用しています。
遅延更新の場合のレコードレベルの更新では、更新回数という項目で
更新前に更新回数の値を取得しておきます。
更新時に更新回数の値を比較して同一なら更新を行います。
（この時に更新回数を＋１して更新します）
違う場合は、他のユーザーが更新をしたので、更新はしないように
しています。
遅延更新の場合のレコードレベルの更新では、更新回数という項目で
更新前に更新回数の値を取得しておきます。
更新時に更新回数の値を比較して同一なら更新を行います。
（この時に更新回数を＋１して更新します）
違う場合は、他のユーザーが更新をしたので、更新はしないように
しています。
投票数:0
平均点:0.00
cotoapli
投稿数: 25
投稿数: 25
nobukoshi802さん
ご回答ありがとうございます。
ちなみになんですが、おっしゃっているロジックの仕組みはわかるのですが、もし、更新されていたら、他のユーザーが更新をしたので、更新はしないようにしてしまえば、この処理そのものをキャンセルされていると言うことですか？つまりは入力しなおしということでしょうか？
ご回答ありがとうございます。
ちなみになんですが、おっしゃっているロジックの仕組みはわかるのですが、もし、更新されていたら、他のユーザーが更新をしたので、更新はしないようにしてしまえば、この処理そのものをキャンセルされていると言うことですか？つまりは入力しなおしということでしょうか？
投票数:0
平均点:0.00
nobukoshi802
投稿数: 118
投稿数: 118
処理そのものをキャンセル、入力しなおしです。
実際、この状態の遭遇確率が少ないので
そんなに困っていないです。
メッセージ表示後、レコード更新後のリレーション保障が
出来るなら、更新も有りです。
最後の更新が有効ってやつですね
入力履歴を保持して、誰が何時更新した履歴照会などで
逃げるという方法も有りだと思います。
実際、この状態の遭遇確率が少ないので
そんなに困っていないです。
メッセージ表示後、レコード更新後のリレーション保障が
出来るなら、更新も有りです。
最後の更新が有効ってやつですね
入力履歴を保持して、誰が何時更新した履歴照会などで
逃げるという方法も有りだと思います。
投票数:0
平均点:0.00