JP3503957B2 - 遠隔データベースの制御方法及び装置 - Google Patents
遠隔データベースの制御方法及び装置Info
- Publication number
- JP3503957B2 JP3503957B2 JP31528492A JP31528492A JP3503957B2 JP 3503957 B2 JP3503957 B2 JP 3503957B2 JP 31528492 A JP31528492 A JP 31528492A JP 31528492 A JP31528492 A JP 31528492A JP 3503957 B2 JP3503957 B2 JP 3503957B2
- Authority
- JP
- Japan
- Prior art keywords
- server
- output
- attribute
- client
- record file
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Description
【０００１】
【産業上の利用分野】本発明は、サーバ・クライアント
上に実現した、遠隔データベースに係り、特に、サーバ
に備えたレコードファイルへの入出力をクライアント側
から制御する、遠隔データベースの制御方法及び装置に
関する。
上に実現した、遠隔データベースに係り、特に、サーバ
に備えたレコードファイルへの入出力をクライアント側
から制御する、遠隔データベースの制御方法及び装置に
関する。
【０００２】
【従来の技術】データベースをより有効的なものとする
には、ＵＮＩＸシステムからなるサーバ・クライアント
などのコンピュータ・ネットワーク上にデータベースを
実現し、サーバから離れた遠隔地にあるクラアイントか
ら、サーバ上のデータベースファイル（レコードファイ
ル）にアクセスできるようにすることが望ましい。
には、ＵＮＩＸシステムからなるサーバ・クライアント
などのコンピュータ・ネットワーク上にデータベースを
実現し、サーバから離れた遠隔地にあるクラアイントか
ら、サーバ上のデータベースファイル（レコードファイ
ル）にアクセスできるようにすることが望ましい。
【０００３】このようなシステムでは、サーバにデータ
ベースファイル（レコードファイル）が備えられる。ま
た、クライアントには、データベースファイルへのアク
セスを行うアプリケーション・プログラムが設けられ、
このプログラムの実行により、前記レコードファイルへ
のデータの検索、追加、更新等の制御をする。
ベースファイル（レコードファイル）が備えられる。ま
た、クライアントには、データベースファイルへのアク
セスを行うアプリケーション・プログラムが設けられ、
このプログラムの実行により、前記レコードファイルへ
のデータの検索、追加、更新等の制御をする。
【０００４】ところで、このようなサーバ・クライアン
ト型の遠隔データベースシステムでクライアント側から
サーバのレコードファイルへデータの更新や追加を行う
場合、クライアントはサーバ上での出力結果を持ち合わ
せ、出力すなわち更新や追加が正常に行われことを確認
してから、次の処理に移行していた。このような処理を
以下、同期処理という。
ト型の遠隔データベースシステムでクライアント側から
サーバのレコードファイルへデータの更新や追加を行う
場合、クライアントはサーバ上での出力結果を持ち合わ
せ、出力すなわち更新や追加が正常に行われことを確認
してから、次の処理に移行していた。このような処理を
以下、同期処理という。
【０００５】
【発明が解決しようとする課題】このような同期処理で
は、サーバ上での出力処理の完了を待つ必要がある。換
言すれば、その出力処理完了まで、クライアント側では
次の処理を行うことができず、通信処理のオーバヘッド
が生じ、処理性能が良くなかった。
は、サーバ上での出力処理の完了を待つ必要がある。換
言すれば、その出力処理完了まで、クライアント側では
次の処理を行うことができず、通信処理のオーバヘッド
が生じ、処理性能が良くなかった。
【０００６】本発明は、このような点を改良し、遠隔デ
ータベースシステムにおいて、処理の高速化を図ること
を課題とする。
ータベースシステムにおいて、処理の高速化を図ること
を課題とする。
【０００７】
【課題を解決するための手段】本発明は、前記課題を解
決するため、前記遠隔データベースシステムにおいて、
処理性能を向上させるために、データの更新や追加要求
がクライアント２９からサーバ２５に対してなされた場
合、サーバ２５での出力完了を待たずに次の処理を進め
る、いわゆる非同期処理を適用する点に着眼している。
決するため、前記遠隔データベースシステムにおいて、
処理性能を向上させるために、データの更新や追加要求
がクライアント２９からサーバ２５に対してなされた場
合、サーバ２５での出力完了を待たずに次の処理を進め
る、いわゆる非同期処理を適用する点に着眼している。
【０００８】但し、前記遠隔データベースシステムに非
同期処理をそのまま適用すると、次のような問題があ
る。データレコード内に重複を許さない項目が存在する
場合、データの重複が発生したことを処理結果として通
知することができない。
同期処理をそのまま適用すると、次のような問題があ
る。データレコード内に重複を許さない項目が存在する
場合、データの重複が発生したことを処理結果として通
知することができない。
【０００９】データレコード内に特定のデータ種別（例
えば数字のみ等）を持つ項目が存在したときに、誤った
種別のデータを出力しようとしても、データ異常を処理
結果として通知できない。
えば数字のみ等）を持つ項目が存在したときに、誤った
種別のデータを出力しようとしても、データ異常を処理
結果として通知できない。
【００１０】このような非同期処理に伴う不都合を避け
る必要がある。このため、本発明は以下のような手段を
採用している。 制御（１） クライアント２９側から、サーバ２５上に存在するレコ
ードファイル２１の各項目の属性を検索する手段を設け
る。これを原理図で示すと、図１のように、サーバ２５
に、データベースのレコードファイル２１と、このレコ
ードファイル２１への入出力部２３とを設けてある。こ
れに対し、サーバ２５に通信網（ＮＷ）を介して接続さ
れたクライアント２９に、前記入出力部２３に制御命令
を送信して前記レコードファイル２１を操作する操作部
２７を設けてある。前記レコードファイル２１は、デー
タ群の特性を示す属性を、データ群毎に有している。そ
して、クライアント２９の操作部２７からの操作で前記
レコードファイル２１へのアクセスを行う。その際、前
記クライアント２９からの属性通知依頼でサーバ２５か
らクライアント２９に前記属性を通知し、その属性に従
ってサーバ２５の入出力部２３を制御する。属性通知依
頼のために、クライアント２９には属性通知依頼部３１
が設けられ、この属性通知依頼部３１による属性通知依
頼に応えて属性を獲得し、クライアント２９にその属性
を通知するために、サーバ２５に属性取得・通知部３０
が設けられる。また、サーバ２５から送られてきた属性
を取り込む属性受信部３３を前記クラインアントに設け
る。
る必要がある。このため、本発明は以下のような手段を
採用している。 制御（１） クライアント２９側から、サーバ２５上に存在するレコ
ードファイル２１の各項目の属性を検索する手段を設け
る。これを原理図で示すと、図１のように、サーバ２５
に、データベースのレコードファイル２１と、このレコ
ードファイル２１への入出力部２３とを設けてある。こ
れに対し、サーバ２５に通信網（ＮＷ）を介して接続さ
れたクライアント２９に、前記入出力部２３に制御命令
を送信して前記レコードファイル２１を操作する操作部
２７を設けてある。前記レコードファイル２１は、デー
タ群の特性を示す属性を、データ群毎に有している。そ
して、クライアント２９の操作部２７からの操作で前記
レコードファイル２１へのアクセスを行う。その際、前
記クライアント２９からの属性通知依頼でサーバ２５か
らクライアント２９に前記属性を通知し、その属性に従
ってサーバ２５の入出力部２３を制御する。属性通知依
頼のために、クライアント２９には属性通知依頼部３１
が設けられ、この属性通知依頼部３１による属性通知依
頼に応えて属性を獲得し、クライアント２９にその属性
を通知するために、サーバ２５に属性取得・通知部３０
が設けられる。また、サーバ２５から送られてきた属性
を取り込む属性受信部３３を前記クラインアントに設け
る。
【００１１】項目の属性とは例えば次のようなものを言
う。 項目の長さ 項目のデータ種別（数値のみの項目、英数値のみの項
目等） 項目のデータの一意性（重複を許す項目であるか否
か） 図２（ｂ）に属性の例を示す。
う。 項目の長さ 項目のデータ種別（数値のみの項目、英数値のみの項
目等） 項目のデータの一意性（重複を許す項目であるか否
か） 図２（ｂ）に属性の例を示す。
【００１２】当方法によれば、クライアント２９側で、
これから出力するレコードデータについての異常の蓋然
性のチェックを行うことが可能となる。このチェックの
ためには、クライアント２９に属性検証部３７あるいは
属性妥当性検証部３９を設ける。
これから出力するレコードデータについての異常の蓋然
性のチェックを行うことが可能となる。このチェックの
ためには、クライアント２９に属性検証部３７あるいは
属性妥当性検証部３９を設ける。
【００１３】また、クライアント２９側で出力しようと
したレコードの異常の蓋然性のチェックを行うことで、
レコードが妥当でないときには通信処理を行うことなく
アプリケーションに異常を通知でき、処理のスループッ
トを向上できるメリットもある。
したレコードの異常の蓋然性のチェックを行うことで、
レコードが妥当でないときには通信処理を行うことなく
アプリケーションに異常を通知でき、処理のスループッ
トを向上できるメリットもある。
【００１４】操作部２７とは、前記したようなクライア
ント２９側のアプリケーション・プログラムで実現され
る。図２に、項目の属性の取り込みを示すフロー図を示
す。 制御（２−１） レコードデータの出力に先立って、サーバ２５上に存在
するレコードファイル２１の各項目にチェックが必要な
属性が存在するか否か、すなわち、アクセス時に重複デ
ータの追加、矛盾データの追加など、異常の発生する可
能性のある属性か否かをクライアント２９側の属性検証
部３７で属性名のみからチェックし、チェックが必要な
属性が１つも存在しないときには、非同期処理する。
ント２９側のアプリケーション・プログラムで実現され
る。図２に、項目の属性の取り込みを示すフロー図を示
す。 制御（２−１） レコードデータの出力に先立って、サーバ２５上に存在
するレコードファイル２１の各項目にチェックが必要な
属性が存在するか否か、すなわち、アクセス時に重複デ
ータの追加、矛盾データの追加など、異常の発生する可
能性のある属性か否かをクライアント２９側の属性検証
部３７で属性名のみからチェックし、チェックが必要な
属性が１つも存在しないときには、非同期処理する。
【００１５】ここでのチェックは属性名のみから行う。
例えば、従業員データベースにおいて、属性＝従業員番
号である場合、その実際のデータを見るまでもなく、異
なる重複データの存在を許さないことが分かる。従っ
て、属性名＝従業員番号であるときはそのデータを見る
までもなく、異常の可能性のある属性であるとして、同
期処理の対象とする。
例えば、従業員データベースにおいて、属性＝従業員番
号である場合、その実際のデータを見るまでもなく、異
なる重複データの存在を許さないことが分かる。従っ
て、属性名＝従業員番号であるときはそのデータを見る
までもなく、異常の可能性のある属性であるとして、同
期処理の対象とする。
【００１６】非同期処理を行うときには、アプリケーシ
ョンにレコードの出力が正常に行われたという結果（模
擬結果）を通知する。模擬結果を通知することで、アプ
リケーションは動作を続行することができる。
ョンにレコードの出力が正常に行われたという結果（模
擬結果）を通知する。模擬結果を通知することで、アプ
リケーションは動作を続行することができる。
【００１７】チェックが必要な項目が１つでも存在する
ときには、同期処理をし、サーバ２５上でレコードが実
際に出力されるのを待ち合わせる。この結果、サーバ２
５側での出力時に異常を検出したときに操作部２７であ
るアプリケーションにその旨を通知することができる。
この制御（２）のために、図３に示した原理図のよう
に、属性検証部３７でレコードファイル２１の各項目に
チェックが必要な属性が存在するか否かを判定し、チェ
ックの必要な属性が一つも存在しないとき、サーバ２５
におけるレコードファイル２１への出力指令に対し、サ
ーバ２５からの出力完了通知を待たずに、クライアント
２９の操作部２７へ出力完了の疑似結果通知をクライア
ント（２９）側で行うことにより次の処理に移行する非
同期処理部４３と、前記属性検証部３７で、チェックの
必要な属性が一つでも存在するとき、サーバ２５におけ
るレコードファイル２１への出力指令に対し、サーバ２
５からクライアント２９の操作部２７への出力完了結果
通知を待って次の処理に移行する行う同期処理部４１と
を必要とする。
ときには、同期処理をし、サーバ２５上でレコードが実
際に出力されるのを待ち合わせる。この結果、サーバ２
５側での出力時に異常を検出したときに操作部２７であ
るアプリケーションにその旨を通知することができる。
この制御（２）のために、図３に示した原理図のよう
に、属性検証部３７でレコードファイル２１の各項目に
チェックが必要な属性が存在するか否かを判定し、チェ
ックの必要な属性が一つも存在しないとき、サーバ２５
におけるレコードファイル２１への出力指令に対し、サ
ーバ２５からの出力完了通知を待たずに、クライアント
２９の操作部２７へ出力完了の疑似結果通知をクライア
ント（２９）側で行うことにより次の処理に移行する非
同期処理部４３と、前記属性検証部３７で、チェックの
必要な属性が一つでも存在するとき、サーバ２５におけ
るレコードファイル２１への出力指令に対し、サーバ２
５からクライアント２９の操作部２７への出力完了結果
通知を待って次の処理に移行する行う同期処理部４１と
を必要とする。
【００１８】なお、非同期処理部４３としては、サー
バ２５におけるレコードファイル２１への出力指令をク
ライアント２９から送信した際に、サーバ２５からの出
力完了を待たずに操作部２７へ出力完了の疑似結果通知
をクライアント（２９）側で行う場合、サーバ２５に
おけるレコードファイル２１への出力指令をクライアン
ト２９から送信する前に、前記クライアント２９に設け
たバッファメモリに逐次蓄え、そのバッファメモリへの
格納毎に、操作部２７へ出力完了の疑似結果通知を行
い、バッファメモリに所定量の指令が蓄積されたときサ
ーバ２５へ一括して指令を送出するバッファリング処理
部である場合を含む。
バ２５におけるレコードファイル２１への出力指令をク
ライアント２９から送信した際に、サーバ２５からの出
力完了を待たずに操作部２７へ出力完了の疑似結果通知
をクライアント（２９）側で行う場合、サーバ２５に
おけるレコードファイル２１への出力指令をクライアン
ト２９から送信する前に、前記クライアント２９に設け
たバッファメモリに逐次蓄え、そのバッファメモリへの
格納毎に、操作部２７へ出力完了の疑似結果通知を行
い、バッファメモリに所定量の指令が蓄積されたときサ
ーバ２５へ一括して指令を送出するバッファリング処理
部である場合を含む。
【００１９】図４に当制御方式の処理フロー例を示す。
制御（２−２）
また、図５のように、前記属性検証部３７での属性名の
チェックに代えて、あるいは、属性検証部３７での検証
が終了し、その結果としてチェックが必要な項目が１つ
でも存在するときに、クライアント２９側の属性妥当性
検証部３９でさらに属性妥当性のチェックを行ことがで
きる。
チェックに代えて、あるいは、属性検証部３７での検証
が終了し、その結果としてチェックが必要な項目が１つ
でも存在するときに、クライアント２９側の属性妥当性
検証部３９でさらに属性妥当性のチェックを行ことがで
きる。
【００２０】妥当性のチェックとは、属性検証部３７で
の検証と異なり、属性名のみからの異常の可能性の判断
ではなく、その属性について入力されたデータ自体から
異常が発生するか否かを判定することである。例えば、
数値のみを許す項目に対して、数値以外が設定されてい
るか否かのチェックである。より具体的に、属性のデー
タ形式が、数値であるにも係わらず、データが漢字やア
ルファベットなどのキャラクタである場合、そのデータ
は必ず異常となる。また、ファイル２１へ出力するデー
タと、ファイル２１に記憶してあるデータとの比較によ
る異常発生の蓋然性判断もここでいう妥当性判断に含
む。例えば、更新レコード、更新前のレコードを比較し
た場合、重複を許さない項目の内容に変更があるか否か
の判定をし、変更がある場合、妥当性なし（異常発生の
おそれあり）、変更がない場合、妥当性あり（異常発生
のおそれなし）とする。
の検証と異なり、属性名のみからの異常の可能性の判断
ではなく、その属性について入力されたデータ自体から
異常が発生するか否かを判定することである。例えば、
数値のみを許す項目に対して、数値以外が設定されてい
るか否かのチェックである。より具体的に、属性のデー
タ形式が、数値であるにも係わらず、データが漢字やア
ルファベットなどのキャラクタである場合、そのデータ
は必ず異常となる。また、ファイル２１へ出力するデー
タと、ファイル２１に記憶してあるデータとの比較によ
る異常発生の蓋然性判断もここでいう妥当性判断に含
む。例えば、更新レコード、更新前のレコードを比較し
た場合、重複を許さない項目の内容に変更があるか否か
の判定をし、変更がある場合、妥当性なし（異常発生の
おそれあり）、変更がない場合、妥当性あり（異常発生
のおそれなし）とする。
【００２１】図５の原理図に示したように、属性妥当性
検証部３９で妥当性のチェックを行い、妥当でないとさ
れたとき、すなわち、その属性が、サーバ２５側で異常
が発生する属性であると判定されたとき、クライアント
２９の疑似異常通知部４７から疑似的に異常通知をクラ
イアント２９の操作部２７に送り、処理を中止すること
ができる。
検証部３９で妥当性のチェックを行い、妥当でないとさ
れたとき、すなわち、その属性が、サーバ２５側で異常
が発生する属性であると判定されたとき、クライアント
２９の疑似異常通知部４７から疑似的に異常通知をクラ
イアント２９の操作部２７に送り、処理を中止すること
ができる。
【００２２】なお、妥当性があるとされたとき、すなわ
ち、その属性が、サーバ２５側で異常が発生しない属性
であると判定されたときは、サーバ２５におけるレコー
ドファイル２１への出力指令に対し、サーバ２５からの
出力完了を待たずに操作べ２７へ出力完了の疑似結果通
知をクライアント（２９）側で行うことにより次の処理
に移行する非同期処理をすることが可能である。
ち、その属性が、サーバ２５側で異常が発生しない属性
であると判定されたときは、サーバ２５におけるレコー
ドファイル２１への出力指令に対し、サーバ２５からの
出力完了を待たずに操作べ２７へ出力完了の疑似結果通
知をクライアント（２９）側で行うことにより次の処理
に移行する非同期処理をすることが可能である。
【００２３】この場合の、処理フロー例を図６に示す。
制御（３）
前記制御（１）や制御（２）で説明した方式を使用する
ことで、通常はサーバ２５上で実際にレコードを出力し
たときに異常が発生することはない。しかし、装置異常
や２次記憶装置の容量不足などが発生する可能性があ
り、このときに、クライアント２９側の操作部２７（ア
プリケーション）に異常を通知しないと、クライアント
２９側のアプリケーションが無意味に続行され続けてし
まう。これを回避するために次の制御を行う。
ことで、通常はサーバ２５上で実際にレコードを出力し
たときに異常が発生することはない。しかし、装置異常
や２次記憶装置の容量不足などが発生する可能性があ
り、このときに、クライアント２９側の操作部２７（ア
プリケーション）に異常を通知しないと、クライアント
２９側のアプリケーションが無意味に続行され続けてし
まう。これを回避するために次の制御を行う。
【００２４】すなわち、サーバ２５上に存在するデータ
ベースファイル２１（レコードファイル２１）への出力
を非同期処理で処理し、その後実際にサーバ２５上で出
力されたときに異常を検出した場合、図７の原理図で示
したように、サーバ２５の異常通知部から通知された異
常が発生した旨の処理結果をクライアント２９側の異常
結果保持部５１で保持しておき、次にアプリケーション
から出力要求を受け付けたときにこれを通知する。
ベースファイル２１（レコードファイル２１）への出力
を非同期処理で処理し、その後実際にサーバ２５上で出
力されたときに異常を検出した場合、図７の原理図で示
したように、サーバ２５の異常通知部から通知された異
常が発生した旨の処理結果をクライアント２９側の異常
結果保持部５１で保持しておき、次にアプリケーション
から出力要求を受け付けたときにこれを通知する。
【００２５】クライアント２９側のアプリケーション
は、異常を通知されたときに処理を停止することがで
き、無意味に続行されることを防ぐことができる。この
場合の、処理フロー例を図８に示す。
は、異常を通知されたときに処理を停止することがで
き、無意味に続行されることを防ぐことができる。この
場合の、処理フロー例を図８に示す。
【００２６】
【作用】本発明では、まず、クライアント２９からの属
性通知依頼に基づきサーバ２５からレコードファイル２
１のデータ項目における属性をクライアント２９に送
る。
性通知依頼に基づきサーバ２５からレコードファイル２
１のデータ項目における属性をクライアント２９に送
る。
【００２７】クライアント２９では、この属性を属性名
から検証する。ここで、例えば、データの追加・更新な
どの場合、重複データあるいは、矛盾する内容のデータ
がファイル２１に出力されては困る属性については、チ
ェックが必要な項目がある場合として、同期処理でデー
タレコードをファイル２１に出力する。矛盾するデータ
内容の出力のおそれが無い属性を受けた場合は、非同期
処理でデータレコードをファイル２１に出力する。
から検証する。ここで、例えば、データの追加・更新な
どの場合、重複データあるいは、矛盾する内容のデータ
がファイル２１に出力されては困る属性については、チ
ェックが必要な項目がある場合として、同期処理でデー
タレコードをファイル２１に出力する。矛盾するデータ
内容の出力のおそれが無い属性を受けた場合は、非同期
処理でデータレコードをファイル２１に出力する。
【００２８】属性の検証の後、チェックが必要な項目が
ある場合とされた場合、さらに、各項目の妥当性を、そ
の項目に入力されたデータから検証する。妥当であると
された場合、非同期処理でデータレコードをファイル２
１に追加する。妥当でない場合は、疑似的に異常通知を
生成し、操作部２７に通知する。これにより、操作部２
７のアプリケーションはその処理を中止する。
ある場合とされた場合、さらに、各項目の妥当性を、そ
の項目に入力されたデータから検証する。妥当であると
された場合、非同期処理でデータレコードをファイル２
１に追加する。妥当でない場合は、疑似的に異常通知を
生成し、操作部２７に通知する。これにより、操作部２
７のアプリケーションはその処理を中止する。
【００２９】なお、属性検証部３７による属性の検証に
代えて、直ちに属性妥当性検証部３９による属性の妥当
性を検証するようにしてもよい。また、非同期処理を行
った場合、実際にファイル２１への出力に異常が生じる
ことがある。その場合、異常結果をクライアント２９側
で保持し、次に、出力要求をクライアント２９のアプリ
ケーションから出されるとき、異常結果を通知し、アプ
リケーションの処理続行を停止する。
代えて、直ちに属性妥当性検証部３９による属性の妥当
性を検証するようにしてもよい。また、非同期処理を行
った場合、実際にファイル２１への出力に異常が生じる
ことがある。その場合、異常結果をクライアント２９側
で保持し、次に、出力要求をクライアント２９のアプリ
ケーションから出されるとき、異常結果を通知し、アプ
リケーションの処理続行を停止する。
【００３０】
【実施例】以下、図面を参照して、レコードを更新する
場合、レコードを追加する場合及びレコードを一括処理
する場合の実施例を説明する。
場合、レコードを追加する場合及びレコードを一括処理
する場合の実施例を説明する。
【００３１】ここで、まず実施例のシステム構成を図９
に示す。図９において、コンピュータからなるサーバ２
５にネットワークを介して、コンピュータからなるクラ
イアント２９が接続されている。クライアント２９は通
常複数接続され、ＬＡＮを構成する。
に示す。図９において、コンピュータからなるサーバ２
５にネットワークを介して、コンピュータからなるクラ
イアント２９が接続されている。クライアント２９は通
常複数接続され、ＬＡＮを構成する。
【００３２】サーバ２５には、データベースにおいて、
データを蓄積するレコードファイル２１が設けられてい
る。このレコードファイル２１は、２次記憶装置、ある
いは、外部記憶装置に記憶される。ここで、レコードフ
ァイル２１のファイル２１形式は、例えば階層型のファ
イル２１で、各階層に分かれた項目毎に、データ群を一
定の属性毎にまとめて記憶するようになっている。ファ
イル２１形式は特に問わないが、少なくとも属性が存在
するものとする。
データを蓄積するレコードファイル２１が設けられてい
る。このレコードファイル２１は、２次記憶装置、ある
いは、外部記憶装置に記憶される。ここで、レコードフ
ァイル２１のファイル２１形式は、例えば階層型のファ
イル２１で、各階層に分かれた項目毎に、データ群を一
定の属性毎にまとめて記憶するようになっている。ファ
イル２１形式は特に問わないが、少なくとも属性が存在
するものとする。
【００３３】また、サーバ２５には、一般的なサーバ２
５機構の他、レコードファイル２１への新規データの書
き込み、データの更新、追加、検索などを行うための入
出力部２３が設けられている。サーバ２５機能とは、ク
ライアント２９から依頼された要求を、レコードファイ
ル２１への入出力機構を介して処理する機能である。サ
ーバ２５機能自らが、レコードファイル２１の入出力機
能を兼ねても良い。
５機構の他、レコードファイル２１への新規データの書
き込み、データの更新、追加、検索などを行うための入
出力部２３が設けられている。サーバ２５機能とは、ク
ライアント２９から依頼された要求を、レコードファイ
ル２１への入出力機構を介して処理する機能である。サ
ーバ２５機能自らが、レコードファイル２１の入出力機
能を兼ねても良い。
【００３４】さらに、サーバ２５に、クライアント２９
からの要求に従ってデータファイル２１の属性を取得し
てクライアント２９に通知する属性取得・通知部３０が
設けられている。
からの要求に従ってデータファイル２１の属性を取得し
てクライアント２９に通知する属性取得・通知部３０が
設けられている。
【００３５】また、サーバ２５に、データファイル２１
でのデータの入出力に異常が生じたとき、その異常をク
ライアント２９に通知する異常通知部４９が設けられて
いる。
でのデータの入出力に異常が生じたとき、その異常をク
ライアント２９に通知する異常通知部４９が設けられて
いる。
【００３６】サーバ２５はコンピュータであり、前記入
出力部２３、属性取得・通知部３０、異常通知部４９
は、メインメモリに記憶されたプログラムが中央演算装
置にロードされることにより実現される。
出力部２３、属性取得・通知部３０、異常通知部４９
は、メインメモリに記憶されたプログラムが中央演算装
置にロードされることにより実現される。
【００３７】クライアント２９には、一般的なクライア
ント２９機構の他、データベースのレコードファイル２
１にアクセスするための操作部２７が設けられている。
操作部２７は、メインメモリに格納されたアプリケーシ
ョン・プログラムにより実現される。
ント２９機構の他、データベースのレコードファイル２
１にアクセスするための操作部２７が設けられている。
操作部２７は、メインメモリに格納されたアプリケーシ
ョン・プログラムにより実現される。
【００３８】なお、クライアント２９機能とは、アプリ
ケーションの処理依頼（レコードの更新・追加等）をサ
ーバ２５機能に送信し結果を受信する処理を行う機能で
ある。
ケーションの処理依頼（レコードの更新・追加等）をサ
ーバ２５機能に送信し結果を受信する処理を行う機能で
ある。
【００３９】さらに、クライアント２９には、サーバ２
５に対して属性通知依頼をする属性通知依頼部３１、サ
ーバ２５から送られて来る属性を受信する属性受信部３
３、受信した属性をチェックする属性検証部３７、属性
検証部３７の検証結果によりその後の処理を同期処理と
する同期処理部４１、属性検証部３７の検証結果により
その後の処理を非同期処理とする非同期処理部４３、属
性検証部３７で検証された属性につきさらに妥当性を検
証する属性妥当性検証部３９、属性妥当性検証部３９で
妥当でないとされた場合に、疑似異常通知を操作部２７
に送り疑似異常通知部４７を有する。
５に対して属性通知依頼をする属性通知依頼部３１、サ
ーバ２５から送られて来る属性を受信する属性受信部３
３、受信した属性をチェックする属性検証部３７、属性
検証部３７の検証結果によりその後の処理を同期処理と
する同期処理部４１、属性検証部３７の検証結果により
その後の処理を非同期処理とする非同期処理部４３、属
性検証部３７で検証された属性につきさらに妥当性を検
証する属性妥当性検証部３９、属性妥当性検証部３９で
妥当でないとされた場合に、疑似異常通知を操作部２７
に送り疑似異常通知部４７を有する。
【００４０】以上の遠隔データベースシステムによる、
レコードの更新、追加、一括出力の場合の例を説明す
る。 ＜レコード更新の場合の実施例＞ここでは、レコードの
更新を非同期処理する例を図１０に示す。また、レコー
ドの更新は、必ず一度レコードを読み込んだ後にその内
容をアプリケーションが変更し、更新するものとする。
レコードの更新、追加、一括出力の場合の例を説明す
る。 ＜レコード更新の場合の実施例＞ここでは、レコードの
更新を非同期処理する例を図１０に示す。また、レコー
ドの更新は、必ず一度レコードを読み込んだ後にその内
容をアプリケーションが変更し、更新するものとする。
【００４１】なお、重複を許さない項目が一つも存在し
ないときには、非同期処理で更新処理を行う。重複を許
さない項目が存在するときは、重複を許さない項目の内
容に変更があるかないかをチェックし、変更がないとき
には非同期処理で更新処理を行い、変更があるときには
実際の更新時にレコードの重複を示す異常が通知される
可能性があるため、サーバ２５側での更新処理が終了す
るのを待ち合わせる。
ないときには、非同期処理で更新処理を行う。重複を許
さない項目が存在するときは、重複を許さない項目の内
容に変更があるかないかをチェックし、変更がないとき
には非同期処理で更新処理を行い、変更があるときには
実際の更新時にレコードの重複を示す異常が通知される
可能性があるため、サーバ２５側での更新処理が終了す
るのを待ち合わせる。
【００４２】なお、重複を許さない項目とは、例えば、
企業における従業員データベースにおける属性として、
社員番号等である。異なる社員に対し同一の社員番号が
あってはデータが矛盾することとなる。
企業における従業員データベースにおける属性として、
社員番号等である。異なる社員に対し同一の社員番号が
あってはデータが矛盾することとなる。
【００４３】処理フローの詳細を図１０に従って説明す
る。 アプリケーションがレコード読込みを要求する（ス
テップ１０１）。クライアント２９機能はこの要求をサ
ーバ２５機能に伝播し、サーバ２５機能が代行でレコー
ドの読込みを行い（ステップ１０２）、クライアント２
９機能に読み込んだレコードを通知する。
る。 アプリケーションがレコード読込みを要求する（ス
テップ１０１）。クライアント２９機能はこの要求をサ
ーバ２５機能に伝播し、サーバ２５機能が代行でレコー
ドの読込みを行い（ステップ１０２）、クライアント２
９機能に読み込んだレコードを通知する。
【００４４】このときに、読み込んだレコードをクライ
アント２９機能で記憶してから（ステップ１０３）、ア
プリケーションに通知する（ステップ１０４）。 アプリケーションが、で通知したレコードの更新
を要求する（ステップ１０５）。
アント２９機能で記憶してから（ステップ１０３）、ア
プリケーションに通知する（ステップ１０４）。 アプリケーションが、で通知したレコードの更新
を要求する（ステップ１０５）。
【００４５】 属性通知依頼部３１は、当該レコード
ファイル２１の各項目の属性を１度もサーバ２５から取
り込んでないときだけ、サーバ２５機能に対して属性通
知依頼を行い（ステップ１０６）、属性取得・通知部３
０で属性の取込みを行い、クライアント２９に通知する
（ステップ１０７）。
ファイル２１の各項目の属性を１度もサーバ２５から取
り込んでないときだけ、サーバ２５機能に対して属性通
知依頼を行い（ステップ１０６）、属性取得・通知部３
０で属性の取込みを行い、クライアント２９に通知する
（ステップ１０７）。
【００４６】この結果、アクセス対象のレコードファイ
ル２１の各項目の属性（重複を許すか否か）が判明す
る。 属性受信部３３が受信した属性は、属性検証部３７
で検証され、更新するレコードに重複を許さない項目が
存在するか否かが判定される（ステップ１０８）。重複
を許さない項目が１つもない場合には、非同期処理で更
新処理を行っても、重複が発生した旨の異常が起きるこ
とはないため、非同期処理部４３からサーバ２５機能に
対して非同期処理でレコード更新を依頼する（ステップ
１０９）。このときに、非同期処理部４３はアプリケー
ションに更新が正常終了した旨の模擬結果を通知する
（ステップ１１０）。
ル２１の各項目の属性（重複を許すか否か）が判明す
る。 属性受信部３３が受信した属性は、属性検証部３７
で検証され、更新するレコードに重複を許さない項目が
存在するか否かが判定される（ステップ１０８）。重複
を許さない項目が１つもない場合には、非同期処理で更
新処理を行っても、重複が発生した旨の異常が起きるこ
とはないため、非同期処理部４３からサーバ２５機能に
対して非同期処理でレコード更新を依頼する（ステップ
１０９）。このときに、非同期処理部４３はアプリケー
ションに更新が正常終了した旨の模擬結果を通知する
（ステップ１１０）。
【００４７】重複を許さない項目が存在するときには、
非同期処理で更新処理をサーバ２５機能に対して依頼で
きないため、属性妥当性検証部３９での判定を行う
（ステップ１１１）。
非同期処理で更新処理をサーバ２５機能に対して依頼で
きないため、属性妥当性検証部３９での判定を行う
（ステップ１１１）。
【００４８】 更新するレコードとで通知したレコ
ードを比較し、重複を許さない項目の内容に更新がある
ときには、更新した結果として重複が発生した旨の異常
が起きる可能性があるため、同期処理部４１によりサー
バ２５側にレコード更新を依頼し（ステップ１１２）、
その後に、更新が終了するのを待ち合わせる（ステップ
１１３）。
ードを比較し、重複を許さない項目の内容に更新がある
ときには、更新した結果として重複が発生した旨の異常
が起きる可能性があるため、同期処理部４１によりサー
バ２５側にレコード更新を依頼し（ステップ１１２）、
その後に、更新が終了するのを待ち合わせる（ステップ
１１３）。
【００４９】重複を許さない項目の内容に変更がないと
きには、更新した結果として重複が発生した旨の異常が
起きることはないため、非同期処理部４３からサーバ２
５機能に対して非同期処理でレコード更新を依頼する
（ステップ１１４）。このときに、アプリケーションに
は更新が正常終了した旨の模擬結果を通知する（ステッ
プ１１５）。
きには、更新した結果として重複が発生した旨の異常が
起きることはないため、非同期処理部４３からサーバ２
５機能に対して非同期処理でレコード更新を依頼する
（ステップ１１４）。このときに、アプリケーションに
は更新が正常終了した旨の模擬結果を通知する（ステッ
プ１１５）。
【００５０】なお、非同期処理でのレコード更新依頼が
装置異常等の要因で異常終了した場合、サーバ２５機能
は異常が発生した旨の処理結果をクライアント２９機能
に送信する。クライアント２９では処理結果保持部５１
でこの処理結果を保持しておく。処理結果保持部５１
は、以降のアプリケーションからの要求に対して、その
旨の異常を通知することで、処理を停止できる。 ＜レコード追加の場合の実施例＞ここでは、レコードの
追加を非同期処理で処理する例を図１１に示す。また、
レコード追加の処理結果として、アプリケーションに追
加したレコードの相対番号を通知するものとする。
装置異常等の要因で異常終了した場合、サーバ２５機能
は異常が発生した旨の処理結果をクライアント２９機能
に送信する。クライアント２９では処理結果保持部５１
でこの処理結果を保持しておく。処理結果保持部５１
は、以降のアプリケーションからの要求に対して、その
旨の異常を通知することで、処理を停止できる。 ＜レコード追加の場合の実施例＞ここでは、レコードの
追加を非同期処理で処理する例を図１１に示す。また、
レコード追加の処理結果として、アプリケーションに追
加したレコードの相対番号を通知するものとする。
【００５１】なお、重複を許さない項目が一つも存在し
ないときには、非同期処理で追加処理を行う。重複を許
さない項目が存在するときは、追加時にレコードの重複
を示す異常が通知される可能性があるため、サーバ２５
側での追加処理が終了するのを待ち合わせる（同期処
理）。
ないときには、非同期処理で追加処理を行う。重複を許
さない項目が存在するときは、追加時にレコードの重複
を示す異常が通知される可能性があるため、サーバ２５
側での追加処理が終了するのを待ち合わせる（同期処
理）。
【００５２】但し、非同期処理で追加処理を行うときで
も、アプリケーションに追加したレコードの相対番号を
通知するために、１度だけはサーバ２５側でのレコード
の追加処理の終了を待ち合わせて追加したレコードの相
対番号を記憶する。２度目以降の追加処理から、非同期
処理でサーバ２５機能にレコード追加を依頼し、前回追
加したレコードの相対番号に１を加えた値を今回追加し
たレコードの相対番号としてアプリケーションに通知す
る。
も、アプリケーションに追加したレコードの相対番号を
通知するために、１度だけはサーバ２５側でのレコード
の追加処理の終了を待ち合わせて追加したレコードの相
対番号を記憶する。２度目以降の追加処理から、非同期
処理でサーバ２５機能にレコード追加を依頼し、前回追
加したレコードの相対番号に１を加えた値を今回追加し
たレコードの相対番号としてアプリケーションに通知す
る。
【００５３】処理フローの詳細を図１１に従って説明す
る。 アプリケーションが追加を要求する（ステップ２０
１）。 属性通知依頼部３１は、当該レコードファイル２１
の各項目の属性を１度もサーバ２５から取り込んでない
ときだけ、サーバ２５機能に対して属性通知依頼を行い
（ステップ２０２）、属性取得・通知部３０で属性の取
込みを行い、クライアント２９に通知する（ステップ２
０３）。
る。 アプリケーションが追加を要求する（ステップ２０
１）。 属性通知依頼部３１は、当該レコードファイル２１
の各項目の属性を１度もサーバ２５から取り込んでない
ときだけ、サーバ２５機能に対して属性通知依頼を行い
（ステップ２０２）、属性取得・通知部３０で属性の取
込みを行い、クライアント２９に通知する（ステップ２
０３）。
【００５４】この結果、アクセス対象のレコードファイ
ル２１の各項目の属性（重複を許すか否か）が判明す
る。 属性受信部３３が受信した属性は、属性検証部３７
で検証され、追加するレコードに重複を許さない項目が
存在するか否かが判定される（ステップ２０４）。
ル２１の各項目の属性（重複を許すか否か）が判明す
る。 属性受信部３３が受信した属性は、属性検証部３７
で検証され、追加するレコードに重複を許さない項目が
存在するか否かが判定される（ステップ２０４）。
【００５５】重複を許さない項目が存在するときには、
追加した結果として重複が発生した旨の異常が起きる可
能性があるため、同期処理部４１によりサーバ２５側に
レコード追加を依頼した後（ステップ２０５）に、追加
が終了するのを待ち合わせる（ステップ２０６）。
追加した結果として重複が発生した旨の異常が起きる可
能性があるため、同期処理部４１によりサーバ２５側に
レコード追加を依頼した後（ステップ２０５）に、追加
が終了するのを待ち合わせる（ステップ２０６）。
【００５６】重複を許さない項目が存在しないときで
も、１回目の追加であるため、追加するレコードの相対
番号を取り出す目的で、サーバ２５側にレコード追加を
依頼した後に、追加が終了するのを待ち合わせる（ステ
ップ２０７）。サーバ２５機能から処理結果を通知され
たときに、通知された相対番号を記憶しておく（ステッ
プ２０８）。その後、結果通知をアプリケーションに対
して行う（ステップ２０９） アプリケーションが次のレコード追加を要求する
（ステップ２１０）。今度は、既に属性を取り込んであ
るので、属性通知依頼は出されない。
も、１回目の追加であるため、追加するレコードの相対
番号を取り出す目的で、サーバ２５側にレコード追加を
依頼した後に、追加が終了するのを待ち合わせる（ステ
ップ２０７）。サーバ２５機能から処理結果を通知され
たときに、通知された相対番号を記憶しておく（ステッ
プ２０８）。その後、結果通知をアプリケーションに対
して行う（ステップ２０９） アプリケーションが次のレコード追加を要求する
（ステップ２１０）。今度は、既に属性を取り込んであ
るので、属性通知依頼は出されない。
【００５７】 追加するレコードについての項目に、
属性検証部３７で検証され、更新するレコードに重複を
許さない項目が存在するか否かが判定される（ステップ
２１１）。重複を許さない項目が存在するときには、追
加した結果として重複が発生した旨の異常が起きる可能
性があるため、同期処理部４１により、サーバ２５側に
レコード追加を依頼した後に（ステップ２１２）、追加
処理が終了するのを待ち合わせる（ステップ２１３）。
属性検証部３７で検証され、更新するレコードに重複を
許さない項目が存在するか否かが判定される（ステップ
２１１）。重複を許さない項目が存在するときには、追
加した結果として重複が発生した旨の異常が起きる可能
性があるため、同期処理部４１により、サーバ２５側に
レコード追加を依頼した後に（ステップ２１２）、追加
処理が終了するのを待ち合わせる（ステップ２１３）。
【００５８】重複を許さない項目が存在しないときに
は、追加した結果として重複が発生した旨の異常がおき
ることはないため、非同期処理により、サーバ２５機能
に対して非同期処理でレコード追加を依頼する（ステッ
プ２１４）。
は、追加した結果として重複が発生した旨の異常がおき
ることはないため、非同期処理により、サーバ２５機能
に対して非同期処理でレコード追加を依頼する（ステッ
プ２１４）。
【００５９】このときに、アプリケーションには、前回
通知した相対番号に１を加えた値を、今回通知したレコ
ードの相対番号として通知するとともに（ステップ２１
５）、追加が正常終了した旨の模擬結果を通知する（ス
テップ２１６）。
通知した相対番号に１を加えた値を、今回通知したレコ
ードの相対番号として通知するとともに（ステップ２１
５）、追加が正常終了した旨の模擬結果を通知する（ス
テップ２１６）。
【００６０】なお、非同期処理でのレコード追加依頼が
装置異常や二次記憶装置の容量不足等の要因で異常終了
した場合、サーバ２５機能は異常が発生した旨の処理結
果をクライアント２９機能に送信する。クライアント２
９では処理結果保持部５１でこの処理結果を保持してお
く。処理結果保持部５１は、以降のアプリケーションか
らの要求に対して、その旨の異常を通知することで、処
理を停止できる。 ＜レコードを一括出力する場合の実施例＞ここでは、レ
コードを一括更新（又は追加）する処理例を図１２に示
す。なお、数字のみが許される項目を持ったレコードフ
ァイル２１を例に説明する。
装置異常や二次記憶装置の容量不足等の要因で異常終了
した場合、サーバ２５機能は異常が発生した旨の処理結
果をクライアント２９機能に送信する。クライアント２
９では処理結果保持部５１でこの処理結果を保持してお
く。処理結果保持部５１は、以降のアプリケーションか
らの要求に対して、その旨の異常を通知することで、処
理を停止できる。 ＜レコードを一括出力する場合の実施例＞ここでは、レ
コードを一括更新（又は追加）する処理例を図１２に示
す。なお、数字のみが許される項目を持ったレコードフ
ァイル２１を例に説明する。
【００６１】処理フローの詳細を図１２に従って説明す
る。 アプリケーションがレコードの出力（更新や追加）
を要求する（ステップ３０１）。
る。 アプリケーションがレコードの出力（更新や追加）
を要求する（ステップ３０１）。
【００６２】 属性通知依頼部３１は、当該レコード
ファイル２１の各項目の属性を１度もサーバ２５から取
り込んでないときだけ、サーバ２５機能に対して属性通
知依頼を行い（ステップ３０２）、属性取得・通知部３
０で属性の取込みを行い、クライアント２９に通知する
（ステップ３０３）。
ファイル２１の各項目の属性を１度もサーバ２５から取
り込んでないときだけ、サーバ２５機能に対して属性通
知依頼を行い（ステップ３０２）、属性取得・通知部３
０で属性の取込みを行い、クライアント２９に通知する
（ステップ３０３）。
【００６３】この結果、アクセス対象のレコードファイ
ル２１の各項目の属性（数値のみを許す項目が存在）が
判明する。 で依頼された出力要求について、属性妥当性検証
部３９により、各項目の属性をチェックする（ステップ
３０４）。（ここではこのときにバッファに空きがあっ
たものとする。）数値のみを許す項目に対して、数値以
外が設定されているときには、出力しようとしたデータ
が異常である旨をアプリケーションに通知する（ステッ
プ３０５）。
ル２１の各項目の属性（数値のみを許す項目が存在）が
判明する。 で依頼された出力要求について、属性妥当性検証
部３９により、各項目の属性をチェックする（ステップ
３０４）。（ここではこのときにバッファに空きがあっ
たものとする。）数値のみを許す項目に対して、数値以
外が設定されているときには、出力しようとしたデータ
が異常である旨をアプリケーションに通知する（ステッ
プ３０５）。
【００６４】出力しようとしたデータに異常がないとき
には、非同期処理部４３においてバッファリング処理と
してバッファにレコードを蓄積し（ステップ３０６）、
アプリケーションに正常に出力された旨を通知する（模
擬結果通知）（ステップ３０７）。
には、非同期処理部４３においてバッファリング処理と
してバッファにレコードを蓄積し（ステップ３０６）、
アプリケーションに正常に出力された旨を通知する（模
擬結果通知）（ステップ３０７）。
【００６５】 アプリケーションが次のレコードの出
力（更新や追加）を要求する（ステップ３０８）。 で依頼された出力要求について、各項目の属性を
チェックする（ステップ３０９）。（当例ではバッファ
に１レコード分の空きがあったものとする。）数値のみ
を許す項目に対して、数値以外が設定されているときに
は、出力しようとしたデータが異常である旨をアプリケ
ーションに通知する（ステップ３１０）。
力（更新や追加）を要求する（ステップ３０８）。 で依頼された出力要求について、各項目の属性を
チェックする（ステップ３０９）。（当例ではバッファ
に１レコード分の空きがあったものとする。）数値のみ
を許す項目に対して、数値以外が設定されているときに
は、出力しようとしたデータが異常である旨をアプリケ
ーションに通知する（ステップ３１０）。
【００６６】出力しようとしたデータに異常がないとき
には、非同期処理として、バッファにレコードを蓄積す
る（ステップ３１１）。このときに、バッファが一杯に
なるため、サーバ２５機能に対してバッファに蓄積され
た複数レコードの出力依頼を行い（ステップ３１２）、
アプリケーションには正常に出力された旨を通知する
（模擬結果通知）（ステップ３１３）。
には、非同期処理として、バッファにレコードを蓄積す
る（ステップ３１１）。このときに、バッファが一杯に
なるため、サーバ２５機能に対してバッファに蓄積され
た複数レコードの出力依頼を行い（ステップ３１２）、
アプリケーションには正常に出力された旨を通知する
（模擬結果通知）（ステップ３１３）。
【００６７】 サーバ２５機能は、クライアント２９
機能から依頼された複数レコードの出力依頼に対して、
レコードファイル２１の入出力部２３に対して、レコー
ドの出力処理を依頼し（ステップ３１４）、処理結果を
クライアント２９機能に通知する（ステップ３１５）。
機能から依頼された複数レコードの出力依頼に対して、
レコードファイル２１の入出力部２３に対して、レコー
ドの出力処理を依頼し（ステップ３１４）、処理結果を
クライアント２９機能に通知する（ステップ３１５）。
【００６８】なお、非同期処理での複数レコード出力依
頼が装置異常等の要因で異常終了した場合、サーバ２５
機能は異常が発生した旨の処理結果をクライアント２９
機能に送信する。クライアント２９では処理結果保持部
５１でこの処理結果を保持しておく。処理結果保持部５
１は、以降のアプリケーションからの要求に対して、そ
の旨の異常を通知することで、処理を停止できる。
頼が装置異常等の要因で異常終了した場合、サーバ２５
機能は異常が発生した旨の処理結果をクライアント２９
機能に送信する。クライアント２９では処理結果保持部
５１でこの処理結果を保持しておく。処理結果保持部５
１は、以降のアプリケーションからの要求に対して、そ
の旨の異常を通知することで、処理を停止できる。
【００６９】
【発明の効果】サーバ・クライアント型のデータベース
では、出力を伴うデータベースファイル（レコードファ
イル）は、サーバ上に配置して各端末（クライアント）
で共用することによって、一元管理を行うことができ
る。
では、出力を伴うデータベースファイル（レコードファ
イル）は、サーバ上に配置して各端末（クライアント）
で共用することによって、一元管理を行うことができ
る。
【００７０】（各端末毎にレコードファイルを配置する
と、後でソートやマージ等の加工が必要となり、管理が
煩雑となる）しかし、クライアントからのレコードファ
イルへの出力に時間がかかると次のような問題が発生す
る。 ＊ 操作者の入力に対して、レスポンスが遅い ＊ バッチ処理の時間が非常に長い このため、クライアントからのレコードファイルへの出
力時間の短縮は、非常にニーズの大きいものとなってい
る。
と、後でソートやマージ等の加工が必要となり、管理が
煩雑となる）しかし、クライアントからのレコードファ
イルへの出力に時間がかかると次のような問題が発生す
る。 ＊ 操作者の入力に対して、レスポンスが遅い ＊ バッチ処理の時間が非常に長い このため、クライアントからのレコードファイルへの出
力時間の短縮は、非常にニーズの大きいものとなってい
る。
【００７１】当発明を使用することで、レコードファイ
ルへの出力において、出力処理を非同期処理又はバッフ
ァリングで行うことが可能となり、通信処理のオーバヘ
ッドを大幅に削減することができる。
ルへの出力において、出力処理を非同期処理又はバッフ
ァリングで行うことが可能となり、通信処理のオーバヘ
ッドを大幅に削減することができる。
【図１】 本発明の原理図１
【図２】 （ａ）項目の属性の取り込みを示すフロー
図、（ｂ）属性の例を示す図
図、（ｂ）属性の例を示す図
【図３】 本発明の原理図２
【図４】 制御（２−１）のフロー図
【図５】 本発明の原理図３
【図６】 制御（２−２）：チェックが必要な項目につ
いて妥当性を判定する場合のフロー図
いて妥当性を判定する場合のフロー図
【図７】 本発明の原理図４
【図８】 制御（３）：サーバで発生した異常を通知す
る処理フロー図
る処理フロー図
【図９】 本発明の実施例を示すブロック図
【図１０】 レコード更新の場合の実施例
【図１１】 レコード追加の場合の実施例
【図１２】 レコードを一括出力する場合の実施例
ＮＷ・・通信網
２１・・レコードファイル
２３・・入出力部
２５・・サーバ
２７・・操作部
２９・・クライアント
３０・・属性取得・通知部
３１・・属性通知依頼部
３３・・属性受信部
３５・・処理制御部
３７・・属性検証部
３９・・属性妥当性検証部
４１・・同期処理部
４３・・非同期処理部
４７・・疑似異常通知部
４９・・異常通知部
５１・・異常結果保持部
フロントページの続き
(56)参考文献 特開 平４−323742（ＪＰ，Ａ)
特開 平２−39372（ＪＰ，Ａ)
特開 平２−129739（ＪＰ，Ａ)
特開 平２−33665（ＪＰ，Ａ)
特開 昭60−118950（ＪＰ，Ａ)
特開 平４−353943（ＪＰ，Ａ)
(58)調査した分野(Int.Cl.7，ＤＢ名)
G06F 12/00
G06F 17/30
Claims (12)
- 【請求項１】レコードファイルへデータを出力するサー
バと、このサーバに通信網を介して接続されるクライア
ントを備えた遠隔データベースシステムにおいて、 前記サーバは、 前記クライアントからの属性通知依頼に応じて、少なく
とも重複データの存在が許されるか否かに関する情報'
を含む属性を獲得して前記クライアントに通知する属性
取得・通知部と、 前記クライアントからの出力指令に応じて、前記レコー
ドファイルへ出力を実行し、その結果に関する出力完了
通知を前記クライアントへ行う入出力部とを有し、 前記クライアントは、 前記サーバに対し前記レコードファイルの属性を通知す
るよう依頼する属性通知依頼部と、 前記サーバから送られてきた属性を取り込む属性受信部
と、 前記属性受信部で取り込まれた属性から重複データの存
在が許されるか否かを検証する属性検証部と、 前記属性検証部で重複データの存在が許されないと判定
されたとき、前記サーバに前記レコードファイルへの出
力を指名し、前記サーバからの出力完了通知を待って、
次の処理に移行する同期処理部と、 前記属性検証部で重複データの存在が許されると判定さ
れたとき、前記サーバに前記レコードファイルへの出力
を指名し、前記サーバからの出力完了通知を待たずに、
次の処理に移行する非同期処理部とを有する遠隔データ
ベースシステム。 - 【請求項２】複数の項目からなるレコードファイルへデ
ータを出力するサーバと、このサーバに通信網を介して
接続されるクライアントを備えた遠隔データベースシス
テムにおいて、 前記サーバは、 前記クライアントからの属性通知依頼に応じて、各項目
ごとに少なくともデー タの存在が許されるか否かに関す
る情報を含む属性を獲得して、前記クライアントに通知
する属性取得・通知部と、 前記クライアントからの出力指令に応じて、前記レコー
ドファイルへ出力を実行し、その結果に関する出力完了
通知を前記クライアントへ行う入出力部とを有し、 前記クライアントは、 前記サーバに対し前記レコードファイルの属性を通知す
るよう依頼する属性通知依頼部と、 前記サーバから送られてきた属性を取り込む属性受信部
と、 前記属性受信部で取り込まれた属性から重複データの存
在が許されるか否かを検出する属性検証部と、 前記属性検証部で重複データの存在が許されない項目が
少なくとも１つあると判定されたときに、前記サーバに
前記レコードファイルへの出力を指令し、前記サーバか
らの出力完了通知を待って、次の処理に移行する同期処
理部と、 前記属性検証部で重複データの存在が許されると全ての
項目が判定されたきに、前記サーバに前記レコードファ
イルへの出力を指令し、前記サーバからの出力完了通知
を待たずに、次の処理に移行する非同期処理部とを有す
る遠隔データベースシステム。 - 【請求項３】複数の項目からなるレコードファイルへデ
ータを出力するサーバと、このサーバに通信網を介して
接続されるクライアントを備えた遠隔データベースシス
テムにおいて、 前記サーバは、 前記クライアントからの属性通知依頼に応じて、各項目
ごとに少なくとも重複データの存在が許されるか否かに
関する情報を含む属性を獲得して、前記クライアントに
通知する属性取得・通知部と、 前記クライアントからの出力指令に応じて、前記レコー
ドファイルへ出力を実行し、その結果に関する出力完了
通知を前記クライアントへ行う入出力部とを有し、 前記クライアントは、 前記サーバに対し前記レコードファイルの属性を通知す
るよう依頼する属性通知依頼部と、 前記サーバから送られてきた属性を取り込む属性受信部
と、 前記属性受信部で取り込まれた属性から重複データの存
在が許されるか否かを検証する属性検証部と、 前記属性検証部で重複データの存在が許されない項目少
なくとも１つあると判定されたときに、更新レコードと
更新前レコードを比較する属性妥当性検証部と、 前記属性妥当性検証部で重複データの存在が許されない
項目の内容に変更があると判定されたときに、前記サー
バに前記レコードファイルへの出力を指令し、前記サー
バからの出力完了通知を待って、次の処理に移行する同
期処理部と、 前記属性検証部で重複データの存在が許されると全ての
項目が判定されたとき、又は、前記属性妥当性検証部で
重複データの存在が許されない項目の内容に変更がない
と判定されたときに、前記サーバに前記レコードファイ
ルへの出力を指令し、前記サーバからの出力完了通知を
待たずに、次の処理に移行する非同期処理部とを有する
遠隔データベースシステム。 - 【請求項４】レコードファイルへデータを出力するサー
バと、このサーバに通信網を介して接続されるクライア
ントを備えた遠隔データベースシステムの制御方法にお
いて、 前記クライアントが、あらかじめ前記サーバに前記レコ
ードファイルの属性を通知するよう依頼して前記サーバ
から取り込んでおいた少なくとも重複データの存在を許
すか否かに関する情報を含む属性から、重複データの存
在が許されるか否かを検証するステップと、 前記検証で重複データの存在が許されないと判定された
とき、前記クライアントが、前記サーバに前記レコード
ファイルへの出力を指令し、前記サーバからの出力完了
結果通知を待って次の処理に移行し、前記検証で重複デ
ータの存在が許されると判定されたとき、前記クライア
ントが、前記サーバに前記レコードファイルへの出力を
指令し、前記サーバからの出力完了通知を待たずに次の
処理に移行するステップと、 前記サーバが、前記クライアントからの出力指令に応じ
て前記レコードファイルへ出力を実行し、その結果に関
する出力完了通知を前記クライアントへ行うステップ
と、 を有する遠隔データベースシステムの制御方法。 - 【請求項５】複数の項目からなるレコードファイルへデ
ータを出力するサーバと、このサーバに通信網を介して
接続されるクライアントを備えた遠隔データベースシス
テムの制御方法において、 前記クライアントが、あらかじめ前記サーバに前記レコ
ードファイルの属性を通知するよう依頼して前記サーバ
から取り込んでおいた各項目ごとに少なくとも重複デー
タの存在が許されるか否かに関する情報を含む前記レコ
ードファイルの属性から、重複データの存在が許される
か否かを検証するステップと、 前記検証で重複データの存在が許されない項目が少なく
とも１つあると判定されたとき、前記クライアントが、
前記サーバに前記レコードファイルへの出力を指令し、
前記サーバからの出力完了結果通知を待って次の処理に
移行し、前記検証で重複データの存在が許されると全て
の項目が判定されたとき、前記クライアントが、前記サ
ーバに前記レコードファイルへの出力を指令し、前記サ
ーバからの出力完了通知を待たずに次の処理に移行する
ステップと、 前記サーバが、前記クライアントからの出力指令に応じ
て前記レコードファイルへ出力を実行し、その結果に関
する出力完了通知を前記クライアントへ行うステップ
と、 を有する遠隔データベースシステムの制御方法。 - 【請求項６】複数の項目からなるレコードファイルへデ
ータを出力するサーバと、このサーバに通信網を介して
接続されるクライアントを備えた遠隔データベースシス
テムの制御方法において、 前記クライアントが、あらかじめ前記サーバに前記レコ
ードファイルの属性を通知するよう依頼して前記サーバ
から取り込んでおいた各項目ごとに少なくとも重複デー
タの存在が許されるか否かに関する情報を含む前記レコ
ードファイルの属性から、重複データの存在が許される
否かを検証するステップと、 前記検証で重複データの存在が許されない項目が少なく
とも１つあると判定さ れたとき、前記クライアントが、
更新レコードと更新前レコードを比較し、前記比較で重
複データの存在が許されない項目の内容に変更があると
判定されたとき、前記クライアントが、前記サーバに前
記レコードファイルへの出力を指令し、前記サーバから
の出力完了結果通知を待って次の処理に移行し、前記検
証で重複データの存在が許されると全ての項目が判定さ
れたとき、又は、前記比較で重複データの存在が許され
ない項目の内容に変更がないと判定されたとき、前記ク
ライアントが、前記サーバに前記レコードファイルへの
出力を指令し、前記サーバからの出力完了通知を待たず
に次の処理に移行するステップと、 前記サーバが、前記クライアントからの出力指令に応じ
て前記レコードファイルへ出力を実行し、その結果に関
する出力完了通知を前記クライアントへ行うステップ
と、 を有する遠隔データベースシステムの制御方法。 - 【請求項７】レコードファイルへデータを出力するサー
バに通信網を介して接続さるクライアントを備えた遠隔
データベース端末装置において、 前記サーバに対し前記レコードファイルの属性を通知す
るよう依頼する属性通知依頼部と、 前記サーバから送られてきた少なくとも重複データの存
在が許されるか否かに関する情報を含む属性を取り込む
属性受信部と、 前記属性受信部で取り込まれた属性から重複データの存
在が許されるか否かを検証する属性検証部と、 前記属性検証部で重複データの存在が許されないと判定
されたとき、前記サーバに前記レコードファイルへの出
力を指令し、前記サーバからの出力完了通知を待って、
次の処理に移行する同期処理部と、 前記属性険証部で重複データの存在が許されると判定さ
れたとき、前記サーバに前記レコードファイルへの出力
を指令し、前記サーバからの出力完了通知を待たずに、
次の処理に移行する非同期処理部とを有する遠隔データ
ベース端末装置。 - 【請求項８】複数の項目からなるレコードファイルへデ
ータを出力するサーバに通信網を介して接続されるクラ
イアントを備えた遠隔データベース端末装置にお いて、 前記サーバに対し前記レコードファイルの属性を通知す
るよう依頼する属性通知依頼部と、 前記サーバから送られてきた各項目ごとに少なくとも重
複データの存在が許される否かに関する情報を含む属性
を取り込む属性受信部と、 前記属性受信部で取り込まれた属性から重複データの存
在が許されるか否かを検証する属性検証部と、 前記属性検証部で重複データの存在が許されない項目が
少なくとも１つあると判定されたとき、前記サーバに前
記レコードファイルへの出力を指令し、前記サーバから
出力完了通知を待って、次の処理に移行する同期処理部
と、 前記属性検証部で重複データの存在が許されると全ての
項目が判定されたとき、前記サーバに前記レコードファ
イルへの出力を指令し、前記サーバからの出力完了通知
を待たずに、次の処理に移行する非同期処理部とを有す
る遠隔データベース端末装置。 - 【請求項９】複数の項目からなるレコードファイルへデ
ータを出力するサーバに通信網を介して接続されるクラ
イアントを備えた遠隔データベース端末装置において、 前記サーバに対し前記レコードファイルの属性を通知す
るよう依頼する属性通知依頼部と、 前記サーバから送られてきた各項目ごとに少なくとも重
複データの存在が許されるか否かに関する情報を含む属
性を取り込む属性受信部と、 前記属性受信部で取り込まれた属性から重複データの存
在が許されるか否かに関する情報を取り込む属性検証部
と、 前記属性検証部で重複データの存在が許されない項目が
少なくとも１つあると判定されたとき、更新レコードと
更新前レコードとを比較する属性妥当性検証部と、 前記属性妥当性検証部で、重複データの存在が許されな
い項目の内容に変更があると判定されたときに、前記サ
ーバに前記レコードファイルへの出力を指令し、前記サ
ーバからの出力完了通知を待って、次の処理に移行する
同期処理部と、 前記属性検証部で重複データの存在が許されると全ての
項目が判定されたとき、又は、前記属性妥当性検証部で
重複データの存在が許されない項目の内容に変更がない
と判定さたとき、前記サーバに前記レコードファイルへ
の出力を指令し、前記サーバからの出力完了通知を待た
ずに、次の処理に移行する非同期処理部とを有する遠隔
データベース端末装置。 - 【請求項１０】レコードファイルへデータを出力するサ
ーバに通信網を介して接続されるクライアントを備えた
遠隔データベース端末装置の制御方法において、 あらかじめ前記サーバに前記レコードファイルの属性を
通知するよう依頼して前記サーバから取り込んでおいた
少なくとも重複データの存在が許されるか否かに関する
情報を含む前記レコードファイルの属性から、重複デー
タの存在が許されるか否かを検証するステップと、 前記検証で重複データの存在が許されないと判定された
とき、前記サーバに前記レコードファイルへの出力を指
令し、前記サーバからの出力完了結果通知を待って次の
処理に移行し、前記検証で重複データの存在が許される
と判定されたとき、前記サーバに前記レコードファイへ
の出力を指令し、前記サーバからの出力完了通知を待た
ずに次の処理に移行するステップと、 を有する遠隔データベース端末装置の制御方法。 - 【請求項１１】複数の項目からなるレコードファイルデ
ータを出力するサーバに通信網を介して接続されるクラ
イアントを備えた遠隔データベース端末装置の制御方法
において、 あらかじめ前記サーバに前記レコードファイルの属性を
通知するよう依頼して前記サーバから取り込んでおいた
各項目ごとに少なくとも重複データの存在が許されるか
否かに関する情報を含む前記レコードファイルの属制か
ら、重複データの存在が許されるか否かを検証するステ
ップと、 前記検証で重複データの存在が許されない項目が少なく
とも１つあると判定されたとき、前記サーバに前記レコ
ードファイルへの出力を指令し、前記サーバからの出力
完了通知を待って次の処理に移行し、前記検証で重複デ
ータの存在が許されると全ての項目が判定されたとき、
前記サーバに前記レコードファイルへの出力を指令し、
前記サーバからの出力完了通知を待たずに次の処理に移
行するス テップとを有する遠隔データベース端末装置の
制御方法。 - 【請求項１２】複数の項目からなるレコードファイルへ
データを出力するサーバに通信網を介して接続されるク
ライアントを備えた遠隔データベース端末装置の制御方
法において、 あらかじめ前記サーバに前記レコードファイルの属性を
通知するよう依頼して前記サーバから取り込んでおいた
各項目ごとに少なくとも重複データの存在が許されるか
否かに関する情報を含む前記レコードファイルの属性か
ら、重複データの存在が許されるか否かを検証するステ
ップと、 前記検証で重複データの存在が許されない項目が少なく
とも１つあると判定されたとき、更新レコードと更新前
レコードを比較し、前記比較で重複データの存在が許さ
れない項目の内容に変更があると判定されたとき、前記
サーバに前記レコードファイルへの出力を指令し、前記
サーバからの出力完了結果通知を待って次の処理に移行
し、前記検証で重複データの存在が許されると全ての項
目が判定されたとき、又は、前記比較で重複データの存
在が許されない項目の内容に変更がないと判定されたと
き、前記サーバに前記レコードファイルへの出力を指令
し、前記サーバからの出力完了通知を待たずに次の処理
に移行するステップとを有する遠隔データベース端末装
置の制御方法。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP31528492A JP3503957B2 (ja) | 1992-11-25 | 1992-11-25 | 遠隔データベースの制御方法及び装置 |
| US08/590,046 US5640556A (en) | 1992-11-25 | 1996-01-03 | Synchronous/asynchronous client server access based upon database file record attribute |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP31528492A JP3503957B2 (ja) | 1992-11-25 | 1992-11-25 | 遠隔データベースの制御方法及び装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH06162086A JPH06162086A (ja) | 1994-06-10 |
| JP3503957B2 true JP3503957B2 (ja) | 2004-03-08 |
Family
ID=18063552
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP31528492A Expired - Fee Related JP3503957B2 (ja) | 1992-11-25 | 1992-11-25 | 遠隔データベースの制御方法及び装置 |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US5640556A (ja) |
| JP (1) | JP3503957B2 (ja) |
Families Citing this family (32)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH0863382A (ja) * | 1994-08-19 | 1996-03-08 | Fujitsu Ltd | 分散システムにおけるデータ整合性確認方法及びデータ整合性確認装置 |
| CA2168087A1 (en) * | 1995-02-13 | 1996-08-14 | James S. Coman | Operating system based remote communication system |
| JP3347914B2 (ja) * | 1995-05-26 | 2002-11-20 | シャープ株式会社 | データ管理装置 |
| US6085223A (en) * | 1995-10-20 | 2000-07-04 | Ncr Corporation | Method and apparatus for providing database information to non-requesting clients |
| US5930786A (en) | 1995-10-20 | 1999-07-27 | Ncr Corporation | Method and apparatus for providing shared data to a requesting client |
| WO1998006055A1 (en) * | 1996-08-08 | 1998-02-12 | Rapaport Jeffrey Alan | Apparatus and method for obtaining information from a computer network using a scanner and browser |
| US5970496A (en) * | 1996-09-12 | 1999-10-19 | Microsoft Corporation | Method and system for storing information in a computer system memory using hierarchical data node relationships |
| JP3780610B2 (ja) * | 1997-03-28 | 2006-05-31 | 富士通株式会社 | 課金情報出力装置 |
| JPH10285164A (ja) * | 1997-04-09 | 1998-10-23 | Nec Corp | ネットワーク管理システム及び方法並びにネットワーク管理プログラムを記録した記録媒体 |
| US6148417A (en) * | 1998-01-14 | 2000-11-14 | Micron Electronics, Inc. | Method for determining a source of failure during a file system access |
| US6378004B1 (en) | 1998-05-07 | 2002-04-23 | Compaq Computer Corporation | Method of communicating asynchronous elements from a mini-port driver |
| US6901596B1 (en) | 1998-05-07 | 2005-05-31 | Hewlett-Packard Development Company, L.P. | Method of communicating asynchronous events to remote procedure call clients |
| JP2000122814A (ja) * | 1998-10-15 | 2000-04-28 | Hitachi Ltd | 拡張型ネットワーク接続二次記憶方法及び装置 |
| US6321238B1 (en) * | 1998-12-28 | 2001-11-20 | Oracle Corporation | Hybrid shared nothing/shared disk database system |
| JP4158297B2 (ja) * | 1999-11-12 | 2008-10-01 | 株式会社日立製作所 | 分散システムにおける属性データの一致化方法および分散システム |
| US6418449B1 (en) * | 2000-01-06 | 2002-07-09 | Inventec Corporation | Method of cloning the file system of a window web operating system by using a bitmap file |
| US6643669B1 (en) | 2000-03-14 | 2003-11-04 | Telefonaktiebolaget Lm Ericsson (Publ) | Method for optimization of synchronization between a client's database and a server database |
| US7401131B2 (en) * | 2000-05-22 | 2008-07-15 | Verizon Business Global Llc | Method and system for implementing improved containers in a global ecosystem of interrelated services |
| US6922685B2 (en) | 2000-05-22 | 2005-07-26 | Mci, Inc. | Method and system for managing partitioned data resources |
| US7280558B1 (en) * | 2001-06-28 | 2007-10-09 | Microsoft Corporation | Asynchronous pattern |
| JP2003091432A (ja) * | 2001-09-19 | 2003-03-28 | Nec Corp | ソフトウェア評価システム、ソフトウェア評価ツール |
| KR100428777B1 (ko) * | 2002-02-14 | 2004-04-28 | 삼성전자주식회사 | 클라이언트/서버 시스템의 클라이언트간의 동기화 방법 |
| US7222139B2 (en) * | 2002-07-30 | 2007-05-22 | International Business Machines Corporation | Method, system and program for synchronizing data |
| US7676516B2 (en) * | 2002-10-15 | 2010-03-09 | Active-Base Ltd. | System and method for the optimization of database access in data base networks |
| US20050076325A1 (en) * | 2003-10-02 | 2005-04-07 | International Business Machines Corporation | Automatic software update of nodes in a network data processing system |
| US20050108246A1 (en) * | 2003-10-31 | 2005-05-19 | Doug Dillon | Systems and methods for accelerating data retrieval |
| US7814065B2 (en) * | 2005-08-16 | 2010-10-12 | Oracle International Corporation | Affinity-based recovery/failover in a cluster environment |
| US9549025B2 (en) * | 2006-05-09 | 2017-01-17 | International Business Machines Corporation | Protocol optimization for client and server synchronization |
| US8321914B2 (en) | 2008-01-21 | 2012-11-27 | International Business Machines Corporation | System and method for verifying an attribute in records for procurement application |
| JP2010198200A (ja) * | 2009-02-24 | 2010-09-09 | Nippon Telegr & Teleph Corp <Ntt> | プロファイル情報管理装置、プロファイル情報管理方法、及びプログラム |
| US8364636B2 (en) * | 2009-09-14 | 2013-01-29 | International Business Machines Corporation | Real time data replication |
| JP7355312B2 (ja) * | 2019-03-15 | 2023-10-03 | 株式会社ジョブカン会計 | データ編集処理システム及びデータ編集処理プログラム |
Family Cites Families (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPS63138439A (ja) * | 1986-12-01 | 1988-06-10 | Hitachi Ltd | 分散データベースアクセス要求処理方法 |
| US4887204A (en) * | 1987-02-13 | 1989-12-12 | International Business Machines Corporation | System and method for accessing remote files in a distributed networking environment |
| US5126728A (en) * | 1989-06-07 | 1992-06-30 | Hall Donald R | ADP security device for labeled data |
| US5237684A (en) * | 1991-08-12 | 1993-08-17 | International Business Machines Corporation | Customized and versatile event monitor within event management services of a computer system |
| US5307490A (en) * | 1992-08-28 | 1994-04-26 | Tandem Computers, Inc. | Method and system for implementing remote procedure calls in a distributed computer system |
| US5329619A (en) * | 1992-10-30 | 1994-07-12 | Software Ag | Cooperative processing interface and communication broker for heterogeneous computing environments |
-
1992
- 1992-11-25 JP JP31528492A patent/JP3503957B2/ja not_active Expired - Fee Related
-
1996
- 1996-01-03 US US08/590,046 patent/US5640556A/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JPH06162086A (ja) | 1994-06-10 |
| US5640556A (en) | 1997-06-17 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3503957B2 (ja) | 遠隔データベースの制御方法及び装置 | |
| US5586310A (en) | System for distributed database replicated read with exclusive central server transfer of primary copies | |
| US7073120B2 (en) | Structured document transformation method, structured document transformation apparatus, and program product | |
| JP3335801B2 (ja) | 異種ファイルへのアクセスを可能とする情報処理システム及びその制御方法 | |
| US6850938B1 (en) | Method and apparatus providing optimistic locking of shared computer resources | |
| US6978381B1 (en) | Enhancement to a system for automated generation of file access control system commands | |
| US5329628A (en) | Database system providing direct access for reads and indirect locked access for writes and reads in which an error was detected in previous attempt | |
| JP2004528636A (ja) | 自動データ更新 | |
| JPH0833857B2 (ja) | システム間デ−タベ−ス共用システムジヤ−ナルマ−ジ方式 | |
| US20060136516A1 (en) | Techniques for maintaining consistency for different requestors of files in a database management system | |
| WO1997021177A1 (en) | Database access | |
| JPH06215031A (ja) | 分散データ処理装置及び方法 | |
| JPH034340A (ja) | データ処理システム | |
| US20100070473A1 (en) | Distributed Data Store with a Designated Master to Ensure Consistency | |
| CN112148745B (zh) | 一种多HBase集群访问方法、装置及存储介质 | |
| US6938055B2 (en) | Data processing system and method and storage medium storing data processing program | |
| JP2881628B2 (ja) | 排他制御システムおよび端末装置 | |
| JP2939414B2 (ja) | 二重系計算機のデータベース等価処理装置 | |
| US20060136509A1 (en) | Techniques for transaction semantics for a database server performing file operations | |
| JP3330006B2 (ja) | 情報記憶システムを備えるネットワークシステム、該システムの入力システムならびに | |
| JPH05108452A (ja) | データベース管理方式 | |
| JP3006527B2 (ja) | クライアント／サーバ型データベースシステム | |
| JP2980610B2 (ja) | トランザクション管理装置 | |
| JP2897807B2 (ja) | ネットワークシステムの機密保護装置 | |
| CN113590580A (zh) | 基于区块链的数据库管理方法、装置及存储介质 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20031202 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20031209 |
|
| LAPS | Cancellation because of no payment of annual fees |