過去の桐井戸端ＢＢＳ　（桐ver.８）

7819	ネットワークでの読み込みコマンドについて	wing	2000/09/27-17:42
一括処理における読み込みコマンドについて、教えて下さい。 桐ver８　sp5を使用しています。 現在、ネットワーク環境で使用するシステムを開発しています。 次のような処理で、読み込みを使用しています。 Ａ.tblを使用した入力フォームＡ.wfmがあります。 Ａ.tblには、Ｃ.tblより、データを読み込んでいます。 処理順序としては、次のようにしています。 　１．表　”Ａ.tbl” 　２．表　”Ｃ.tbl” 　３．絞り込み　（Ｃ.tblを抽出） 　４．読み込み　表，”Ｃ.tbl” 　　　（Ａ.tbl　に　Ｃ.tblの絞り込みデータを読み込む） 　５．ウィンドウ作成　Ａ.wfm 　　　ウィンドウ会話　Ａ.wfm 1台のクライアントで、Ａ.wfmフォームを使用し、データを入力中に、 別のクライアントで、読み込み（上記４）の処理にくると、排他エラーとなってしまいます。 しかし、Ａ.wfmが表示された時点の状態、つまり、編集状態にしていない場合は、読み込むことができます。 「書き出し」は、編集中の表に対しては、実行する事ができないと思い、「読み込み」を使用しました。 「読み込み」は、編集中の表に対しても実行できると考えていました。 私の思い違いなのでしょうか？ もしかして、編集中ではなく、編集表に読み込むことができるという事なのでしょうか？ 現在、排他エラーで、読み込みができない場合は、エラーメッセージを表示して対処していますが、 他に良い方法はないでしょうか？ どなたか良い方法がありましたら、教えて下さい。 宜しくお願いします。
7823	これは排他エラーにならざるを得ません	佐田　守弘	2000/09/27-19:38
記事番号7819へのコメント wingさん 読み込みコマンドの時に排他エラーとの事ですが、おそらくこれは致し方ないと思います。 桐は共有更新の機能はありますが、レコード単位でのロックで共有更新が可能な処理は限定されます。 一般的な入力と編集は、共有が可能です。 しかし、表全体に対して何か行う様な作業では、表全体をロックしない限り、その操作が行えません。 表全体にわたる処理とは、項目置換、読み込みなど、再定義などがあります。 分かりやすいので項目置換で説明すれば、項目置換は全行を対象に処理が行われます。 置換の途中で別の人が値を更新しようとしたら、両者の処理がバッティングしてしまいます。 ちょうど、二階に上がる時に掛けた梯子を外された様な事になります。 ですから、表のデータ全体に渡る処理を行う時には、自動的に他のユーザの利用を制限したり、 他のユーザが編集中には行えないようになるはずです。 佐田守弘(KS-00119)
7824	Re:読み込みコマンドについて	MIT	2000/09/27-19:40
記事番号7819へのコメント wingさん おひさしぶりです。 >1台のクライアントで、Ａ.wfmフォームを使用し、データを入力中に、 >別のクライアントで、読み込み（上記４）の処理にくると、排他エラー >となってしまいます。 読み込み時にエラーとの事ですが，ご説明にあった表は「共有モード」で開いていますか？ 桐の表コマンドではモードを省略した時は「専有モード」で開くと思います。 共有モードで開く時は 表　"＊＊．ＴＢＬ",モード=共有更新 と表の名称の後にカンマで区切ってモードを指定します。 もし的外れな説明であればお許し下さい。MIT
7826	Re:読み込みコマンドについて	wing	2000/09/27-19:49
記事番号7824へのコメント MITさん おひさしぶりです。 ご回答、ありがとうございます。 >読み込み時にエラーとの事ですが，ご説明にあった表は >「共有モード」で開いていますか？ 表は、共有更新で開いています。 モードを省略して書いてしまいました。 １台で入力作業をしている場合に、別のクライアントで入力作業ができないのでは、 作っているシステムの意味がなくなってしまいます。 良い方法はないでしょうか？
7828	Re:読み込みコマンドについて	MIT	2000/09/27-20:04
記事番号7824へのコメント 先の投函は完全に間違いです。流して下さい。 共有テーブルのデータを読み込んでローカルテーブルを編集すると勝手に解釈しておりました。 共有する２テーブルで一方のデータを他方へコピーするのは入力を簡略化するためでしょうか？ これを実現する手法として例えば １．各クライアントに同じ構造を持つ作業テーブルを用意する ２．共有テーブルで絞り込みされたデータを作業テーブルへ読み込む ３．この作業テーブルで編集（フォームをこのテーブルで使います） ４．更新した内容をもう一方の共有テーブルに追加 などでしょうか。こちらを参考として下さい。MIT
7829	Re:これは排他エラーにならざるを得ません	wing	2000/09/27-20:09
記事番号7823へのコメント 佐田さん、ご回答ありがとうございます。 >読み込みコマンドの時に排他エラーとの事ですが、おそらくこれは致し方ないと思 >います。 そうですか、仕方ないのですか。 >表のデータ全体に渡る処理を行う時には、自動的に他のユーザの利用を >制限したり、他のユーザが編集中には行えないようになるはずです。 現在、作成しているシステムは、ネットワークで共有使用することを前提とし、作成しています。 複数のクライアントで、同時に処理するのは不可能という事になってしまうのでしょうか？ >Ａ.tblを使用した入力フォームＡ.wfmがあります。 >Ａ.tblには、Ｃ.tblより、データを読み込んでいます。 > >処理順序としては、次のようにしています。 >　１．表　”Ａ.tbl”　（ワークテーブル） >　２．表　”Ｃ.tbl”　（マスターテーブル） >　３．絞り込み　（Ｃ.tblを抽出） >　４．読み込み　表，”Ｃ.tbl” >　　　（Ａ.tbl　に　Ｃ.tblの絞り込みデータを読み込む） >　５．ウィンドウ作成　Ａ.wfm >　　　ウィンドウ会話　Ａ.wfm 画面に設定しているテーブルは、ワークとしてのテーブルです。 Ｃ.tblが、マスタテーブルとなっています。 なぜ、Ｃ.tblをＡ.tblに読み込んでいるかというと、フォームに戻すボタンを設定しているからなんです。 戻すボタンが押された時に、Ａ.tblのデータを削除し、再度、Ｃ.tblより、 データを読み込み、編集対照データを編集前に戻すということをしています。 このような処理を排他エラーにならないよう、処理する事は可能でしょうか？ なにか良い方法がありましたら、ご回答をお願い致します。
7830	Re:読み込みコマンドについて	wing	2000/09/27-20:21
記事番号7828へのコメント MITさん、早速のご回答、ありがとうございます。 >共有する２テーブルで一方のデータを他方へコピーするのは >入力を簡略化するためでしょうか？ 簡略化が目的ではないのです。 データを編集前に戻す処理を行う為に、フォームに設定しているテーブルはワークテーブルとしているのです。 処理内容は、佐田さんへのご回答に記述させて頂きました。 >これを実現する手法として例えば >１．各クライアントに同じ構造を持つ作業テーブルを用意する >２．共有テーブルで絞り込みされたデータを作業テーブルへ読み込む >３．この作業テーブルで編集（フォームをこのテーブルで使います） >４．更新した内容をもう一方の共有テーブルに追加 この方法が、使用できると一番良いのですが、クライアント側には 作業テーブルを持たせる事はできないのです。 理由としては、客先の意向として、クライアント側にテーブル等は置きたく、 また、クライアント数が多いので、環境を設定する事が難しいとの事なのです。 環境設定、維持は、客先で行う為、客先の意向に沿っての開発する しかないのが現状です。 他に良い方法は、ないのでしょうか？
7838	共有の方法は	佐田　守弘	2000/09/28-01:52
記事番号7830へのコメント wingさん 表の共有とは、サーバ上に表ファイルを置いておいて、同時に複数のユーザが この１つの表に対して読み書きをする事を差します。 この様にしませんと共有での作業にはなりません。 そして、Ａのユーザがaaのデータを更新している時に、同時にＢのユーザがbbの データを更新する事が可能です。 しかし、Ａのユーザがaaを更新している時には、Ｂのユーザーはaaは更新できない、これが共有モードです。 wingさんが行おうとしている方法、つまり１つの表をそれぞれのユーザにコピーし、 ローカルで作業をしたあと、まとめてサーバの共通の表に書き出そうとしたら、データのバッティングは起きませんか？ 仮に、ローカルに落としたデータaaに対して、Ａはaaaと変更し、Ｂはaabと変更したとします。 どちらを採用するのでしょうか。 もっと分かりやすい例でいいます。緑の窓口の様な座席予約を考えて下さい。 入力者Ａは100番の座席を予約します。この時点で他のユーザーには100番の座席が予約済みである事を 伝えなければならないのです。 しかし、言われている方法では、全てのユーザが時間を違えて100番の座席の予約が可能になります。 これは不都合そのものではないでしょうか。 もちろんその方法はある条件に限って不可能ではありません。 �@サーバのデータはローカルには決してコピーしない。 �Aローカルでは単にジャーナルファイルを作成し、１日の仕事が終わったあと、マスタファイルに対して更新を掛ける。 （トランザクション処理で随時行う事も可能） �B複数のユーザが入力するデータは互に独立であり、影響し合わない。 まあ、この様な状況が成り立つなら、不可能ではありません。そして、これは 共有モードでのデータの処理ではなく、古典的な方法です。 これを具体的に言うなら、ＡはＡ支店の売上を、ＢはＢ支店の売上を入力する。 そして互に他の支店の売上の変更は差せないといった場合です。 一番重要なシステムの使い方の状況が伝えられていないので、 どちらのケースに相当するのかの判断が付きません。 このどちらのケースなのかを見て、ローカルにコピーする事が処理として可能かを考えてみて下さい。 佐田守弘(KS-00119)
7840	Re:読み込みコマンドについて	MIT	2000/09/28-02:03
記事番号7830へのコメント wingさん 編集した結果を戻したい時，桐に用意されているコマンドとしては 「トランザクション」ですね。記述例としては ************************************** トランザクション＿開始 **この間に処理内容を記述** ＩＦ＿（今回の編集をＯＫとする条件） トランザクション＿コミット ＥＬＳＥ トランザクション＿ロールバック ＥＮＤ ************************************** という感じになります。（＿はスペースです） ただ私には桐でトランザクションコマンドを実際のシステムで使った実績はありません。 もしこの掲示板をご覧になっている皆様で実際にこのコマンドを使ってシステムを運用されている方がいらっしゃったら wingさんにコメントしてあげて下さい。 無論，もっとすばらしい手法もありましたらよろしくお願い致します。MIT
7841	システム設計をやり直すべきです	佐田　守弘	2000/09/28-02:16
記事番号7838へのコメント 補足です。 >これを実現する手法として例えば >１．各クライアントに同じ構造を持つ作業テーブルを用意する >２．共有テーブルで絞り込みされたデータを作業テーブルへ読み込む >３．この作業テーブルで編集（フォームをこのテーブルで使います） >４．更新した内容をもう一方の共有テーブルに追加 との事ですが、この考え方は一件合理的に見えながらきわめて矛盾だらけのシステム設計ですね。 その矛盾とは、次の通りです。 仮に、一人のクライアントがデータをワークファイルにコピーして編集している間に、 別のクライアントが同じデータの編集に入ったとします。 そして先に編集に入ったＡが書き戻したあと、Ｂも別の値を書き戻すおそれがあります。 これが前回コメントの座席予約の例です。 つまり、複数の入力者間で入力データの矛盾が生じるおそれがあるわけです。 一人がデータの編集を始めたら、そのレコードに対しては別のユーザーの編集を受け付けない。 これがデータの共有と排他制御です。 書き込みによればwingさんはシステムの開発を受託されているように見受けます。 受注時にこの矛盾を見つけて指摘するのがプロの役目と思うのですがいかがですか？ （以上はあくまでもプロの方に対する助言として受け止めて下さい。 素人の方にはこの様な厳しい指摘は致しません） 佐田守弘(KS-00119)
7842	Re:システム設計をやり直すべきです	MIT	2000/09/28-03:01
記事番号7841へのコメント 佐田先生 深夜までご苦労様です。 投函して表示更新してみると早々にコメントされていたので早いレスポンスにビックリしました。 >>これを実現する手法として例えば >>１．各クライアントに同じ構造を持つ作業テーブルを用意する >>２．共有テーブルで絞り込みされたデータを作業テーブルへ読み込む >>３．この作業テーブルで編集（フォームをこのテーブルで使います） >>４．更新した内容をもう一方の共有テーブルに追加 >との事ですが、この考え方は一件合理的に見えながらきわめて矛盾だらけのシス >テム設計ですね。 これを投函したのは私ですので私よりコメントさせて頂きます。 おっしゃる通りです。 ただこれは共有する２テーブルＡ→Ｂへの更新方法を一例としてコメントさせていただいたものです。 不十分なコメントでした。 本来，一貫性を保つはずの共有テーブルを別の複数箇所でコピーして編集すれば一貫性は失われます。 wingさんが希望される処理は時系列より「編集結果の有効／無効を制御したい」かな？ と今は理解しております。 >受注時にこの矛盾を見つけて指摘するのがプロの役目と思うのですがいかがで >すか？ そうですね。正にプロたる所以はプログラム的なテクニックではなく必要にして十分な表（テーブル）と その構成を考える能力に尽きるのだろうと思います。 MIT
7845	Re:読み込みコマンドについて	wing	2000/09/28-11:25
記事番号7840へのコメント MITさん、佐田さん、早々のご回答、ありがとうございます。 クライアント側にテーブルを持たせる事は、佐田さんのおっしゃる通りだとおもいます。 私は、設計の経験が今回が初めてのため、とても勉強になるご回答を頂き、感謝しております。 MITさんにお察し頂いたとおり、「編集結果の有効／無効の制御」をしたいのです。 ご回答を頂いた”トランザクションコマンド”を使用して作成してみたいと思います。 ご丁寧なご回答を頂き、感謝致します。 今後とも、宜しくお願いします。
7847	Re:読み込みコマンドについて	みすず	2000/09/28-11:52
記事番号7830へのコメント 複数行まとめて更新、まとめて復元とするとたちまち破綻しますね。 トランザクションを利用しようにも、トランザクション中は他のユーザの変更点が反映されません。 他のユーザが変更した部分はレコードロックがかかりコミットするまで解除されないので 少なくとも、最新情報では無いという事はわかりますが不便です。 １レコード毎に確定かキャンセル&復元かを考えてはいかがでしょうか？ そうすればワークファイルに書き出す必要もありません。 もし伝票のようなものを一括キャンセル&復元とかするとなると、やはりトランザクションを使うしかないか、 共有更新を使わず専有＆参照だけで無理矢理実現するか・・
7855	Re:読み込みコマンドについて	みすず	2000/09/28-14:04
記事番号7847へのコメント 追伸です。 問題点はどうやら、共有更新で１行でもレコードロック状態にあると読み込みコマンドが使えない、 という部分から来るようですね。 ですが、行追加や行訂正は行えるようなので、読み込みを使用せずに、１行１行ワークの内容を行退避し、 マスタへ行複写してゆくというのはどうでしょうか？ ワークは一時表として、クライアントの一時領域に書き出します。 −−−−−−−−−−−− ・マスタを共有更新で開く ・マスタを絞り込み ・結果をロックコマンドすべてロックし、内容をクライアントの一時領域 　に書き出し ・一時ファイルを編集する （更新時）ワークの行数分以下の処理を繰り返す ・ワークの１行を処理対象行にする。 ・ワークのIDでマスタの１行を検索 ・同一指令が有れば、そこへ行退避。 　なければ行追加して行退避 ・ワークの処理対象行を次の行へ移動する。 　ワークが終端行に達すればワークファイルを削除し、 　マスタのロックをすべて解除 (破棄時) ・マスタのロックをすべて解除し、ワークファイルを削除する。 −−−−−−−−−−−−− 問題点は処理速度ですが、まあ実用可能ではないでしょうか？
7858	Re:読み込みコマンドについて	にせほりかわ	2000/09/28-14:17
記事番号7855へのコメント 技術的にはみすずさんに一票！ 本質的には佐田さんに一票！ やむにやまれぬ運用時にはMITさんにも一票！ まぁ、桐ってそんなソフトですから。 にせほりかわ（旧姓いかすぱげてぃ(^^;）
7861	Re:読み込みコマンドについて	ほりかわしんじ	2000/09/28-15:33
記事番号7858へのコメント お世話様です。 >技術的にはみすずさんに一票！ >本質的には佐田さんに一票！ >やむにやまれぬ運用時にはMITさんにも一票！ > >まぁ、桐ってそんなソフトですから。 > >にせほりかわ（旧姓いかすぱげてぃ(^^;） にせほりかわさん そんなあなたに「上カルビ」１まい！（明日ね）。 ひまなん？ 追伸： 社内用（堀川にも）に正式リリース用のSp6が先ほど配られました。 とりあえず例のやつは問題なく動いてますぞ，兄貴。ではでは。
7863	Re:読み込みコマンドについて	wing	2000/09/28-16:32
記事番号7847へのコメント みすずさん、ご回答ありがとうございます。 >もし伝票のようなものを一括キャンセル&復元とかするとなると、やはり >トランザクションを使うしかないか、共有更新を使わず専有＆参照だけで >無理矢理実現するか・・ データは、伝票形式となります。 一括キャンセルと復元を行いたい為、とりあえずトランザクションを使用して、作成をしたいと考えております。 現在開発している処理は、１クライアントで編集中のレコードに対し、 他クライアントからの編集を受け付けないようにしなくてはなりません。 みすずさんのレスを読み、トランザクションが向いているかなと考えました。 とりあえず、作ってみようと思います。 皆さん、ありがとうございました。
7864	Re:読み込みコマンドについて	にせほりかわ	2000/09/28-16:43
記事番号7861へのコメント こんにちわ。本物のほりかわしんじさん(^^; >ひまなん？ 今日は完全にサボタージュです。追いまくられる現実からの逃避であります。 それに、さすがにそろそろＶ５からＶ８へとシステムを移行させるかななどとも考えていて・・・ ここでお勉強させてもらってます。 >社内用（堀川にも）に正式リリース用のSp6が先ほど >配られました。とりあえず例のやつは問題なく動い >てますぞ，兄貴。ではでは。 ならば、練習がてらにニューバージョンでも・・・(^^; ｐｓ.では明日。しかし、こんなことばかり書いてると幅田さんから 　　　「馬鹿なほりかわ両名に米俵イッピョウ」 　　　投げつけられてしまう。m(__)m
7865	Re:読み込みコマンドについて	みすず	2000/09/28-22:39
記事番号7863へのコメント wingさんは No.7863「Re:読み込みコマンドについて」で書きました。 >データは、伝票形式となります。 >一括キャンセルと復元を行いたい為、とりあえずトランザクションを >使用して、作成をしたいと考えております。 であれば、No.7855の方式でトランザクションを使わず実現可能です。 一括キャンセル、一括確定も行えます。 共有でトランザクションを使うと何かと壁にぶち当たりますので注意です。
7866	一括処理で排他制御をする方法	佐田　守弘	2000/09/29-00:27
記事番号7830へのコメント wingさん 皆様の書き込みなどで、少しずつ状況が分かり始めて来ました。 ただし、まだ１点分からない事として、作ろうとしているシステムが、「座席予約型」なのか、 「売上データ集計型」（ないしは「銀行預金管理型」）なのかです。 実はこれがシステム設計のヘソです。 ここでは難しい方の「座席予約型」を想定しておきます。 現在の桐はレコードロック（表の共有とレコード単位での排他制御）が可能なので、 前回のコメントの様な方法で処理をするか本当です。 あるいは、「売上データ集計型」であれば、トランザクション処理で行うのも１つの方法でしょう。 さて、パソコン上でファイルの共有が登場する以前の時代に、ユーザーが自分自身のシステムで 排他制御をする仕組みを考えた事があります。 今ではカビの生えたアルゴリズムですが、あるいは今回の件に応用できるかとも思いますので、紹介します。 その仕組みとして、共有する表の中に、編集者を入力する項目を新たに作って下さい。 ここにはそのデータを編集するユーザーを識別する情報を書き込みます。 これは、ネットワークのユーザー名でも、ユーザーの氏名でも構いません。 編集するレコード（複数レコードでも可）を編集するに先立ち、[編集者]の値を調べます。 この項目がブランクであれば、誰も編集していないので、ここに自分のユーザー識別情報を書き込み、 編集を始める事を宣言します。 もし他の人の情報が書かれていたら、他のユーザが編集中なので諦めます。 そして、自分の識別コードを記入して他のユーザーの編集を禁止してから、そのレコードをワーク表にコピーします。 この際に、読み込みコマンドを使うのではなく、項目値を変数に読み込み、その変数値をワーク表の項目値に 書き込むといった方法で行います。 そしてワーク表の編集が終わったら、同じ方法で共有のマスタファイルに書き込みます。 書き込みを終えた後、[編集者]に書き込んでおいた自分の識別番号を消して、ロックを解除します。 桐の共有と排他制御は、桐のシステムが行ってくれるのですが、ここに紹介した方法は、 それを使わず、ユーザー自身が一括処理の中で排他制御を管理するといった方法です。 今では時代遅れの方法ですが、或いは質問の主旨には合致するかとも思います。御検討下さい。 佐田守弘(KS-00119)
7867	参考までに当時の記憶をたどって	佐田　守弘	2000/09/29-00:55
記事番号7866へのコメント 前述のコメントで書きました、ユーザーが一括処理で排他制御をする方法を考えた頃の話を思い出してみます。 当時まだネットワークなどがない時代でした。 その頃、ランドコンピュータからリムーバブルな大容量ハードディスク(80MBでしたが当時は大容量)で、 複数ユーザーが同時に使用できるものが発表になりました。 ネットワークはもとより、LexasGearといった共有システムさえなかった時代です。 このディスク装置の紹介記事を当時の月間マイコン誌に書いた際に、考え出した方法です。 当時、編集長と話しながら、「グループコンピューティング」なる概念を考え出したのも、実は私でした。 詳しい事は忘れてしまいましたが、確かこの装置は、ファイル単位での排他制御機能だけは持っていたと思います。 座席予約の様なシステムを念頭に置き、データテーブルとは別に、レコード単位で排他制御を行うための 管理テーブルを持ちます。 そして、あるレコードの書き込み(つまり座席の予約)を行う前に、管理テーブル上の該当するレコードにフラグを立てます。 管理テーブル自身はファイルロックになりますが、フラグを書き込む瞬間だけロックすればよいので、 それ程多い人数でなければ、バッティングする事はないであろうと考えました。 そして、管理テーブルでレコードロックを宣言した後、データテーブルを開いて 該当するレコードを読み出して値の編集などを行います。 データテーブルも読み出しや書き込みの瞬間にはファイルロックを掛けるのですが、 編集している間はロックは解除します。 そうしないと他の人が編集できないからです。 しかしながら、管理テーブルでロックを宣言してあるので、これを使って、他の人が編集しているレコードは、 別の人に編集させないようにできるはず、というのが、その考え方でした。 今は、桐などでもシステムがこういった事を内部的に行ってくれるので、 ユーザーが自分でレコードロックを行う必要はなくなりました。 ただし、今回の質問の様なケースでは、古い考え方ではありますが、 役に立つかもしれないと思い、参考までに紹介させていただきました。 佐田守弘(KS-00119)
7871	Re:読み込みコマンドについて	wing	2000/09/29-10:02
記事番号7865へのコメント みすずさん、ありがとうございます。 >共有でトランザクションを使うと何かと壁にぶち当たりますので >注意です。 具体的にどのような事なのでしょうか。 すみませんが、わかる範囲で、教えて頂けないでしょうか？
7873	Re:読み込みコマンドについて	みすず	2000/09/29-14:40
記事番号7871へのコメント トランザクションを利用して伝票のようなものを一括キャンセルさせようとする場合、 ワークファイルには書き出さないで直接マスタのデータを共有更新で開き、編集させますよね。 で、編集前にトランザクションをかけ、編集後にコミットするとします。 トランザクションがかかった時点で、マスタのすべてのレコードは他のユーザの変更点が反映されなくなります。 他のユーザが変更した部分はレコードロックがかかり開いた自分自身がコミットかロールバックするまで 解放&ロック解除されません。 たとえば、PC１がマスタのトランザクション中に、PC2がマスタのトランザクションを開始した場合・・ PC1がトランザクションをコミットして終了しても、PC2がトランザクション中である間はPC2にとって PC1の変更点は反映しません。 PC1が終了しているかしていないかに関わらず、PC1で変更した部分はPC2か見るとレコードロックされる事になります。 PC2が自分でコミットかロールバックしない限り、PC1でロックされたレコードロックは PC2にとって永久に解放されない訳です。 そうすると、各PCは同時にトランザクションに入ると先に編集を開始した方のレコードは後に編集の開始した方にとって 永久にロック解除されない訳で、都合が悪いような気もしますが・・。 私自身もトランザクションで共有で使う上での定石を知りたいくらいです。すみません。
7874	Re:読み込みコマンドについて	みすず	2000/09/29-15:24
記事番号7873へのコメント 自己レスですが、更新する処理を行うたびに表を開き、 終了後すぐに表を閉じればトランザクションでも行けそうですね。
7875	Re:読み込みコマンドについて	wing	2000/09/29-17:47
記事番号7873へのコメント みすずさん、詳しくご説明を頂き、ありがとうございます。 トランザクションについて、良く理解する事ができました。 トランザクションを利用して一括処理を作成し、動作確認をしてみました。 次のように、更新処理の一括処理に、トランザクションコマンドを組み込んで、作成しました。 １．使用するテーブルを全て開く ２．編集するデータを絞り込む ３．ウィンドウ作成 ４．トランザクション開始 ５．ウィンドウ会話　 ６．その他の処理（処理に応じて、コミット，ロールバックを記述） 　　・フォームの「キャンセル」ボタンがクリックされた場合、 　　　各コマンドが正常終了しなかった場合は、ロールバック 　　・「登録」ボタンがクリックされた場合は、コミット ７．全てのテーブルを閉じる 動作確認をした限りでは、特に問題なくデータが登録され、キャンセルもできました。 ただ、クライアント２台で動作確認をしただけですので、うまくいったのかな？ とも思っています。 トランザクションを利用した一括処理で、テストを重ねて、検証したいと思います。 ありがとうございました。
7876	Re:読み込みコマンドについて	みすず	2000/09/29-18:22
記事番号7875へのコメント >トランザクションを利用した一括処理で、テストを重ねて、検証したいと思います。 私自身もトランザクションの理解が深まりました。 今後活用したいとおもいます。

戻る