ファイルの共有更新

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

9329	ファイルの共有更新	ezer	2001/01/14-17:21
はじめて投稿致します。Ｖ４から桐を使い初めて現在Ｖ８に移行中です。ファイルサーバーを９８ＳＥにてクライアントを１０台くらいでのシステムを考えています。実は共有更新、共有参照のところで詰まっています。最初はすべてのクライアントで共有更新でデータを開くことで考えていました。しかしデータの整合性を考えてファイルがもし未使用の場合はファイル共有更新で開きもし使用されていたら共有参照で開くとゆうようなシステムに考えました。がもしクライアントA,Bとあった場合　Aが共有更新で開いている場合Bは共有参照で開く、そしてAがファイルを閉じもう一度開こうとした場合共有更新では開けず共有参照になってしまいます。それで、教えていただきたいのですがメニューフォームの中にファイルが使用中か未使用がわかる様な形に変えようかと思っています。その場合ファイルが使用中であった場合使用中のクライアントにファイルを閉じてもらう様なメッセージ送り、そしてそのファイルを共有更新で開くようなシステムを考えているのですが可能でしょうか。よろしくお願いいたします。
9330	Re:ファイルの共有更新	KH	2001/01/14-21:47
記事番号9329へのコメント >ファイルサーバーを９８ＳＥにてクライアントを１０台くらいでのシステムを考え >ています。 >実は共有更新、共有参照のところで詰まっています。 >最初はすべてのクライアントで共有更新でデータを開くことで考えていました。 >しかしデータの整合性を考えてファイル・・・ ezerさんは今晩は。「整合性を考えてファイル・・・」のところがよくわかりません。共有更新モードでひらいている表を共有参照で開く意味はなんですしょうか。確認のためしか使えまないと思うのですが。ここの整合性がちょっとよく把握できません。全て共有更新でもレコードロックがかけられますので入力に問題はないと思いますが。かえって難しくしていませんでしょうか。私はネットワーク上で桐の表データを開く場合、一括処理の中で、専有で開くか、共有更新で開くかを先に選択させて、開くようにしています。ですからその表ファイルに最初に専有で開いた人がいれば、その後は共有で開く人がいたり、逆に共有更新で開いているのに、専有で開こうとした場合、全てエラーメッセージで開けない趣旨のメッセージを表示し他のユーザーが終了するまでお待ちくださいと表示させています。終了状態で１でない場合（表が正常に開けない場合）をエラー表示用名札に分岐させています。終了状態の所は思っていたより実際は細かく状態を拾えなっかったような気がします。で、大雑把な終了状態の処理しかしていませんけど。なお、共有・専有を調べても、共有更新、共有参照を分けて調べる関数はないような気がしましたし、この関数は今開いている表データを調べるもので、ファイル一覧にある任意のファイルを開かないで調べるものではなかったような気がしましたが。　私もここのところは昨年大分苦労しました。以外なことに関数でも、一括コマンドでも大雑把な表の共有状況しか把握できなくて困ったたような記憶が残っていますが。
9331	ＫＨさんありがとうございました。	ezer	2001/01/15-01:16
記事番号9330へのコメントＫＨさん意味不明な質問に丁重にお答え下さりありがとうございます。又、意味不明な質問になるかも知れませんがよろしくお願いいたします。早速ですが >「整合性を考えてファイル・・・」のところがよくわかりません。共有更新モー >ドでひらいている表を共有参照で開く意味はなんですしょうか。確認のためしか >使えまないと思うのですが。ここの整合性がちょっとよく把握できません。全て >共有更新でもレコードロックがかけられますので入力に問題はないと思いますが。 >かえって難しくしていませんでしょうか。共有参照で開くのは顧客からの電話に確認のためです。共有更新で複数のクライアントが入力した場合ファイルには受注NOの項目がありたとえば　東京商店の場合　TO0009 の様な番号をその最終NOを確認し連番で何個か入力していきます。しかし何番まで入力するのか解らないため他のクライアントは共有参照で開く事にしました。それはファイルを専有で開きその終了状態によって１ならば共有更新で開き１以外ならば共有参照で開くとゆう一括を書きました。その場合一度共有更新で開き他のクライアントが共有参照で開いていた場合ファイルを閉じもう一度開くときに共有更新では開けなくなるとゆう困った問題があります。共有参照か共有更新で開いている状態を調べる関数なないのでファイルが開かれていた場合メニューにて共有更新、共有参照を選択し入力しなければならないかな？と思っていました。そのときにファイルを使用中のクライアントにメッセージを表示出来る方法がないのかと思った次第です。なおこの様な場合ファイルをロックをどの様に使えばよいのかも解りません。どなたか御指導下さいますようお願い致します。
9332	表の共有参照	佐田　守弘	2001/01/15-02:05
記事番号9331へのコメント ezerさん私も一部分からない部分がまだ残っておりますが、一般論的にお答します。 ezerさんの様なケースでは、常に共有更新で表を開くのが原則的な方法と思います。参照のためだけに更新を許可しないモードで開かせる必要があるのかどうか、このあたりは私も良く分かりません。 >共有参照で開くのは顧客からの電話に確認のためです。との事ですが、その担当者が更新する事はあり得ない（更新を許可しない）という事なのでしょうか。後は一般論ですが ●レコードロックとファイルロックレコードロックなどは桐がシステムとして行ってくれます。あるクライアントAがあるレコードaの編集に入ると、他のユーザーはそのレコードの編集（正しくは更新）ができなくなります。そしてAが別のレコードに移動すれば、その直後に他のユーザーがそのレコードaの更新ができる様になります。この様に、レコード単位で早いもの勝ちで、レコード単位で一人だけが編集を許可される仕組みがレコードロックです。これ以外にトランザクション関連のコマンドがあり、そのトランザクションを開始してから終了するまでの間、データが(多分ファイル単位で)ロックされます。また、置換コマンドの様に表全体にわたる処理を行う時には、その処理中はファイル全体がロックされます。この様に、レコード、ファイル全体のロックは、桐によって自動的に行われます。 ●ロック関連のコマンドこれは、処理対象行をロックしたり解除するコマンドです。原則的にはデータを見ているだけならば、ロックする必要はありません。しかしながら何らかの必要で、表のあるレコード(複数可能)を他のクライアントから更新されては困る時に、使います。 ●受注NO これは手入力で番号を決めているのでしょうか。通常は、桐に自動的に番号を発生させるのが良いと思うのですが。例えば「東京商会」のデータを５件入力したいが、連番号にしなければならない。もし他のユーザーが東京商会を入力すると、番号が割り込まれてしまう。そんな理由ですか？状況は良く分かりませんが、連番号でなければならない理由は元来ないと思うのですが。受注NOの付け方も含めて、このあたりのシステム設計の点で何か無理をしている所があり、見直すべき点がある様な気がするのですが。例えば伝票１枚分に相当する５件のデータなど、１まとまりのデータであっても、受注番号は単なる連番でよいはずだと思うのですが。その５件分が外観上で連続して見えればよいし、必要なら印刷のための連番号は後から付けてもよい訳です。佐田守弘(KS-00119)
9333	佐田先生ありがとうございました。	ezer	2001/01/15-03:29
記事番号9332へのコメント佐田先生　遅くまでご苦労様です。そしてありがとうございました。レコードロックの件よく分かりました。先生の説明のおかげで問題点がはっきりしました。受注NOの付け方が問題ではないのかなと思われます。本当は自動的に受注NOを付けるべきなのでしょうが、現在項目数が２５５項目使っておりDOS版では項目数が増やせず困っていました。その為に受注NOは手入力になっていました。（わたし表定義をしていない表なのでなるべく変更をしないで済ませていました。） WIN桐８に移行するに当たり本腰を入れてシステムの見直しをする気持ちが出てきました。これからもよろしくお願いいたします。佐田先生こんなに遅くまでお仕事なんですね。お体を大切に！わたしは今日は徹夜になりそうです。　まずはお礼まで。

戻る