過去の桐井戸端BBS (桐ver.5)
10082 遠隔地にあるファイルと同期をとる方法 chisok 2001/03/07-19:53
Windows98SEの桐ver5で顧客名簿管理システムを一括処理で作成しています。
●現状

・本社及び支店A、支店B、支店Cがある。
(支店はそれぞれ遠隔地に所在している。)
・本社及び各支店のコンピューターはWindows98SEを使用し桐ver5がインストールされている。
・通信環境は本社及び各支店すべてTAであり、現状はケーブルやADSL等の高速接続を導入することができない。
・日々、各支店でそれぞれの顧客データの追加、訂正、削除が行われている。
・本店及び各支店のデータを運用する担当者は各自コンピューターに不慣れでワープロソフトや表計算以外の他のソフト
(エクスプローラーを含む)は使えない。
・自分も桐ver8を勉強し直すエネルギーも時間もない。

●目的(要望)

各支店のデータを本社で一元管理し、各支店で編集されたデータを本社でリアルタイムに参照したい。
なおかつ、支店Aで編集された内容を支店B等でも参照することが度々ある。(その逆も)
(以上の要望は、社長の要望でありリアルタイムという部分は断念し多少のタイムラグが発生してもやむを得ないと理解してもらいました。)

●試した方法とそれぞれの問題点

以下に試した方法はすべて、RASSE(DOSプロンプトからダイアルアップ接続ができるフリーウェア)で本社のRASに接続し処理しようと企みました。

【支店側の処理】
1.本社のハードディスクはネットワークドライブの割り当てで「F:」に設定してあります。
2.一括処理ファイルと作業用の”顧客名簿.TBL(中身は空っぽ)”を「C:¥システム」フォルダに作りました。
3.「C:¥システム」の下に「C:¥システム¥仮想サーバー」フォルダを作り、本社と同期をとりたい”顧客名簿.TBL”を作成しました。
(↓ここから一括処理)
4.”C:¥システム¥顧客名簿.TBL”を開いた後
5.一括処理の最初の段階でシステムコマンドのバッチファイルで本社のコンピューターにRASSEで接続し
6.読み込みコマンドで本社の”F:¥システム¥仮想サーバー¥顧客名簿.TBL”を読み込む。
7.読み込みが終了したらRASZAPで回線切断
8.”C:¥システム¥顧客名簿.TBL”の編集が終わったら
9.「6.」と同じく本社のコンピューターに接続
10.”F:¥システム¥仮想サーバー¥顧客名簿.TBL”を開いて
11.「併合 両方」コマンドでまずは、本社の”F:¥システム¥仮想サーバー¥顧客名簿.TBL”の更新データから支店の”C:¥システム¥顧客名簿.TBL”を更新
12.同じく今度は支店の”C:¥システム¥顧客名簿.TBL”の更新データから本社の”F:¥システム¥仮想サーバー¥顧客名簿.TBL”を更新
13.”F:¥システム¥仮想サーバー¥顧客名簿.TBL”を閉じる。
13.”C:¥システム¥仮想サーバー¥顧客名簿.TBL”を開いて「併合 両方」コマンドで更新
14.「7.」と同じく回線切断

以上の方法で本社と支店との同期をとろうとしましたが、おわかりのとおり
この方法だと「7」、「10」、「11」...等の時点で、恐ろしく時間がかかり
(しまいにはタイムアウトエラー?で一括処理終了)、全く実用性がありません。
(ファイルをコピーすると上書きされてしまうし...)

贅沢かもしれませんが処理スピードの面から、LHA等で圧縮したファイルを
(仮に)”C:¥システム¥TMP”フォルダーにコピーした後、解凍してから併合コマンドで同期をとる方法だと
それでも時間がかかるし、それに本社側では3つの支店から送られてきた圧縮ファイルを一括処理起動時に
解凍→併合を3回繰り返さなければならないし。

過去の井戸端(#4203等)も勉強しましたが、いずれも本社からダウンロードする処理のようだし...

何かよいアドバイスがあれば(あきらめろも含む)お願いします。

(長々と書きましたが、説明不足等がありましたらご指摘ください)
10096 Re:遠隔地にあるファイルと同期をとる方法 めあ 2001/03/08-01:54
記事番号10082へのコメント
追加、訂正、削除されたデータのみを本社・支店間でやりとりするようにすれば、
ISDNでも実用的にやりとりできるぐらいのデータ量に抑えることができるかもしれません。

追加、訂正、削除されたデータは一括処理やデータ形式を工夫することで自動的に抽出、反映させることができますし。

10098 Re:遠隔地にあるファイルと同期をとる方法 えむに 2001/03/08-02:11
記事番号10096へのコメント
経験的にはISDNのダイアルアップ接続で、マスタをダイレクトに更新するのは避けた方が良いと思います。
「タイムアウト」を食らうとテーブルが壊れるし。

私もめあさんの様に、追加・訂正・削除のフラグを持った行データのみの送受信で対応させた事があります。
しかも安全性を高める為に各支店別のファイルにしたりと一見理屈では簡単そうでいて、やっかいな気がします。
10100 Re:遠隔地にあるファイルと同期をとる方法 みすず 2001/03/08-08:48
記事番号10082へのコメント
同じような処理を桐5で実現しております。
要望のような処理では、どう工夫した所で、膨大なデータが流れるだけで、実用は難しそうです。
また、支店A、B、Cが同一のレコードを更新した場合、どれを生かすデータなのか判断つきません。
(同一レコードを更新しないなら良いのですが)
例ですが、データがおいてある本社側にPCを別に置き、監視用一括処理を24時間動作させます。
監視用一括処理は、各支店からの要求を受け、代行してデータの送受信を行うシステムにします。
あるフォルダを監視して、テキストファイル「#支店A.読」が生成されたら、
そのファイルの中に書かれているコードを元に、本社データから絞り込みを行い、
レコードロックを行って「$支店A.TBL」を監視フォルダに返します。
支店Aは「$支店A.tbl」が生成されたら、編集処理等を行います。
もしそのデータを更新するのであれば、「$支店A.TBL」と、「#支店A.更」ファイルを生成し、
その中に更新すべきコードNoも記載します。
監視一括処理側では、「#支店A.更」が発見されれば、「$支店A.TBL」を元に、元のデータを更新し、
レコードロックを解除します。
レコードロックはテキストファイル等の生成などで工夫すると良いです。
また強制切断された場合にそなえて、レコードロックのタイムアウトと、
支店起動時の自分のレコードロックファイル残骸削除の処理を入れておくと良いです。
この処理を行うことで、非常に高速に処理を行うことができます。
またクライアントのPCの処理能力にもあまり依存しないのが特徴です。
10104 Re:遠隔地にあるファイルと同期をとる方法 chisok 2001/03/08-13:00
記事番号10098へのコメント
めあさん、えむにさん有り難うございます。

>経験的にはISDNのダイアルアップ接続で、マスタをダイレクトに更新するのは
>避けた方が良いと思います。

おっしゃるとおりです。

>「タイムアウト」を食らうとテーブルが壊れるし。
>

はい、一回壊しました

>私もめあさんの様に、追加・訂正・削除のフラグを持った行データのみの送受信で
>対応させた事があります。

この方法が一番適していると思います。
僕もこの方法を模索していました。

>しかも安全性を高める為に各支店別のファイルにしたりと
>一見理屈では簡単そうでいて、やっかいな気がします。

本当にやっかいなんです。
実は、顧客名簿.TBLは[顧客コード]を通じて
家族情報.TBL
物件情報.TBL



等、7つのTBLとリンクしています。
ってことは、3カ所の支店×7個のTBLに対して処理することになります。

正直言って、あきらめ直前の行き詰まり感があり、わらをもすがる気持ちで質問を投げてみました。

今、冗談抜きで僕が考えているのはジャストシステムのインターネットディスクを利用する方法です。
@本社も含むそれぞれのデータをテキストファイル(k3)で保存し
A一括処理起動時に同期をとる、
B「読み込み k3」で読み込んだ後、編集する
Cテキストファイル(k3)で書き出した後表を閉じる
D一括処理終了時にまた同期をとる。

僕は今までブリーフケースも含めてファイルの同期というものをやったことがありませんので、
この方法でできるかどうかもわかりませんし、まだ試してもいませんが、
みなさまのご意見をお聞かせいただければと思います。

10107 Re:遠隔地にあるファイルと同期をとる方法 chisok 2001/03/08-13:26
記事番号10100へのコメント
みすずさん有り難うございます。

>同じような処理を桐5で実現しております。
>要望のような処理では、どう工夫した所で、膨大なデータが流れる
>だけで、実用は難しそうです。

おっしゃるとおりです。

>また、支店A、B、Cが同一のレコードを更新した場合、どれを生かす
>データなのか判断つきません。(同一レコードを更新しないなら良いのですが)

これは、先に送信されたデータを後から送信されたデータで上書きされてもやむを得ないと妥協していました。
(実際はあまり多くないケースですし、すぐに修正ができますから。)

>例ですが、データがおいてある本社側にPCを別に置き、監視用一括処理を24時間
>動作させます。監視用一括処理は、各支店からの要求を受け、代行してデータの送受
>信を行うシステムにします。
>あるフォルダを監視して、テキストファイル「#支店A.読」が生成されたら、そのフ
>ァイルの中に書かれているコードを元に、本社データから絞り込みを行い、レコード
>ロックを行って「$支店A.TBL」を監視フォルダに返します。
>支店Aは「$支店A.tbl」が生成されたら、編集処理等を行います。もしそのデータを
>更新するのであれば、「$支店A.TBL」と、「#支店A.更」ファイルを生成し、その中
>に更新すべきコードNoも記載します。
>監視一括処理側では、「#支店A.更」が発見されれば、「$支店A.TBL」を元に、元の
>データを更新し、レコードロックを解除します。
>レコードロックはテキストファイル等の生成などで工夫すると良いです。また強制切
>断された場合にそなえて、レコードロックのタイムアウトと、支店起動時の自分のレ
>コードロックファイル残骸削除の処理を入れておくと良いです。
>この処理を行うことで、非常に高速に処理を行うことができます。またクライアント
>のPCの処理能力にもあまり依存しないのが特徴です。

この方法は、「桐ver5についてのノウハウあれこれ」の中の
「ネットワークでレコード単位の排他制御を行いたい」ですよね
あくまで僕の発想の範囲、想像力の範囲ですがこの方法は、LANだと非常に効果的な方法ですが、
ダイヤルアップ接続だと編集レコードを移動して次のレコードを更新しようとする都度、
改めて回線接続処理をしなければならなくなると思います。(つなぎっぱなしだと他の支店が接続不可だし)

えむにさんの下のツリーに書きましたが、インターネットディスクを使う方法を考えたのですが、どうでしょうか?

10117 Re:遠隔地にあるファイルと同期をとる方法 みすず 2001/03/08-17:20
記事番号10107へのコメント
>あくまで僕の発想の範囲、想像力の範囲ですがこの方法は、LANだと非常に
>効果的な方法ですが、ダイヤルアップ接続だと編集レコードを移動して次の
>レコードを更新しようとする都度、改めて回線接続処理をしなければならなくなる
>と思います。(つなぎっぱなしだと他の支店が接続不可だし)

使用頻度にもよりますが、回線接続は無通信時間3分程度で自動的に切れるようにしておいたとして、
連続的に編集してゆけば、回線はつながったままで編集される事になります。
おっしゃるとおりその間は他の支店が接続不可ですね。
各支店毎に専用の回線が有れば、それで解決するのですが。
またはインターネット回線を使用するか。
質問の趣旨では、リアルタイム性は求めていらっしゃらないようなので、
ちょっと的はずれのコメントだったようです。
ただし実際に上記手法を用いて、数十メガバイトのデータに対し、
WAN側から486のボロPCで2,3秒で更新している処理を桐5で実現しております。

>えむにさんの下のツリーに書きましたが、インターネットディスクを使う方
>法を考えたのですが、どうでしょうか?

インターネットディスクって、結局FTPの更新処理のような事をディスクに見せかけて行っているだけですよね?
単にクライアント側に同一のデータを蓄えて置いて、同期を行うと、インターネットディスク上のファイルに
最新日付で上書きする・・だとすると2カ所同時に更新したファイルを同期してしまったら、
桐のデータの場合、最後に更新した支店のデータが優先になってしまい
他の支店が更新したレコードまで戻ってしまう可能性があるような気がしますけど。
(インターネットディスクの詳しい仕様はわかりませんが。)

同一の表を同時に更新する以上、本来はレコードロックのような概念は絶対に必要になってきますが、
各支店の最新の更新レコードで無条件で上書きでよろしいのでしたら、
各支店の更新された内容(レコード毎の更新日時入り)のみを、圧縮等をしてからダイアルアップして送り、
本社側の監視一括処理に更新を行わせ、正常終了の結果をもらって回線切断 という流れが一番速いと思います。

ここでポイントは実際の併合処理等は本社側のファイルサーバと同一LAN内にいる監視一括処理に行わせなければ、
高速化は期待できません。
支店側が併合処理を行ったのでは、結局は電話回線に膨大なデータが流れる事になります。
支店は、その処理結果をただじっとまち、結果完了を本社側の監視一括処理からテキストファイル等で受け取り、
正常終了として回線切断する。もしエラー等で更新できなかったら、更新失敗を受け取り、更新失敗として回線切断する。
LAN内で併合等を行うのでしたら、長くても数分程度でおわるので、
その間電話線を専有していても、それほど問題にならないと思います。
10141 Re:遠隔地にあるファイルと同期をとる方法 chisok 2001/03/09-11:17
記事番号10117へのコメント
みすずさん有り難うございます。

>>あくまで僕の発想の範囲、想像力の範囲ですがこの方法は、LANだと非常に
>>効果的な方法ですが、ダイヤルアップ接続だと編集レコードを移動して次の
>>レコードを更新しようとする都度、改めて回線接続処理をしなければならなくなる
>>と思います。(つなぎっぱなしだと他の支店が接続不可だし)
>
>使用頻度にもよりますが、回線接続は無通信時間3分程度で自動的に切れる
>ようにしておいたとして、連続的に編集してゆけば、回線はつながったまま
>で編集される事になります。

なるほどです。 目から鱗です。

>おっしゃるとおりその間は他の支店が接続不可
>ですね。各支店毎に専用の回線が有れば、それで解決するのですが。
>またはインターネット回線を使用するか。

インターネット回線ってネットミーティングとかみたいにインターネット接続している仲間に対して
メッセージのやりとりとか編集画面の共有とかをする機能ですか?
もし、これで例えば本支店のすべてを常時接続環境を整えてデータのやりとりができればと思い
(結局DOSアプリでは無理かもしれないと思いながら)本屋をかけずり回りましたが未だにわかりません。
すごく興味があります。

>質問の趣旨では、リアルタイム性は求めていらっしゃらないようなので、
>ちょっと的はずれのコメントだったようです。

いえいえ、リアルタイム性を求めないのではなく、自分の技量と発想の限界を感じて泣く泣くあきらめたわけでして...

>ただし実際に上記手法を用いて、数十メガバイトのデータに対し、WAN側から
>486のボロPCで2,3秒で更新している処理を桐5で実現しております。

すごいの一言です。
最初からあきらめモードが入っていたのでリアルタイム性を断念したり
下記のようなインターネットディスクを使う方法に逃げたりしてました。

>インターネットディスクって、結局FTPの更新処理のような事をディスク
>中略
>(インターネットディスクの詳しい仕様はわかりませんが。)

インターネットディスクの詳しい使用どころかFTPとか同期ということ自体わからないのに質問しました。

>同一の表を同時に更新する以上、本来はレコードロックのような概念は絶対に必
>要になってきますが、

おっしゃるとおりです。

先にも書きましたが最初からあきらめモードが入っていましたが、
もうちょっと気合いを入れてみすずさんの方法を勉強してみます。
またわからないことがあったら質問しますので、厚かましいですがヒントやアドバイスをして頂けたらと思います。

お礼と言い訳のみのコメントになりますが本当に有り難うございます。

10200 Re:遠隔地にあるファイルと同期をとる方法 みすず 2001/03/11-16:17
記事番号10141へのコメント
>もし、これで例えば本支店のすべてを常時接続環境を整えてデータのやりとりが
>できればと思い(結局DOSアプリでは無理かもしれないと思いながら)本屋を
>かけずり回りましたが未だにわかりません。すごく興味があります。

DOSではインターネットを通すのは難しそうですね。
どのような回線にするにしても、本社側の一括処理にて併合等の処理をすれば、そこそこ実用になるかと思います。
本社側に常時監視体制になる一括処理を動作させておかなければなりませんが。
10202 Re:遠隔地にあるファイルと同期をとる方法 chisok 2001/03/11-23:13
記事番号10200へのコメント
みすずさんコメント有り難うございます。

>DOSではインターネットを通すのは難しそうですね。

やはりそうですか。
でも他のウィンドウズアプリケーションで出来るのであれば興味深いです。
(桐8とか)
僕のまわりにはコンピューターの相談を出来る人がいません
本屋さんに行ってみたのですが何を参考にしてよいのかわかりません。
厚かましいのを承知の上で何の分野を勉強すればよいのか質問させてください。
ルール違反だとは思いますが...

>どのような回線にするにしても、本社側の一括処理にて併合等の処理をすれば、
>そこそこ実用になるかと思います。本社側に常時監視体制になる一括処理を動作
>させておかなければなりませんが。

これに関しては本気で取り組んでみます。
本社側に常時監視体制のパソコンも導入する予定です。

戻る