JP3615150B2 - データ処理サーバ及び方法並びにデータ処理プログラムを記録した記録媒体 - Google Patents
データ処理サーバ及び方法並びにデータ処理プログラムを記録した記録媒体 Download PDFInfo
- Publication number
- JP3615150B2 JP3615150B2 JP2001023005A JP2001023005A JP3615150B2 JP 3615150 B2 JP3615150 B2 JP 3615150B2 JP 2001023005 A JP2001023005 A JP 2001023005A JP 2001023005 A JP2001023005 A JP 2001023005A JP 3615150 B2 JP3615150 B2 JP 3615150B2
- Authority
- JP
- Japan
- Prior art keywords
- record
- recorded
- data
- value
- received
- 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
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、データを処理するためのデータ処理方法に関し、さらに、そのようなデータ処理方法を用いるデータ処理サーバ、及び、データ処理プログラムを記録した記録媒体に関する。
【０００２】
【従来の技術】
従来より、種々のデータをレコードとして格納し、レコードに対して各種の操作等を行うデータベースシステムが用いられている。
このようなデータベースシステムに格納されたあるレコードに対して、複数のユーザが重複して更新する場合がある。例えば、あるレコードに対して、第１のユーザが読み出し操作を行い、第２のユーザが読み出し操作を行い、第１のユーザが更新操作を行い、第２のユーザが更新操作を行う場合である。この場合には、第１のユーザの更新操作の結果が、第２のユーザの更新操作の結果によって上書きされ、失われてしまうこととなる。
【０００３】
このような同一レコードに対する複数のユーザの重複更新を防止するため、従来のデータベースシステムにおいて、レコードロック、ページロック、テーブルロック、データベースロック等を含むロック法等の排他制御が行われていた。
しかしながら、従来のロック法は、多くの計算時間（処理時間）を必要とする。また、あるレコードがレコードロックされている場合に、所定の条件（例えば、更新ページが所定数を超える等）を満たすことによりレコードロックからテーブルロック等に移行し（ロックエスカレーション）、ひいては他のデータベース操作との間でデッドロックを招く場合があった。更に、あるユーザの操作によってロックされているレコードに対し、他のユーザが更新操作のみならず読み出し操作をも行うことができない場合があった。
【０００４】
一方、上記のようなデータベースシステムが、企業等の会計業務に用いられている。このようにデータベースシステムが会計業務に用いられている場合に、企業等の第ｋ期会計期間から第（ｋ＋１）期会計期間への移行時から所定の期間（一般に、会計期間の移行時から数日〜十数日程度）において、多数の伝票データ（第ｋ期会計期間の伝票データと第（ｋ＋１）期会計期間の伝票データとの双方を含む）の入力、決算処理等が集中し、円滑な会計業務を遂行できない場合があった。
【０００５】
そのため、従来のデータベースシステムを用いた会計業務では、会計期間の移行時から所定の期間内における伝票データの入力を一切禁止し、第ｋ期会計期間の決算処理が終了した後に伝票データの入力を再開するか、又は会計期間の移行時から所定の期間内に入力された伝票データを仮の記録領域に記録しておき、第ｋ期会計期間の決算処理が終了した後に仮の記録領域に記録されていた伝票データを会計業務用の記録領域に転送していた。
【０００６】
【発明が解決しようとする課題】
そこで、上記の点に鑑み、本発明は、同一レコードに対する複数ユーザの重複読み出しを可能にしつつ、重複更新を防止することができるデータ処理サーバ及びデータ処理方法、並びにデータ処理プログラムを記録した記録媒体を提供することを目的とする。また、本発明は、データの入力とデータに対する処理を並行して行うことができるデータ処理サーバ及びデータ処理方法、並びにデータ処理プログラムを記録した記録媒体を提供することを更なる目的とする。
【０００７】
【課題を解決するための手段】
以上の課題を解決するため、本発明の第１の観点に係るデータ処理サーバは、複数の装置と通信することによりデータを処理するサーバであって、複数のレコードを記録する記録手段と、所定の起算日から現在までの累積日数を計数してその値を出力する累積日数計数手段と、第ｎ番目のナンバー生成要求に応じて、ｘ（ｉ）＜ｘ（ｎ）（ｉ＝１、・・・、（ｎ−１））を満たすナンバーｘ（ｎ）であって、累積日数計数手段が出力した値を上位桁とし、その日に起動又はリブートされた回数の値を中位桁とし、その日にナンバー生成を要求された回数の値を下位桁とするナンバーを生成するナンバー生成手段と、複数の装置の内のいずれかの装置からデータを受信した場合に、ナンバー生成手段にナンバー生成要求を行い、受信したデータ及びナンバー生成手段から出力されたナンバーを含むレコードを記録手段に書き込むレコード作成手段と、複数の装置の内のいずれかの装置から記録手段に記録されたレコードを読み出す旨の要求を受信した場合に、要求されたレコードを記録手段から読み出して装置に出力するレコード読出し手段と、複数の装置の内のいずれかの装置からデータが編集されたレコードを受信した場合に、受信したレコード内のナンバーと記録手段に記録されている更新対象のレコード内のナンバーとが一致するか否かをチェックし、受信したレコード内のナンバーと記録手段に記録されている更新対象のレコード内のナンバーとが一致する場合に、ナンバー生成手段にナンバー生成要求を行い、受信したレコード内のナンバーをナンバー生成手段から出力されたナンバーで置き換えたレコードを記録手段に書き込むレコード更新手段とを具備する。
【０００８】
また、本発明の第２の観点に係るデータ処理サーバは、複数の装置と通信することによりデータを処理するサーバであって、複数のレコードを記録する記録手段と、所定の起算日から現在までの累積日数を計数してその値を出力する累積日数計数手段と、第ｎ番目のナンバー生成要求に応じて、ｘ（ｉ）＜ｘ（ｎ）（ｉ＝１、・・・、（ｎ−１））を満たすナンバーｘ（ｎ）であって、累積日数計数手段が出力した値を上位桁とし、その日に起動又はリブートされた回数の値を中位桁とし、その日にナンバー生成を要求された回数の値を下位桁とするナンバーを生成して出力するナンバー生成手段と、複数の装置の内のいずれかの装置からデータを受信した場合に、ナンバー生成手段にナンバー生成要求を行い、受信したデータ及びナンバー生成手段から出力されたナンバーを含むレコードを記録手段に書き込むレコード作成手段と、記録手段に記録されているレコードの内で複数の装置の内のいずれかの装置によって指示されたデータを含むレコード内のナンバーより小さいナンバーを有するレコードに対して集計処理を行うレコード処理手段とを具備する。
【０００９】
また、本発明の第１の観点に係るデータ処理方法は、複数の装置と通信することによりデータを処理する方法であって、所定の起算日から現在までの累積日数を計数してその値を出力するステップ（ａ）と、ナンバー生成手段において、第ｎ番目のナンバー生成要求に応じて、ｘ（ｉ）＜ｘ（ｎ）（ｉ＝１、・・・、（ｎ−１））を満たすナンバーｘ（ｎ）であって、ステップ（ａ）が出力した値を上位桁とし、その日に起動又はリブートされた回数の値を中位桁とし、その日にナンバー生成を要求された回数の値を下位桁とするナンバーを生成するステップ（ｂ）と、複数の装置の内のいずれかの装置からデータを受信した場合に、ナンバー生成手段にナンバー生成要求を行い、受信したデータ及びナンバー生成手段から出力されたナンバーを含むレコードを記録媒体に記録するステップ（ｃ）と、複数の装置の内のいずれかの装置からレコードを読み出す旨の要求を受信した場合に、要求されたレコードを記録媒体から読み出して装置に出力するステップ（ｄ）と、複数の装置の内のいずれかの装置からデータが編集されたレコードを受信した場合に、受信したレコード内のナンバーと記録媒体に記録されている更新対象のレコード内のナンバーとが一致するか否かをチェックし、受信したレコード内のナンバーと記録媒体に記録されている更新対象のレコード内のナンバーとが一致する場合に、ナンバー生成手段にナンバー生成要求を行い、受信したレコード内のナンバーをナンバー生成手段から出力されたナンバーで置き換えたレコードを記録媒体に書き込むステップ（ｅ）とを具備する。
【００１０】
また、本発明の第２の観点に係るデータ処理方法は、複数の装置と通信することによりデータを処理する方法であって、所定の起算日から現在までの累積日数を計数してその値を出力するステップ（ａ）と、ナンバー生成手段において、第ｎ番目のナンバー生成要求に応じて、ｘ（ｉ）＜ｘ（ｎ）（ｉ＝１、・・・、（ｎ−１））を満たすナンバーｘ（ｎ）であって、ステップ（ａ）が出力した値を上位桁とし、その日に起動又はリブートされた回数の値を中位桁とし、その日にナンバー生成を要求された回数の値を下位桁とするナンバーを生成するステップ（ｂ）と、複数の装置の内のいずれかの装置からデータを受信した場合に、ナンバー生成手段にナンバー生成要求を行い、受信したデータ及びナンバー生成手段から出力されたナンバーを含むレコードを記録媒体に書き込むステップ（ｃ）と、記録媒体に記録されているレコードの内で複数の装置の内のいずれかの装置によって指示されたデータを含むレコード内のナンバーより小さいナンバーを有するレコードに対して集計処理を行うステップ（ｄ）とを具備する。
【００１１】
また、本発明の第１の観点に係るデータ処理プログラムを記録した記録媒体は、複数の装置と通信することによりデータを処理するためにＣＰＵで読み取り可能な記録媒体であって、所定の起算日から現在までの累積日数を計数してその値を出力する手順（ａ）と、ナンバー生成手段において、第ｎ番目のナンバー生成要求に応じて、ｘ（ｉ）＜ｘ（ｎ）（ｉ＝１、・・・、（ｎ−１））を満たすナンバーｘ（ｎ）であって、手順（ａ）が出力した値を上位桁とし、その日に起動又はリブートされた回数の値を中位桁とし、その日にナンバー生成を要求された回数の値を下位桁とするナンバーを生成する手順（ｂ）と、複数の装置の内のいずれかの装置からデータを受信した場合に、ナンバー生成手段にナンバー生成要求を行い、受信したデータ及びナンバー生成手段から出力されたナンバーを含むレコードを記録媒体に記録する手順（ｃ）と、複数の装置の内のいずれかの装置からレコードを読み出す旨の要求を受信した場合に、要求されたレコードを記録媒体から読み出して装置に出力する手順（ｄ）と、複数の装置の内のいずれかの装置からデータが編集されたレコードを受信した場合に、受信したレコード内のナンバーと記録媒体に記録されている更新対象のレコード内のナンバーとが一致するか否かをチェックし、受信したレコード内のナンバーと記録媒体に記録されている更新対象のレコード内のナンバーとが一致する場合に、ナンバー生成手段にナンバー生成要求を行い、受信したレコード内のナンバーをナンバー生成手段から出力されたナンバーで置き換えたレコードを記録媒体に書き込む手順（ｅ）とをＣＰＵに実行させる。
【００１２】
また、本発明の第２の観点に係るデータ処理プログラムを記録した記録媒体は、複数の装置と通信することによりデータを処理するためにＣＰＵで読み取り可能な記録媒体であって、所定の起算日から現在までの累積日数を計数してその値を出力する手順（ａ）と、ナンバー生成手段において、第ｎ番目のナンバー生成要求に応じて、ｘ（ｉ）＜ｘ（ｎ）（ｉ＝１、・・・、（ｎ−１））を満たすナンバーｘ（ｎ）であって、手順（ａ）が出力した値を上位桁とし、その日に起動又はリブートされた回数の値を中位桁とし、その日にナンバー生成を要求された回数の値を下位桁とするナンバーを生成する手順（ｂ）と、複数の装置の内のいずれかの装置からデータを受信した場合に、ナンバー生成手段にナンバー生成要求を行い、受信したデータ及びナンバー生成手段から出力されたナンバーを含むレコードを記録媒体に書き込む手順（ｃ）と、記録媒体に記録されているレコードの内で複数の装置の内のいずれかの装置によって指示されたデータを含むレコード内のナンバーより小さいナンバーを有するレコードに対して集計処理を行う手順（ｄ）とをＣＰＵに実行させる。
【００１３】
本発明の第１の観点によれば、データが編集されたレコード内のナンバーと更新対象レコード内のナンバーとが一致する場合にのみレコードを更新するので、同一レコードに対する複数ユーザの重複読み出しを可能にしつつ、重複更新を防止することができる。また、本発明の第２の観点によれば、複数の装置の内のいずれかの装置によって指示されたデータを含むレコード内のナンバーより小さいナンバーを含むレコードにのみ集計処理を行うので、データの入力とデータに対する処理とを並行して行うことができる。
【００１４】
【発明の実施の形態】
以下、図面に基づいて本発明の実施の形態について説明する。なお、同一の構成要素には同一の参照番号を付して説明を省略する。
まず、本発明の第１の実施形態に係るデータ処理方法について説明する。図１は、本発明の第１の実施形態に係るデータ処理方法を実施するためのシステムを示す図である。
図１に示すように、このシステム１は、クライアント端末１１〜１ｎと、サーバ２１とを備えている。
クライアント端末１１〜１ｎ及びサーバ２１は、ＬＡＮ、公衆回線網、インターネット等のネットワーク３１によって相互に接続されている。
クライアント端末１１〜１ｎは、ユーザがサーバ２１を利用するためのＰＣ等である。
【００１５】
図２は、サーバ２１を示す図である。図２に示すように、サーバ２１は、システムデート管理部２２と、システムイベントナンバー生成部２３と、レコード作成部２４と、レコード読出し部２５と、レコード更新部２６と、記録媒体２７とを含んでいる。
システムデート管理部２２は、サーバ２１のシステムデートの管理を行い、所定の起算日を”００００１”とした場合のシステムデートまでの日数（以下、「累積日数」ともいう）をカウントし、その数値を出力する。例えば、１９９９年１月１日が起算日であり、システムデートが２００１年１月１日である場合には、累積日数は７３１日となり、システムデート管理部２２は”００７３１”を出力する。
【００１６】
システムイベントナンバー生成部２３は、レコード作成部２４及びレコード更新部２６からの要求に応じて、１８桁の数であるＳＥＮ（システムイベントナンバー、以下においては単に「ナンバー」ともいう）を生成して出力する。また、システムイベントナンバー生成部２３は、生成したナンバーを所定時に記録媒体２７に書き込む。
ここで、ナンバーについて詳しく説明する。図３は、ナンバーのフォーマットを示す図である。図３に示すように、ナンバーは、上位５桁（Ｄ１Ｄ２Ｄ３Ｄ４Ｄ５）、中位４桁（Ｓ１Ｓ２Ｓ３Ｓ４）、及び、下位９桁（Ｃ１Ｃ２Ｃ３Ｃ４Ｃ５Ｃ６Ｃ７Ｃ８Ｃ９）を結合した数である。
【００１７】
ナンバーの上位５桁（Ｄ１Ｄ２Ｄ３Ｄ４Ｄ５）は、このナンバーが生成された日の累積日数を示す数値である。従って、システムイベントナンバー生成部２３は、起算日から９９，９９９日目まで、即ち起算日から約２７０年後まで、ナンバーを生成することができる。
【００１８】
ナンバーの下位９桁（Ｃ１Ｃ２Ｃ３Ｃ４Ｃ５Ｃ６Ｃ７Ｃ８Ｃ９）は、ナンバー生成要求毎にインクリメントされた数である。なお、ナンバーの下位９桁（Ｃ１Ｃ２Ｃ３Ｃ４Ｃ５Ｃ６Ｃ７Ｃ８Ｃ９）からキャリーが発生した場合には、そのキャリーがナンバーの中位４桁（Ｓ１Ｓ２Ｓ３Ｓ４）に伝搬される。
【００１９】
ナンバーの中位４桁（Ｓ１Ｓ２Ｓ３Ｓ４）は、原則として、サーバ２１が同一日内でリブート（停電、故障等によりサーバ２１が停止し、その後再起動した場合等を含む）された回数とナンバーの下位９桁（Ｃ１Ｃ２Ｃ３Ｃ４Ｃ５Ｃ６Ｃ７Ｃ８Ｃ９）からのキャリーとの和である。但し、後にナンバー生成処理の説明において述べるように、ナンバーの中位４桁（Ｓ１Ｓ２Ｓ３Ｓ４）は、システムデート管理部２２によって管理されているシステムデートが正しい日付よりも古い日付に誤設定されている状態でサーバ２１が起動又はリブートされた場合には、インクリメントされる。従って、システムイベントナンバー生成部２３は、サーバ２１が同一日内でリブートされた回数と、システムデートが古い日付に誤設定されている状態でサーバ２１が起動又はリブートされた回数と、下位９桁（Ｃ１Ｃ２Ｃ３Ｃ４Ｃ５Ｃ６Ｃ７Ｃ８Ｃ９）からのキャリーとの合計が９，９９９となるまで、ナンバーを生成することができる。
【００２０】
なお、システムイベントナンバー生成部２３は、サーバ２１が同一日内に一度もリブートされていない場合には、中位４桁（Ｓ１Ｓ２Ｓ３Ｓ４）と下位９桁（Ｃ１Ｃ２Ｃ３Ｃ４Ｃ５Ｃ６Ｃ７Ｃ８Ｃ９）を合わせて、同一日内に９，９９９，９９９，９９９，９９９回までナンバーを生成できることとなる。
一方、動作周波数が６００ＭＨｚのＣＰＵとソフトウェアとを用いてナンバーを生成するために必要な時間を実測したところ、１０，０００回のナンバー生成処理に０．７秒の時間が必要であった。すなわち、ナンバー生成１回当たり０．００００７秒の時間が必要であった。
【００２１】
従って、９，９９９，９９９，９９９，９９９回のナンバー生成処理には、０．００００７（秒／回）に９，９９９，９９９，９９９，９９９（回）を乗じた約７億秒（約８１００日）が必要となる。更に、ナンバーの生成とともに各種のデータベース操作処理を行うことをも考慮すると、ナンバーは実用上十分な桁数を有することとなる。また、上記したように、サーバ２１が同一日内にリブートされ又はシステムデートが古い日付に誤設定されている状態でリブートされた場合には、ナンバーの中位４桁（Ｓ１Ｓ２Ｓ３Ｓ４）がインクリメントされるため、同一日内にナンバーを生成することができる回数が１，０００，０００，０００回ずつ減って行くことになる。しかし、このような事態を考慮しても、ナンバーは実用上十分な桁数を有すると考えられる。
【００２２】
レコード作成部２４は、クライアント端末１１〜１ｎからデータを受信し、受信したデータ及びナンバーを含むレコードを新規レコードとして記録媒体２７内のデータベースに書き込む。
レコード読出し部２５は、クライアント端末１１〜１ｎからの要求に応じて、記録媒体２７内のデータベースからレコードを読み出して出力する。
レコード更新部２６は、クライアント端末１１〜１ｎからレコードを受信し、受信したレコード内のナンバーと記録媒体２７内の更新対象レコード内のナンバーとが一致する場合に、受信したレコードによって記録媒体２７内のデータベースに格納されている更新対象レコードを更新（上書き）する。
【００２３】
記録媒体２７は、データベース、システムイベントナンバー生成部２３によって生成されたナンバー等を記録する。記録媒体２７としては、ハードディスク、フロッピーディスク、ＭＯ、ＭＴ、ＲＡＭ、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ等が該当する。
なお、図２に示すシステムデート管理部２２、システムイベントナンバー生成部２３、レコード作成部２４、レコード読出し部２５、及び、レコード更新部２６は、ＣＰＵとソフトウェア（プログラム）で構成することができる。このプログラムと、各種データベース及びアプリケーションデータファイルの各々は、ハードディスク、フロッピーディスク、ＭＯ、ＭＴ、ＲＡＭ、ＣＤ−ＲＯＭ、又は、ＤＶＤ−ＲＯＭ等の記録媒体に記録することができる。
【００２４】
次に、サーバ２１の動作について説明する。
まず、レコード作成部２４、レコード読出し部２５、及び、レコード更新部２６によるレコード操作の説明に先だって、システムイベントナンバー生成部２３の動作について説明する。
図４は、システムイベントナンバー生成部２３の起動処理動作の概要を示すフローチャートである。以下、システムイベントナンバー生成部２３の起動処理動作について、図４を参照しながら説明する。
【００２５】
サーバ２１が起動又はリブートされると、システムイベントナンバー生成部２３は、図４の処理を開始する。
図４の処理を開始すると、システムイベントナンバー生成部２３は、記録媒体２７に記録されているナンバーを読み出す（ステップＳ１０１）。
【００２６】
次に、システムイベントナンバー生成部２３は、ステップＳ１０１にて読み出したナンバー（以下、「最終記録ナンバー」ともいう）の上位５桁（Ｄ１Ｄ２Ｄ３Ｄ４Ｄ５）がシステムデート管理部２２によって管理されている現在の累積日数の数値以上であるか否か、即ち最終記録ナンバーを記録した日と同一日内にリブートされ又はシステムデート管理部２２によって管理されているシステムデートが古い日付に誤設定されているか否かをチェックする。そして、システムイベントナンバー生成部２３は、最終記録ナンバーの上位５桁（Ｄ１Ｄ２Ｄ３Ｄ４Ｄ５）が現在の累積日数より小さければ処理をステップＳ１０３に移し、最終記録ナンバーの上位５桁（Ｄ１Ｄ２Ｄ３Ｄ４Ｄ５）が現在の累積日数以上であれば処理をステップＳ１０４に移す（ステップＳ１０２）。
【００２７】
ステップＳ１０２にて最終記録ナンバーの上位５桁（Ｄ１Ｄ２Ｄ３Ｄ４Ｄ５）が現在の累積日数より小さいと判断した場合、即ち最終記録ナンバーを記録した日と同一日内にリブートされておらず且つシステムデートが誤設定されていないと判断した場合には、システムイベントナンバー生成部２３は、起動時の初期値として新規に生成しようとするナンバー（以下、「起動時ナンバー」ともいう）の上位５桁（Ｄ１Ｄ２Ｄ３Ｄ４Ｄ５）を現在の累積日数の数値に、中位４桁（Ｓ１Ｓ２Ｓ３Ｓ４）を”００００”に、それぞれ設定する（ステップＳ１０３）。
【００２８】
一方、ステップＳ１０２にて最終記録ナンバーの上位５桁（Ｄ１Ｄ２Ｄ３Ｄ４Ｄ５）が現在の累積日数以上であると判断した場合、即ち最終記録ナンバーを記録した日と同一日内にリブートされ又はシステムデートが古い日付に誤設定されていると判断した場合には、システムイベントナンバー生成部２３は、起動時ナンバーの上位５桁（Ｄ１Ｄ２Ｄ３Ｄ４Ｄ５）を最終記録ナンバーの上位５桁（Ｄ１Ｄ２Ｄ３Ｄ４Ｄ５）と同じ値に、起動時ナンバーの中位４桁（Ｓ１Ｓ２Ｓ３Ｓ４）を最終記録ナンバーの中位４桁（Ｓ１Ｓ２Ｓ３Ｓ４）をインクリメントした値に、それぞれ設定する（ステップＳ１０４）。
【００２９】
次に、システムイベントナンバー生成部２３は、起動時ナンバーの下位９桁（Ｃ１Ｃ２Ｃ３Ｃ４Ｃ５Ｃ６Ｃ７Ｃ８Ｃ９）を”０００００００００”に設定する（ステップＳ１０５）。そして、システムイベントナンバー生成部２３は、起動時ナンバーを記録媒体２７に書き込む（ステップＳ１０６）。このようにシステムイベントナンバー生成部２３が起動時ナンバーを記録媒体２７に書き込むことにより、起動時ナンバーが新たな最終記録ナンバーとなる。なお、システムイベントナンバー生成部２３が、記録媒体２７ではなく、ＥＥＰＲＯＭ等にナンバーを記録するようにしても良い。
【００３０】
このように、最終記録ナンバーを記録した日と同一日内にリブートされ又はシステムデートが誤って古い日付に設定されている場合であっても、起動時ナンバーの中位４桁（Ｓ１Ｓ２Ｓ３Ｓ４）を最終記録ナンバーの中位４桁（Ｓ１Ｓ２Ｓ３Ｓ４）をインクリメントした値に設定することにより、最終記録ナンバーより大きな数値である起動時ナンバーを生成することができる。
【００３１】
次に、レコード作成部２４又はレコード更新部２６からナンバー生成要求を受けた場合のシステムイベントナンバー生成部２２の動作について説明する。図５は、システムイベントナンバー生成部２３のナンバー生成処理動作の概要を示すフローチャートである。以下、システムイベントナンバー生成部２３のナンバー生成処理動作について、図５を参照しながら説明する。
【００３２】
レコード作成部２４又はレコード更新部２６からナンバー生成要求を受けると、システムイベントナンバー生成部２３は、図５の処理を開始する。
まず、システムイベントナンバー生成部２３は、前回生成したナンバー（サーバ２１の起動後最初にナンバー生成要求を受けた場合には、起動時ナンバーが該当する。以下、「前回ナンバー」ともいう）の下位９桁（Ｃ１Ｃ２Ｃ３Ｃ４Ｃ５Ｃ６Ｃ７Ｃ８Ｃ９）が”９９９９９９９９９”であるか否か、即ち前回ナンバーの下位９桁（Ｃ１Ｃ２Ｃ３Ｃ４Ｃ５Ｃ６Ｃ７Ｃ８Ｃ９）をインクリメントするとキャリーが発生するか否かをチェックし、前回ナンバーの下位９桁（Ｃ１Ｃ２Ｃ３Ｃ４Ｃ５Ｃ６Ｃ７Ｃ８Ｃ９）が”９９９９９９９９９”であれば処理をステップＳ１１２に移し、そうでなければ処理をステップＳ１１５に移す（ステップＳ１１１）。
【００３３】
ステップＳ１１１にて前回ナンバーの下位９桁（Ｃ１Ｃ２Ｃ３Ｃ４Ｃ５Ｃ６Ｃ７Ｃ８Ｃ９）が”９９９９９９９９９”であると判断した場合、即ち前回ナンバーの下位９桁（Ｃ１Ｃ２Ｃ３Ｃ４Ｃ５Ｃ６Ｃ７Ｃ８Ｃ９）をインクリメントするとキャリーが発生すると判断した場合には、システムイベントナンバー生成部２３は、更に前回ナンバーの中位４桁（Ｓ１Ｓ２Ｓ３Ｓ４）が”９９９９”であるか否か、即ち前回ナンバーの下位９桁（Ｃ１Ｃ２Ｃ３Ｃ４Ｃ５Ｃ６Ｃ７Ｃ８Ｃ９）からのキャリーを加算すると前回ナンバーの中位４桁（Ｓ１Ｓ２Ｓ３Ｓ４）が桁あふれを発生するか否かをチェックする。そして、システムイベントナンバー生成部２３は、前回ナンバーの中位４桁（Ｓ１Ｓ２Ｓ３Ｓ４）が”９９９９”でなければ処理をステップＳ１１３に移し、前回ナンバーの中位４桁（Ｓ１Ｓ２Ｓ３Ｓ４）が”９９９９”であれば処理をステップＳ１１６に移す（ステップＳ１１２）。
【００３４】
ステップＳ１１２にて前回ナンバーの中位４桁（Ｓ１Ｓ２Ｓ３Ｓ４）が”９９９９”でないと判断した場合には、システムイベントナンバー生成部２３は、新規に生成しようとするナンバー（以下、「新規生成ナンバー」ともいう）の中位４桁（Ｓ１Ｓ２Ｓ３Ｓ４）を前回ナンバーの中位４桁（Ｓ１Ｓ２Ｓ３Ｓ４）をインクリメント（前回ナンバーの下位９桁（Ｃ１Ｃ２Ｃ３Ｃ４Ｃ５Ｃ６Ｃ７Ｃ８Ｃ９）からのキャリーの加算に相当）した値に、新規生成ナンバーの下位９桁（Ｃ１Ｃ２Ｃ３Ｃ４Ｃ５Ｃ６Ｃ７Ｃ８Ｃ９）を”０００００００００“に、それぞれ設定する（ステップＳ１１３）。更に、システムイベントナンバー生成部２３は、この時点における新規生成ナンバーを記録媒体２７に書き込む（ステップＳ１１４）。システムイベントナンバー生成部２３がこの時点における新規生成ナンバーを記録媒体２７に書き込むことにより、この時点における新規生成ナンバーが新たな最終記録ナンバーとなる。
【００３５】
ステップＳ１１１にて前回ナンバーの下位９桁（Ｃ１Ｃ２Ｃ３Ｃ４Ｃ５Ｃ６Ｃ７Ｃ８Ｃ９）が”９９９９９９９９９”ではないと判断した場合、又はステップＳ１１４の処理を終了した場合には、システムイベントナンバー生成部２３は、新規生成ナンバーの下位９桁（Ｃ１Ｃ２Ｃ３Ｃ４Ｃ５Ｃ６Ｃ７Ｃ８Ｃ９）をインクリメントし、この新規生成ナンバーをナンバー生成を要求したレコード作成部２４又はレコード更新部２６に出力する（ステップＳ１１５）。
【００３６】
一方、ステップＳ１１２にて前回ナンバーの中位４桁（Ｓ１Ｓ２Ｓ３Ｓ４）が”９９９９”であると判断した場合には、システムイベントナンバー生成部２３は、新規ナンバーの生成を停止し、処理を終了する（ステップＳ１１６）。この場合には、サーバ２１がオペレータに警告文を表示するようにしても良い。
なお、ステップＳ１１６の処理が実行される場合とは、システムイベントナンバー生成部２３が、ステップＳ１１１にて前回ナンバーの下位９桁（Ｃ１Ｃ２Ｃ３Ｃ４Ｃ５Ｃ６Ｃ７Ｃ８Ｃ９）が”９９９９９９９９９”であると判断し、且つステップＳ１１２にて前回ナンバーの中位４桁（Ｓ１Ｓ２Ｓ３Ｓ４）が”９９９９”であると判断した場合である。しかしながら、先に説明したように、同一日内に９，９９９，９９９，９９９，９９９回を超えるナンバー生成要求があることは、実用上殆どないものと考えられる。
【００３７】
以上説明したように、システムイベントナンバー生成部２３は、サーバ２１の同一日内のリブート及びシステムデートが古い日付に誤設定されている状態での起動（リブートを含む）をも考慮した上で、前回ナンバーより大きな数値であるという条件を必ず満たす新規ナンバーを生成することができる。また、システムイベントナンバー生成部２３は、ナンバーを生成する毎ではなく、新規生成ナンバーの中位４桁（Ｓ１Ｓ２Ｓ３Ｓ４）がインクリメントされた場合にのみ新規生成ナンバーを記録媒体２７に書き込むので、新規生成ナンバーの記録媒体２７への書き込みのオーバーヘッドを小さくすることができる。
【００３８】
次に、サーバ２１のレコード作成部２４の動作について説明する。図６は、レコード作成部２４のレコード作成動作の概要を示すフローチャートである。以下、レコード作成部２４のレコード作成動作について、図６を参照しながら説明する。
【００３９】
まず、クライアント端末１１〜１ｎが、新規なレコードのためのデータをサーバ２１に送信し、サーバ２１のレコード作成部２４が、データを受信する（ステップＳ２０１）。
次に、レコード作成部２４は、システムイベントナンバー生成部２３にナンバーの生成を要求する（ステップＳ２０２）。システムイベントナンバー生成部２３は、レコード作成部２４からナンバー生成要求を受けると、ナンバーを生成し、レコード作成部２４に送信する。
レコード作成部２４は、システムイベントナンバー生成部２３からナンバーを受信すると、クライアント端末１１〜１ｎから受信したデータ及びシステムイベントナンバー生成部２３から受信したナンバーを含むレコードを作成し、記録媒体２７内のデータベースに格納する（ステップＳ２０４）。
このように、ナンバーを含むレコードを作成し、データベースに格納することができる。
【００４０】
次に、サーバ２１のレコード読出し部２５の動作について説明する。図７は、レコード読出し部２５のレコード読み出し動作の概要を示すフローチャートである。以下、レコード読出し部２５のレコード読み出し動作について、図７を参照しながら説明する。
【００４１】
まず、クライアント端末１１〜１ｎが、所望のレコードを読み出すことをサーバ２１に要求し、サーバ２１のレコード読出し部２５が、レコードの読み出し要求を受信する（ステップＳ３０１）。
次に、レコード読出し部２５は、クライアント端末１１〜１ｎから要求されたレコードを記録媒体２７内のデータベースから検索し、読み出す（ステップＳ３０２）。
レコード読出し部２５は、読み出したレコードをクライアント端末１１〜１ｎに送信する（ステップＳ３０３）。なお、クライアント端末１１〜１ｎが、受信したレコード内のナンバーを表示しないようにすることができ、ユーザが、レコード内のナンバーを編集できないようにすることができる。
【００４２】
次に、サーバ２１のレコード更新部２６の動作について説明する。図８は、レコード更新部２６のレコード更新動作の概要を示すフローチャートである。以下、レコード更新部２６のレコード更新動作について、図７を参照しながら説明する。
【００４３】
まず、クライアント端末１１〜１ｎが、データを編集したレコードをサーバ２１に送信し、サーバ２１のレコード更新部２６が、データを編集したレコードを受信する（ステップＳ４０１）。
次に、レコード更新部２６は、クライアント端末１１〜１ｎから受信したレコード内のナンバーと記録媒体２７内のデータベースに格納されている更新対象レコード内のナンバーとを比較する。そして、レコード更新部２６は、クライアント端末１１〜１ｎから受信したレコード内のナンバーと記録媒体２７内のデータベースに格納されている更新対象レコード内のナンバーとが一致する場合には処理をステップＳ４０３に移し、一致しない場合には処理をステップＳ４０６に移す（ステップＳ４０２）。
【００４４】
ステップＳ４０２にてクライアント端末１１〜１ｎから受信したレコード内のナンバーとデータベースに格納されている更新対象レコード内のナンバーとが一致すると判断した場合には、レコード更新部２６は、システムイベントナンバー生成部２３にナンバーの生成を要求する（ステップＳ４０３）。システムイベントナンバー生成部２３は、レコード更新部２６からナンバー生成要求を受けると、ナンバーを生成し、レコード更新部２６に送信する。
【００４５】
次に、レコード更新部２６は、クライアント端末１１〜１ｎから受信したレコード内のナンバーをシステムイベントナンバー生成部２３から受信したナンバーで置き換える。そして、レコード更新部２６は、ナンバーを置き換えたレコードを記録媒体２７内のデータベースの更新対象レコードが格納されている箇所に格納することにより、データベース内の更新対象レコードを更新する（ステップＳ４０５）。
【００４６】
一方、ステップＳ４０２にてクライアント端末１１〜１ｎから受信したレコード内のナンバーとデータベースに格納されている更新対象レコード内のナンバーとが一致しないと判断した場合には、レコード更新部２６は、記録媒体２７内のデータベースに格納されている更新対象レコードの更新をせず、その旨を通知する警告文をクライアント端末１１〜１ｎに送信する（ステップＳ４０６）。
このように、レコード更新部２６が、クライアント端末１１〜１ｎから受信したレコード内のナンバーとデータベースに格納されている更新対象レコード内のナンバーとが一致する場合にのみ、更新対象レコード内のナンバーを新規生成ナンバーで置き換えて更新することができる。
【００４７】
次に、本実施形態に係るデータ処理方法を用いた実施例について説明する。本実施例は、本実施形態に係るデータ処理方法を社員データベース処理に適用したものである。なお、本実施例において、全てのデータベース操作は、起算日当日に行われるものとする。
本実施例において、サーバ２１の記録媒体２７には、社員に対する手当金を管理する社員データベースのスキーマが構築されている。この社員データベースは、社員名、手当金、及び、ナンバーの３つのカラムを有する。
【００４８】
まず、第１のユーザが社員データベース内にレコードを作成する場合のクライアント端末１１及びサーバ２１の動作について、図９のフローチャートを参照しながら説明する。なお、第１のユーザはクライアント端末１１を使用するものとする。
第１のユーザが、社員名及び手当金を含むデータ（４社員分）をクライアント端末１１に入力し、クライアント端末１１が、社員名及び手当金を含むデータ（４社員分）をサーバ２１に送信する（ステップＳ５０１）。
【００４９】
サーバ２１は、クライアント端末１１から社員名及び手当金を含むデータ（４社員分）を受信すると、４つのナンバーを生成し、それぞれのデータにナンバーを付加したレコード４１〜４４を作成し、社員データベースに格納する（ステップＳ６０１）。図１０（ａ）は、このようにして４つのレコードが格納された社員データベース４０を示す図である。図１０（ａ）に示すように、レコード４１には、“００００１００００００００００００１”という値のナンバーが含まれている。この値は、このナンバーが起算日当日に生成され、サーバ２１が起算日当日に一度もリブートされておらず、このナンバーが起算日当日に生成された最初のナンバーであることを示している。
【００５０】
次に、第２及び第３のユーザがこの社員データベース内のレコード４１を重複して更新しようとする場合のクライアント端末１２及び１３並びにサーバ２１の動作について、図１１のフローチャートを参照しながら説明する。なお、第２のユーザはクライアント端末１２を使用し、第３のユーザはクライアント端末１３を使用するものとする。
まず、第２のユーザが、レコード４１の読み出しを要求し、クライアント端末１２が、レコード４１の読み出し要求をサーバ２１に送信する（ステップＳ７１１）。
【００５１】
サーバ２１は、クライアント端末１２からレコード４１の読み出し要求を受信すると、社員データベース４０からレコード４１を読み出して、クライアント端末１２に送信する（ステップＳ６１１）。クライアント端末１２は、サーバ２１からレコード４１を受信し、表示する。
次に、第２のユーザが、表示されたレコード４１内の所望のデータを編集する（ステップＳ７１２）。ここでは、第２のユーザが、レコード４１内の手当金の金額を５０，０００円から５５，０００円に編集するものとする。図１０（ｂ）は、第２のユーザがレコード４１を編集した結果であるレコード４５を示す図である。
【００５２】
一方、この時、第３のユーザが、レコード４１の読み出しを要求し、クライアント端末１３が、レコード４１の読み出し要求をサーバ２１に送信する（ステップＳ８１１）。
サーバ２１は、クライアント端末１３からレコード４１の読み出し要求を受信すると、社員データベース４０からレコード４１を読み出して、クライアント端末１３に送信する（ステップＳ６１２）。クライアント端末１３は、サーバ２１からレコード４１を受信し、表示する。
次に、第３のユーザは、表示されたレコード４１内の所望のデータを編集する（ステップＳ８１２）。ここでは、第３のユーザが、レコード４１内の手当金の金額を５０，０００円から５７，０００円に編集するものとする。図１０（ｃ）は、第２のユーザがレコード４１を編集した結果であるレコード４６を示す図である。
【００５３】
他方、第２のユーザが、編集したレコード４５の送信を要求し、クライアント端末１２が、レコード４５をサーバ２１に送信する（ステップＳ７１３）。
サーバ２１は、クライアント端末１２からレコード４５を受信すると、レコード４５のナンバーと社員データベース４０に格納されているレコード４１のナンバーとが一致することを確認した後、新しいナンバーを生成する。本実施例では、新しいナンバーは、“００００１００００００００００００５”となる。そして、サーバ２１は、レコード４５のナンバーを新しいナンバーで置き換え、レコード４５を社員データベース４０に格納する（ステップＳ６１３）。図１０（ｄ）は、レコード４５を格納した後の社員データベース４０を示す図である。
【００５４】
一方、第３のユーザが、編集したレコード４６の送信を要求し、クライアント端末１３が、レコード４６をサーバ２１に送信する（ステップＳ８１３）。
サーバ２１は、クライアント端末１３からレコード４６を受信すると、レコード４６のナンバーと社員データベース４０に格納されているレコード４５のナンバーとを比較する。しかし、本実施例においては、レコード４５は既に第２のユーザによって更新されており、レコード４５のナンバーとレコード４６のナンバーは一致しない。そのため、サーバ２１は、レコード４６を社員データベースに格納せず、その旨を示す警告メッセージをクライアント端末１３に送信する（ステップＳ６１４）。
クライアント端末１３は、サーバ２１から受信した警告メッセージを表示する（ステップＳ８１４）。
【００５５】
このように、クライアント端末１２及び１３から受信したレコード内のナンバーと社員データベース４０に格納されているレコード内のナンバーを比較し、一致する場合にのみレコードを更新するので、同一のレコードに対する第２及び第３のユーザの重複した更新を防止することができる。
【００５６】
次に、本発明の第２の実施形態に係るデータ処理方法について説明する。
図１２は、本実施形態に係るデータ処理方法を実施するためのシステムを示す図である。
図１２に示すように、このシステム２は、クライアント端末１１〜１ｎと、サーバ５１とを備えている。
クライアント端末１１〜１ｎ及びサーバ５１は、ネットワーク３１によって相互に接続されている。
【００５７】
図１３は、サーバ５１を示す図である。図１３に示すように、サーバ５１は、システムデート管理部２２と、システムイベントナンバー生成部２３と、レコード作成部２４と、レコード読出し部２５と、レコード更新部２６と、記録媒体２７と、レコード処理部５２とを含んでいる。
レコード処理部５２は、記録媒体２７内のデータベースに格納されたレコードに対して所定の処理を行う。
【００５８】
次に、レコード処理部５２の動作について説明する。図１４は、レコード処理部５２のレコード処理動作の概要を示すフローチャートである。以下、レコード処理部５２のレコード読み出し動作について、図１４を参照しながら説明する。
【００５９】
まず、レコード処理部５２は、所定のデータを含むレコードを記録媒体２７内のデータベースから検索する（ステップＳ９０１）。
次に、レコード処理部５２は、ステップＳ９０１にて検索したレコード内のナンバーより小さいナンバーを含むレコードをデータベースから抽出する（ステップＳ９０２）。
そして、レコード処理部５２は、ステップＳ９０２にて抽出したレコードに対し所定の処理を行う（ステップＳ９０３）。
このように、レコード処理部５２は、所定のデータを含むレコード内のナンバーより小さいナンバーを含むレコードに対してのみ、所定の処理を行うことができる。
【００６０】
次に、本実施形態に係るデータ処理方法を用いた実施例について説明する。本実施例は、本実施形態に係るデータ処理方法を決算処理に適用したものである。なお、本実施例において、起算日は１９９９年４月１日であり、決算日は２０００年３月３１日であるものとする。
本実施例において、サーバ５１の記録媒体２７には、伝票データベースが構築されている。この伝票データベースは、入力日、計上日、伝票内容、及び、ナンバーの４つのカラムを有する。
図１５は、記録媒体２７内の伝票データベースを示す図である。図１５において、この伝票データベース６０には、レコード作成部２４又はレコード更新部２６によってレコード６１〜７１の１１のレコードが格納されている。
【００６１】
次に、サーバ５１のレコード処理部５２の動作について、図１６のフローチャートを参照しながら説明する。
サーバ５１のレコード処理部５２は、クライアント端末１１〜１ｎから決算開始指示を受信すると、図１６の処理を開始する。
まず、レコード処理部５２は、伝票締めを指示するレコードを伝票データベースから検索する（ステップＳ９１１）。本実施例においては、伝票締めを指示するレコードは、レコード７０である。
【００６２】
次に、レコード処理部５２は、ステップＳ９０１にて検索したレコード７０のナンバー（”００３６８００００００００００００２”）よりも小さいナンバーを含むレコードを抽出する（ステップＳ９１２）。本実施例においては、レコード７０のナンバーよりも小さいナンバーを含むレコードは、レコード６１〜６９である。
次に、レコード処理部５２は、ステップＳ９０２にて抽出したレコード６１〜６９の内で計上日が２０００年３月３１日以前であるレコード（本実施例においては、レコード６１〜６４、６６、及び、６８）を集計し、決算処理を行う（ステップＳ９１３）。
【００６３】
このように、ユーザが適切な時に伝票締めを指示するレコード７０を伝票データベースに格納することにより、レコード処理部５２によって決算処理される対象となるレコード６１〜６４、６６、及び、６８を特定することができ、レコード７０の格納後に伝票データベースに格納されたレコード７１を決算処理の対象から外すことができる。従って、決算処理が終了するまで伝票データを含むレコード（本実施例においては、レコード７１）の入力を禁止したり、記録媒体２７内の仮の記録領域に伝票データを仮入力し決算処理終了後に伝票データベース６０に格納し直す必要がない。
なお、伝票締めを指示するレコード７０を伝票データベース６０に格納した後に、何らかの事情によりレコード７１をも決算対象とする必要が生じた場合には、レコード７０を削除し、伝票締めを指示する新たなレコードをレコード７１の次に作成すれば良い。
【００６４】
以上説明した各実施形態及び各実施例において、サーバ２１の他にサブサーバを設置してサーバを多重化することにより、ナンバーの生成をより確実にすることができる。
【００６５】
【発明の効果】
以上述べた様に、本発明の第１の観点によれば、データが編集されたレコード内のナンバーと更新対象レコード内のナンバーとが一致する場合にのみレコードを更新するので、同一レコードに対する複数ユーザの重複読み出しを可能にしつつ、重複更新を防止することができる。また、本発明の第２の観点によれば、複数の装置の内のいずれかの装置によって指示されたデータを含むレコード内のナンバーより小さいナンバーを含むレコードにのみ集計処理を行うので、データの入力とデータに対する処理とを並行して行うことができる。
【図面の簡単な説明】
【図１】本発明の第１の実施形態に係るデータ処理方法を実施するためのシステムを示す図である。
【図２】図１のサーバの構成を示す図である。
【図３】システムイベントナンバーのフォーマットを示す図である。
【図４】本発明の第１の実施形態に係るデータ処理方法の起動処理を示すフローチャートである。
【図５】本発明の第１の実施形態に係るデータ処理方法のシステムイベントナンバー生成処理を示すフローチャートである。
【図６】本発明の第１の実施形態に係るデータ処理方法のレコード作成処理を示すフローチャートである。
【図７】本発明の第１の実施形態に係るデータ処理方法のレコード読出処理を示すフローチャートである。
【図８】本発明の第１の実施形態に係るデータ処理方法のレコード更新処理を示すフローチャートである。
【図９】本発明の第１の実施形態の実施例に係るデータ処理方法のレコード作成処理を示すフローチャートである。
【図１０】本発明の第１の実施形態の実施例に係るデータ処理方法によって処理される社員データベースを示す図である。
【図１１】本発明の第１の実施形態の実施例に係るデータ処理方法のレコード更新処理を示すフローチャートである。
【図１２】本発明の第２の実施形態に係るデータ処理方法を実施するためのシステムを示す図である。
【図１３】図１２のサーバの構成を示す図である。
【図１４】本発明の第２の実施形態に係るデータ処理方法のレコード処理を示すフローチャートである。
【図１５】本発明の第２の実施形態の実施例に係るデータ処理方法によって処理される伝票データベースを示す図である。
【図１６】本発明の第２の実施形態の実施例に係るデータ処理方法の決算処理を示すフローチャートである。
【符号の説明】
１、２ データ処理システム
１１〜１ｎ クライアント端末
２１、５１ サーバ
２２ システムデート管理部
２３ システムイベントナンバー生成部
２４ レコード作成部
２５ レコード読出し部
２６ レコード更新部
２７ 記録媒体
３１ ネットワーク
４０ 社員データベース
４１〜４６ レコード
５２ レコード処理部
６０ 伝票データベース
６１〜７１ レコード
【発明の属する技術分野】
本発明は、データを処理するためのデータ処理方法に関し、さらに、そのようなデータ処理方法を用いるデータ処理サーバ、及び、データ処理プログラムを記録した記録媒体に関する。
【０００２】
【従来の技術】
従来より、種々のデータをレコードとして格納し、レコードに対して各種の操作等を行うデータベースシステムが用いられている。
このようなデータベースシステムに格納されたあるレコードに対して、複数のユーザが重複して更新する場合がある。例えば、あるレコードに対して、第１のユーザが読み出し操作を行い、第２のユーザが読み出し操作を行い、第１のユーザが更新操作を行い、第２のユーザが更新操作を行う場合である。この場合には、第１のユーザの更新操作の結果が、第２のユーザの更新操作の結果によって上書きされ、失われてしまうこととなる。
【０００３】
このような同一レコードに対する複数のユーザの重複更新を防止するため、従来のデータベースシステムにおいて、レコードロック、ページロック、テーブルロック、データベースロック等を含むロック法等の排他制御が行われていた。
しかしながら、従来のロック法は、多くの計算時間（処理時間）を必要とする。また、あるレコードがレコードロックされている場合に、所定の条件（例えば、更新ページが所定数を超える等）を満たすことによりレコードロックからテーブルロック等に移行し（ロックエスカレーション）、ひいては他のデータベース操作との間でデッドロックを招く場合があった。更に、あるユーザの操作によってロックされているレコードに対し、他のユーザが更新操作のみならず読み出し操作をも行うことができない場合があった。
【０００４】
一方、上記のようなデータベースシステムが、企業等の会計業務に用いられている。このようにデータベースシステムが会計業務に用いられている場合に、企業等の第ｋ期会計期間から第（ｋ＋１）期会計期間への移行時から所定の期間（一般に、会計期間の移行時から数日〜十数日程度）において、多数の伝票データ（第ｋ期会計期間の伝票データと第（ｋ＋１）期会計期間の伝票データとの双方を含む）の入力、決算処理等が集中し、円滑な会計業務を遂行できない場合があった。
【０００５】
そのため、従来のデータベースシステムを用いた会計業務では、会計期間の移行時から所定の期間内における伝票データの入力を一切禁止し、第ｋ期会計期間の決算処理が終了した後に伝票データの入力を再開するか、又は会計期間の移行時から所定の期間内に入力された伝票データを仮の記録領域に記録しておき、第ｋ期会計期間の決算処理が終了した後に仮の記録領域に記録されていた伝票データを会計業務用の記録領域に転送していた。
【０００６】
【発明が解決しようとする課題】
そこで、上記の点に鑑み、本発明は、同一レコードに対する複数ユーザの重複読み出しを可能にしつつ、重複更新を防止することができるデータ処理サーバ及びデータ処理方法、並びにデータ処理プログラムを記録した記録媒体を提供することを目的とする。また、本発明は、データの入力とデータに対する処理を並行して行うことができるデータ処理サーバ及びデータ処理方法、並びにデータ処理プログラムを記録した記録媒体を提供することを更なる目的とする。
【０００７】
【課題を解決するための手段】
以上の課題を解決するため、本発明の第１の観点に係るデータ処理サーバは、複数の装置と通信することによりデータを処理するサーバであって、複数のレコードを記録する記録手段と、所定の起算日から現在までの累積日数を計数してその値を出力する累積日数計数手段と、第ｎ番目のナンバー生成要求に応じて、ｘ（ｉ）＜ｘ（ｎ）（ｉ＝１、・・・、（ｎ−１））を満たすナンバーｘ（ｎ）であって、累積日数計数手段が出力した値を上位桁とし、その日に起動又はリブートされた回数の値を中位桁とし、その日にナンバー生成を要求された回数の値を下位桁とするナンバーを生成するナンバー生成手段と、複数の装置の内のいずれかの装置からデータを受信した場合に、ナンバー生成手段にナンバー生成要求を行い、受信したデータ及びナンバー生成手段から出力されたナンバーを含むレコードを記録手段に書き込むレコード作成手段と、複数の装置の内のいずれかの装置から記録手段に記録されたレコードを読み出す旨の要求を受信した場合に、要求されたレコードを記録手段から読み出して装置に出力するレコード読出し手段と、複数の装置の内のいずれかの装置からデータが編集されたレコードを受信した場合に、受信したレコード内のナンバーと記録手段に記録されている更新対象のレコード内のナンバーとが一致するか否かをチェックし、受信したレコード内のナンバーと記録手段に記録されている更新対象のレコード内のナンバーとが一致する場合に、ナンバー生成手段にナンバー生成要求を行い、受信したレコード内のナンバーをナンバー生成手段から出力されたナンバーで置き換えたレコードを記録手段に書き込むレコード更新手段とを具備する。
【０００８】
また、本発明の第２の観点に係るデータ処理サーバは、複数の装置と通信することによりデータを処理するサーバであって、複数のレコードを記録する記録手段と、所定の起算日から現在までの累積日数を計数してその値を出力する累積日数計数手段と、第ｎ番目のナンバー生成要求に応じて、ｘ（ｉ）＜ｘ（ｎ）（ｉ＝１、・・・、（ｎ−１））を満たすナンバーｘ（ｎ）であって、累積日数計数手段が出力した値を上位桁とし、その日に起動又はリブートされた回数の値を中位桁とし、その日にナンバー生成を要求された回数の値を下位桁とするナンバーを生成して出力するナンバー生成手段と、複数の装置の内のいずれかの装置からデータを受信した場合に、ナンバー生成手段にナンバー生成要求を行い、受信したデータ及びナンバー生成手段から出力されたナンバーを含むレコードを記録手段に書き込むレコード作成手段と、記録手段に記録されているレコードの内で複数の装置の内のいずれかの装置によって指示されたデータを含むレコード内のナンバーより小さいナンバーを有するレコードに対して集計処理を行うレコード処理手段とを具備する。
【０００９】
また、本発明の第１の観点に係るデータ処理方法は、複数の装置と通信することによりデータを処理する方法であって、所定の起算日から現在までの累積日数を計数してその値を出力するステップ（ａ）と、ナンバー生成手段において、第ｎ番目のナンバー生成要求に応じて、ｘ（ｉ）＜ｘ（ｎ）（ｉ＝１、・・・、（ｎ−１））を満たすナンバーｘ（ｎ）であって、ステップ（ａ）が出力した値を上位桁とし、その日に起動又はリブートされた回数の値を中位桁とし、その日にナンバー生成を要求された回数の値を下位桁とするナンバーを生成するステップ（ｂ）と、複数の装置の内のいずれかの装置からデータを受信した場合に、ナンバー生成手段にナンバー生成要求を行い、受信したデータ及びナンバー生成手段から出力されたナンバーを含むレコードを記録媒体に記録するステップ（ｃ）と、複数の装置の内のいずれかの装置からレコードを読み出す旨の要求を受信した場合に、要求されたレコードを記録媒体から読み出して装置に出力するステップ（ｄ）と、複数の装置の内のいずれかの装置からデータが編集されたレコードを受信した場合に、受信したレコード内のナンバーと記録媒体に記録されている更新対象のレコード内のナンバーとが一致するか否かをチェックし、受信したレコード内のナンバーと記録媒体に記録されている更新対象のレコード内のナンバーとが一致する場合に、ナンバー生成手段にナンバー生成要求を行い、受信したレコード内のナンバーをナンバー生成手段から出力されたナンバーで置き換えたレコードを記録媒体に書き込むステップ（ｅ）とを具備する。
【００１０】
また、本発明の第２の観点に係るデータ処理方法は、複数の装置と通信することによりデータを処理する方法であって、所定の起算日から現在までの累積日数を計数してその値を出力するステップ（ａ）と、ナンバー生成手段において、第ｎ番目のナンバー生成要求に応じて、ｘ（ｉ）＜ｘ（ｎ）（ｉ＝１、・・・、（ｎ−１））を満たすナンバーｘ（ｎ）であって、ステップ（ａ）が出力した値を上位桁とし、その日に起動又はリブートされた回数の値を中位桁とし、その日にナンバー生成を要求された回数の値を下位桁とするナンバーを生成するステップ（ｂ）と、複数の装置の内のいずれかの装置からデータを受信した場合に、ナンバー生成手段にナンバー生成要求を行い、受信したデータ及びナンバー生成手段から出力されたナンバーを含むレコードを記録媒体に書き込むステップ（ｃ）と、記録媒体に記録されているレコードの内で複数の装置の内のいずれかの装置によって指示されたデータを含むレコード内のナンバーより小さいナンバーを有するレコードに対して集計処理を行うステップ（ｄ）とを具備する。
【００１１】
また、本発明の第１の観点に係るデータ処理プログラムを記録した記録媒体は、複数の装置と通信することによりデータを処理するためにＣＰＵで読み取り可能な記録媒体であって、所定の起算日から現在までの累積日数を計数してその値を出力する手順（ａ）と、ナンバー生成手段において、第ｎ番目のナンバー生成要求に応じて、ｘ（ｉ）＜ｘ（ｎ）（ｉ＝１、・・・、（ｎ−１））を満たすナンバーｘ（ｎ）であって、手順（ａ）が出力した値を上位桁とし、その日に起動又はリブートされた回数の値を中位桁とし、その日にナンバー生成を要求された回数の値を下位桁とするナンバーを生成する手順（ｂ）と、複数の装置の内のいずれかの装置からデータを受信した場合に、ナンバー生成手段にナンバー生成要求を行い、受信したデータ及びナンバー生成手段から出力されたナンバーを含むレコードを記録媒体に記録する手順（ｃ）と、複数の装置の内のいずれかの装置からレコードを読み出す旨の要求を受信した場合に、要求されたレコードを記録媒体から読み出して装置に出力する手順（ｄ）と、複数の装置の内のいずれかの装置からデータが編集されたレコードを受信した場合に、受信したレコード内のナンバーと記録媒体に記録されている更新対象のレコード内のナンバーとが一致するか否かをチェックし、受信したレコード内のナンバーと記録媒体に記録されている更新対象のレコード内のナンバーとが一致する場合に、ナンバー生成手段にナンバー生成要求を行い、受信したレコード内のナンバーをナンバー生成手段から出力されたナンバーで置き換えたレコードを記録媒体に書き込む手順（ｅ）とをＣＰＵに実行させる。
【００１２】
また、本発明の第２の観点に係るデータ処理プログラムを記録した記録媒体は、複数の装置と通信することによりデータを処理するためにＣＰＵで読み取り可能な記録媒体であって、所定の起算日から現在までの累積日数を計数してその値を出力する手順（ａ）と、ナンバー生成手段において、第ｎ番目のナンバー生成要求に応じて、ｘ（ｉ）＜ｘ（ｎ）（ｉ＝１、・・・、（ｎ−１））を満たすナンバーｘ（ｎ）であって、手順（ａ）が出力した値を上位桁とし、その日に起動又はリブートされた回数の値を中位桁とし、その日にナンバー生成を要求された回数の値を下位桁とするナンバーを生成する手順（ｂ）と、複数の装置の内のいずれかの装置からデータを受信した場合に、ナンバー生成手段にナンバー生成要求を行い、受信したデータ及びナンバー生成手段から出力されたナンバーを含むレコードを記録媒体に書き込む手順（ｃ）と、記録媒体に記録されているレコードの内で複数の装置の内のいずれかの装置によって指示されたデータを含むレコード内のナンバーより小さいナンバーを有するレコードに対して集計処理を行う手順（ｄ）とをＣＰＵに実行させる。
【００１３】
本発明の第１の観点によれば、データが編集されたレコード内のナンバーと更新対象レコード内のナンバーとが一致する場合にのみレコードを更新するので、同一レコードに対する複数ユーザの重複読み出しを可能にしつつ、重複更新を防止することができる。また、本発明の第２の観点によれば、複数の装置の内のいずれかの装置によって指示されたデータを含むレコード内のナンバーより小さいナンバーを含むレコードにのみ集計処理を行うので、データの入力とデータに対する処理とを並行して行うことができる。
【００１４】
【発明の実施の形態】
以下、図面に基づいて本発明の実施の形態について説明する。なお、同一の構成要素には同一の参照番号を付して説明を省略する。
まず、本発明の第１の実施形態に係るデータ処理方法について説明する。図１は、本発明の第１の実施形態に係るデータ処理方法を実施するためのシステムを示す図である。
図１に示すように、このシステム１は、クライアント端末１１〜１ｎと、サーバ２１とを備えている。
クライアント端末１１〜１ｎ及びサーバ２１は、ＬＡＮ、公衆回線網、インターネット等のネットワーク３１によって相互に接続されている。
クライアント端末１１〜１ｎは、ユーザがサーバ２１を利用するためのＰＣ等である。
【００１５】
図２は、サーバ２１を示す図である。図２に示すように、サーバ２１は、システムデート管理部２２と、システムイベントナンバー生成部２３と、レコード作成部２４と、レコード読出し部２５と、レコード更新部２６と、記録媒体２７とを含んでいる。
システムデート管理部２２は、サーバ２１のシステムデートの管理を行い、所定の起算日を”００００１”とした場合のシステムデートまでの日数（以下、「累積日数」ともいう）をカウントし、その数値を出力する。例えば、１９９９年１月１日が起算日であり、システムデートが２００１年１月１日である場合には、累積日数は７３１日となり、システムデート管理部２２は”００７３１”を出力する。
【００１６】
システムイベントナンバー生成部２３は、レコード作成部２４及びレコード更新部２６からの要求に応じて、１８桁の数であるＳＥＮ（システムイベントナンバー、以下においては単に「ナンバー」ともいう）を生成して出力する。また、システムイベントナンバー生成部２３は、生成したナンバーを所定時に記録媒体２７に書き込む。
ここで、ナンバーについて詳しく説明する。図３は、ナンバーのフォーマットを示す図である。図３に示すように、ナンバーは、上位５桁（Ｄ１Ｄ２Ｄ３Ｄ４Ｄ５）、中位４桁（Ｓ１Ｓ２Ｓ３Ｓ４）、及び、下位９桁（Ｃ１Ｃ２Ｃ３Ｃ４Ｃ５Ｃ６Ｃ７Ｃ８Ｃ９）を結合した数である。
【００１７】
ナンバーの上位５桁（Ｄ１Ｄ２Ｄ３Ｄ４Ｄ５）は、このナンバーが生成された日の累積日数を示す数値である。従って、システムイベントナンバー生成部２３は、起算日から９９，９９９日目まで、即ち起算日から約２７０年後まで、ナンバーを生成することができる。
【００１８】
ナンバーの下位９桁（Ｃ１Ｃ２Ｃ３Ｃ４Ｃ５Ｃ６Ｃ７Ｃ８Ｃ９）は、ナンバー生成要求毎にインクリメントされた数である。なお、ナンバーの下位９桁（Ｃ１Ｃ２Ｃ３Ｃ４Ｃ５Ｃ６Ｃ７Ｃ８Ｃ９）からキャリーが発生した場合には、そのキャリーがナンバーの中位４桁（Ｓ１Ｓ２Ｓ３Ｓ４）に伝搬される。
【００１９】
ナンバーの中位４桁（Ｓ１Ｓ２Ｓ３Ｓ４）は、原則として、サーバ２１が同一日内でリブート（停電、故障等によりサーバ２１が停止し、その後再起動した場合等を含む）された回数とナンバーの下位９桁（Ｃ１Ｃ２Ｃ３Ｃ４Ｃ５Ｃ６Ｃ７Ｃ８Ｃ９）からのキャリーとの和である。但し、後にナンバー生成処理の説明において述べるように、ナンバーの中位４桁（Ｓ１Ｓ２Ｓ３Ｓ４）は、システムデート管理部２２によって管理されているシステムデートが正しい日付よりも古い日付に誤設定されている状態でサーバ２１が起動又はリブートされた場合には、インクリメントされる。従って、システムイベントナンバー生成部２３は、サーバ２１が同一日内でリブートされた回数と、システムデートが古い日付に誤設定されている状態でサーバ２１が起動又はリブートされた回数と、下位９桁（Ｃ１Ｃ２Ｃ３Ｃ４Ｃ５Ｃ６Ｃ７Ｃ８Ｃ９）からのキャリーとの合計が９，９９９となるまで、ナンバーを生成することができる。
【００２０】
なお、システムイベントナンバー生成部２３は、サーバ２１が同一日内に一度もリブートされていない場合には、中位４桁（Ｓ１Ｓ２Ｓ３Ｓ４）と下位９桁（Ｃ１Ｃ２Ｃ３Ｃ４Ｃ５Ｃ６Ｃ７Ｃ８Ｃ９）を合わせて、同一日内に９，９９９，９９９，９９９，９９９回までナンバーを生成できることとなる。
一方、動作周波数が６００ＭＨｚのＣＰＵとソフトウェアとを用いてナンバーを生成するために必要な時間を実測したところ、１０，０００回のナンバー生成処理に０．７秒の時間が必要であった。すなわち、ナンバー生成１回当たり０．００００７秒の時間が必要であった。
【００２１】
従って、９，９９９，９９９，９９９，９９９回のナンバー生成処理には、０．００００７（秒／回）に９，９９９，９９９，９９９，９９９（回）を乗じた約７億秒（約８１００日）が必要となる。更に、ナンバーの生成とともに各種のデータベース操作処理を行うことをも考慮すると、ナンバーは実用上十分な桁数を有することとなる。また、上記したように、サーバ２１が同一日内にリブートされ又はシステムデートが古い日付に誤設定されている状態でリブートされた場合には、ナンバーの中位４桁（Ｓ１Ｓ２Ｓ３Ｓ４）がインクリメントされるため、同一日内にナンバーを生成することができる回数が１，０００，０００，０００回ずつ減って行くことになる。しかし、このような事態を考慮しても、ナンバーは実用上十分な桁数を有すると考えられる。
【００２２】
レコード作成部２４は、クライアント端末１１〜１ｎからデータを受信し、受信したデータ及びナンバーを含むレコードを新規レコードとして記録媒体２７内のデータベースに書き込む。
レコード読出し部２５は、クライアント端末１１〜１ｎからの要求に応じて、記録媒体２７内のデータベースからレコードを読み出して出力する。
レコード更新部２６は、クライアント端末１１〜１ｎからレコードを受信し、受信したレコード内のナンバーと記録媒体２７内の更新対象レコード内のナンバーとが一致する場合に、受信したレコードによって記録媒体２７内のデータベースに格納されている更新対象レコードを更新（上書き）する。
【００２３】
記録媒体２７は、データベース、システムイベントナンバー生成部２３によって生成されたナンバー等を記録する。記録媒体２７としては、ハードディスク、フロッピーディスク、ＭＯ、ＭＴ、ＲＡＭ、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ等が該当する。
なお、図２に示すシステムデート管理部２２、システムイベントナンバー生成部２３、レコード作成部２４、レコード読出し部２５、及び、レコード更新部２６は、ＣＰＵとソフトウェア（プログラム）で構成することができる。このプログラムと、各種データベース及びアプリケーションデータファイルの各々は、ハードディスク、フロッピーディスク、ＭＯ、ＭＴ、ＲＡＭ、ＣＤ−ＲＯＭ、又は、ＤＶＤ−ＲＯＭ等の記録媒体に記録することができる。
【００２４】
次に、サーバ２１の動作について説明する。
まず、レコード作成部２４、レコード読出し部２５、及び、レコード更新部２６によるレコード操作の説明に先だって、システムイベントナンバー生成部２３の動作について説明する。
図４は、システムイベントナンバー生成部２３の起動処理動作の概要を示すフローチャートである。以下、システムイベントナンバー生成部２３の起動処理動作について、図４を参照しながら説明する。
【００２５】
サーバ２１が起動又はリブートされると、システムイベントナンバー生成部２３は、図４の処理を開始する。
図４の処理を開始すると、システムイベントナンバー生成部２３は、記録媒体２７に記録されているナンバーを読み出す（ステップＳ１０１）。
【００２６】
次に、システムイベントナンバー生成部２３は、ステップＳ１０１にて読み出したナンバー（以下、「最終記録ナンバー」ともいう）の上位５桁（Ｄ１Ｄ２Ｄ３Ｄ４Ｄ５）がシステムデート管理部２２によって管理されている現在の累積日数の数値以上であるか否か、即ち最終記録ナンバーを記録した日と同一日内にリブートされ又はシステムデート管理部２２によって管理されているシステムデートが古い日付に誤設定されているか否かをチェックする。そして、システムイベントナンバー生成部２３は、最終記録ナンバーの上位５桁（Ｄ１Ｄ２Ｄ３Ｄ４Ｄ５）が現在の累積日数より小さければ処理をステップＳ１０３に移し、最終記録ナンバーの上位５桁（Ｄ１Ｄ２Ｄ３Ｄ４Ｄ５）が現在の累積日数以上であれば処理をステップＳ１０４に移す（ステップＳ１０２）。
【００２７】
ステップＳ１０２にて最終記録ナンバーの上位５桁（Ｄ１Ｄ２Ｄ３Ｄ４Ｄ５）が現在の累積日数より小さいと判断した場合、即ち最終記録ナンバーを記録した日と同一日内にリブートされておらず且つシステムデートが誤設定されていないと判断した場合には、システムイベントナンバー生成部２３は、起動時の初期値として新規に生成しようとするナンバー（以下、「起動時ナンバー」ともいう）の上位５桁（Ｄ１Ｄ２Ｄ３Ｄ４Ｄ５）を現在の累積日数の数値に、中位４桁（Ｓ１Ｓ２Ｓ３Ｓ４）を”００００”に、それぞれ設定する（ステップＳ１０３）。
【００２８】
一方、ステップＳ１０２にて最終記録ナンバーの上位５桁（Ｄ１Ｄ２Ｄ３Ｄ４Ｄ５）が現在の累積日数以上であると判断した場合、即ち最終記録ナンバーを記録した日と同一日内にリブートされ又はシステムデートが古い日付に誤設定されていると判断した場合には、システムイベントナンバー生成部２３は、起動時ナンバーの上位５桁（Ｄ１Ｄ２Ｄ３Ｄ４Ｄ５）を最終記録ナンバーの上位５桁（Ｄ１Ｄ２Ｄ３Ｄ４Ｄ５）と同じ値に、起動時ナンバーの中位４桁（Ｓ１Ｓ２Ｓ３Ｓ４）を最終記録ナンバーの中位４桁（Ｓ１Ｓ２Ｓ３Ｓ４）をインクリメントした値に、それぞれ設定する（ステップＳ１０４）。
【００２９】
次に、システムイベントナンバー生成部２３は、起動時ナンバーの下位９桁（Ｃ１Ｃ２Ｃ３Ｃ４Ｃ５Ｃ６Ｃ７Ｃ８Ｃ９）を”０００００００００”に設定する（ステップＳ１０５）。そして、システムイベントナンバー生成部２３は、起動時ナンバーを記録媒体２７に書き込む（ステップＳ１０６）。このようにシステムイベントナンバー生成部２３が起動時ナンバーを記録媒体２７に書き込むことにより、起動時ナンバーが新たな最終記録ナンバーとなる。なお、システムイベントナンバー生成部２３が、記録媒体２７ではなく、ＥＥＰＲＯＭ等にナンバーを記録するようにしても良い。
【００３０】
このように、最終記録ナンバーを記録した日と同一日内にリブートされ又はシステムデートが誤って古い日付に設定されている場合であっても、起動時ナンバーの中位４桁（Ｓ１Ｓ２Ｓ３Ｓ４）を最終記録ナンバーの中位４桁（Ｓ１Ｓ２Ｓ３Ｓ４）をインクリメントした値に設定することにより、最終記録ナンバーより大きな数値である起動時ナンバーを生成することができる。
【００３１】
次に、レコード作成部２４又はレコード更新部２６からナンバー生成要求を受けた場合のシステムイベントナンバー生成部２２の動作について説明する。図５は、システムイベントナンバー生成部２３のナンバー生成処理動作の概要を示すフローチャートである。以下、システムイベントナンバー生成部２３のナンバー生成処理動作について、図５を参照しながら説明する。
【００３２】
レコード作成部２４又はレコード更新部２６からナンバー生成要求を受けると、システムイベントナンバー生成部２３は、図５の処理を開始する。
まず、システムイベントナンバー生成部２３は、前回生成したナンバー（サーバ２１の起動後最初にナンバー生成要求を受けた場合には、起動時ナンバーが該当する。以下、「前回ナンバー」ともいう）の下位９桁（Ｃ１Ｃ２Ｃ３Ｃ４Ｃ５Ｃ６Ｃ７Ｃ８Ｃ９）が”９９９９９９９９９”であるか否か、即ち前回ナンバーの下位９桁（Ｃ１Ｃ２Ｃ３Ｃ４Ｃ５Ｃ６Ｃ７Ｃ８Ｃ９）をインクリメントするとキャリーが発生するか否かをチェックし、前回ナンバーの下位９桁（Ｃ１Ｃ２Ｃ３Ｃ４Ｃ５Ｃ６Ｃ７Ｃ８Ｃ９）が”９９９９９９９９９”であれば処理をステップＳ１１２に移し、そうでなければ処理をステップＳ１１５に移す（ステップＳ１１１）。
【００３３】
ステップＳ１１１にて前回ナンバーの下位９桁（Ｃ１Ｃ２Ｃ３Ｃ４Ｃ５Ｃ６Ｃ７Ｃ８Ｃ９）が”９９９９９９９９９”であると判断した場合、即ち前回ナンバーの下位９桁（Ｃ１Ｃ２Ｃ３Ｃ４Ｃ５Ｃ６Ｃ７Ｃ８Ｃ９）をインクリメントするとキャリーが発生すると判断した場合には、システムイベントナンバー生成部２３は、更に前回ナンバーの中位４桁（Ｓ１Ｓ２Ｓ３Ｓ４）が”９９９９”であるか否か、即ち前回ナンバーの下位９桁（Ｃ１Ｃ２Ｃ３Ｃ４Ｃ５Ｃ６Ｃ７Ｃ８Ｃ９）からのキャリーを加算すると前回ナンバーの中位４桁（Ｓ１Ｓ２Ｓ３Ｓ４）が桁あふれを発生するか否かをチェックする。そして、システムイベントナンバー生成部２３は、前回ナンバーの中位４桁（Ｓ１Ｓ２Ｓ３Ｓ４）が”９９９９”でなければ処理をステップＳ１１３に移し、前回ナンバーの中位４桁（Ｓ１Ｓ２Ｓ３Ｓ４）が”９９９９”であれば処理をステップＳ１１６に移す（ステップＳ１１２）。
【００３４】
ステップＳ１１２にて前回ナンバーの中位４桁（Ｓ１Ｓ２Ｓ３Ｓ４）が”９９９９”でないと判断した場合には、システムイベントナンバー生成部２３は、新規に生成しようとするナンバー（以下、「新規生成ナンバー」ともいう）の中位４桁（Ｓ１Ｓ２Ｓ３Ｓ４）を前回ナンバーの中位４桁（Ｓ１Ｓ２Ｓ３Ｓ４）をインクリメント（前回ナンバーの下位９桁（Ｃ１Ｃ２Ｃ３Ｃ４Ｃ５Ｃ６Ｃ７Ｃ８Ｃ９）からのキャリーの加算に相当）した値に、新規生成ナンバーの下位９桁（Ｃ１Ｃ２Ｃ３Ｃ４Ｃ５Ｃ６Ｃ７Ｃ８Ｃ９）を”０００００００００“に、それぞれ設定する（ステップＳ１１３）。更に、システムイベントナンバー生成部２３は、この時点における新規生成ナンバーを記録媒体２７に書き込む（ステップＳ１１４）。システムイベントナンバー生成部２３がこの時点における新規生成ナンバーを記録媒体２７に書き込むことにより、この時点における新規生成ナンバーが新たな最終記録ナンバーとなる。
【００３５】
ステップＳ１１１にて前回ナンバーの下位９桁（Ｃ１Ｃ２Ｃ３Ｃ４Ｃ５Ｃ６Ｃ７Ｃ８Ｃ９）が”９９９９９９９９９”ではないと判断した場合、又はステップＳ１１４の処理を終了した場合には、システムイベントナンバー生成部２３は、新規生成ナンバーの下位９桁（Ｃ１Ｃ２Ｃ３Ｃ４Ｃ５Ｃ６Ｃ７Ｃ８Ｃ９）をインクリメントし、この新規生成ナンバーをナンバー生成を要求したレコード作成部２４又はレコード更新部２６に出力する（ステップＳ１１５）。
【００３６】
一方、ステップＳ１１２にて前回ナンバーの中位４桁（Ｓ１Ｓ２Ｓ３Ｓ４）が”９９９９”であると判断した場合には、システムイベントナンバー生成部２３は、新規ナンバーの生成を停止し、処理を終了する（ステップＳ１１６）。この場合には、サーバ２１がオペレータに警告文を表示するようにしても良い。
なお、ステップＳ１１６の処理が実行される場合とは、システムイベントナンバー生成部２３が、ステップＳ１１１にて前回ナンバーの下位９桁（Ｃ１Ｃ２Ｃ３Ｃ４Ｃ５Ｃ６Ｃ７Ｃ８Ｃ９）が”９９９９９９９９９”であると判断し、且つステップＳ１１２にて前回ナンバーの中位４桁（Ｓ１Ｓ２Ｓ３Ｓ４）が”９９９９”であると判断した場合である。しかしながら、先に説明したように、同一日内に９，９９９，９９９，９９９，９９９回を超えるナンバー生成要求があることは、実用上殆どないものと考えられる。
【００３７】
以上説明したように、システムイベントナンバー生成部２３は、サーバ２１の同一日内のリブート及びシステムデートが古い日付に誤設定されている状態での起動（リブートを含む）をも考慮した上で、前回ナンバーより大きな数値であるという条件を必ず満たす新規ナンバーを生成することができる。また、システムイベントナンバー生成部２３は、ナンバーを生成する毎ではなく、新規生成ナンバーの中位４桁（Ｓ１Ｓ２Ｓ３Ｓ４）がインクリメントされた場合にのみ新規生成ナンバーを記録媒体２７に書き込むので、新規生成ナンバーの記録媒体２７への書き込みのオーバーヘッドを小さくすることができる。
【００３８】
次に、サーバ２１のレコード作成部２４の動作について説明する。図６は、レコード作成部２４のレコード作成動作の概要を示すフローチャートである。以下、レコード作成部２４のレコード作成動作について、図６を参照しながら説明する。
【００３９】
まず、クライアント端末１１〜１ｎが、新規なレコードのためのデータをサーバ２１に送信し、サーバ２１のレコード作成部２４が、データを受信する（ステップＳ２０１）。
次に、レコード作成部２４は、システムイベントナンバー生成部２３にナンバーの生成を要求する（ステップＳ２０２）。システムイベントナンバー生成部２３は、レコード作成部２４からナンバー生成要求を受けると、ナンバーを生成し、レコード作成部２４に送信する。
レコード作成部２４は、システムイベントナンバー生成部２３からナンバーを受信すると、クライアント端末１１〜１ｎから受信したデータ及びシステムイベントナンバー生成部２３から受信したナンバーを含むレコードを作成し、記録媒体２７内のデータベースに格納する（ステップＳ２０４）。
このように、ナンバーを含むレコードを作成し、データベースに格納することができる。
【００４０】
次に、サーバ２１のレコード読出し部２５の動作について説明する。図７は、レコード読出し部２５のレコード読み出し動作の概要を示すフローチャートである。以下、レコード読出し部２５のレコード読み出し動作について、図７を参照しながら説明する。
【００４１】
まず、クライアント端末１１〜１ｎが、所望のレコードを読み出すことをサーバ２１に要求し、サーバ２１のレコード読出し部２５が、レコードの読み出し要求を受信する（ステップＳ３０１）。
次に、レコード読出し部２５は、クライアント端末１１〜１ｎから要求されたレコードを記録媒体２７内のデータベースから検索し、読み出す（ステップＳ３０２）。
レコード読出し部２５は、読み出したレコードをクライアント端末１１〜１ｎに送信する（ステップＳ３０３）。なお、クライアント端末１１〜１ｎが、受信したレコード内のナンバーを表示しないようにすることができ、ユーザが、レコード内のナンバーを編集できないようにすることができる。
【００４２】
次に、サーバ２１のレコード更新部２６の動作について説明する。図８は、レコード更新部２６のレコード更新動作の概要を示すフローチャートである。以下、レコード更新部２６のレコード更新動作について、図７を参照しながら説明する。
【００４３】
まず、クライアント端末１１〜１ｎが、データを編集したレコードをサーバ２１に送信し、サーバ２１のレコード更新部２６が、データを編集したレコードを受信する（ステップＳ４０１）。
次に、レコード更新部２６は、クライアント端末１１〜１ｎから受信したレコード内のナンバーと記録媒体２７内のデータベースに格納されている更新対象レコード内のナンバーとを比較する。そして、レコード更新部２６は、クライアント端末１１〜１ｎから受信したレコード内のナンバーと記録媒体２７内のデータベースに格納されている更新対象レコード内のナンバーとが一致する場合には処理をステップＳ４０３に移し、一致しない場合には処理をステップＳ４０６に移す（ステップＳ４０２）。
【００４４】
ステップＳ４０２にてクライアント端末１１〜１ｎから受信したレコード内のナンバーとデータベースに格納されている更新対象レコード内のナンバーとが一致すると判断した場合には、レコード更新部２６は、システムイベントナンバー生成部２３にナンバーの生成を要求する（ステップＳ４０３）。システムイベントナンバー生成部２３は、レコード更新部２６からナンバー生成要求を受けると、ナンバーを生成し、レコード更新部２６に送信する。
【００４５】
次に、レコード更新部２６は、クライアント端末１１〜１ｎから受信したレコード内のナンバーをシステムイベントナンバー生成部２３から受信したナンバーで置き換える。そして、レコード更新部２６は、ナンバーを置き換えたレコードを記録媒体２７内のデータベースの更新対象レコードが格納されている箇所に格納することにより、データベース内の更新対象レコードを更新する（ステップＳ４０５）。
【００４６】
一方、ステップＳ４０２にてクライアント端末１１〜１ｎから受信したレコード内のナンバーとデータベースに格納されている更新対象レコード内のナンバーとが一致しないと判断した場合には、レコード更新部２６は、記録媒体２７内のデータベースに格納されている更新対象レコードの更新をせず、その旨を通知する警告文をクライアント端末１１〜１ｎに送信する（ステップＳ４０６）。
このように、レコード更新部２６が、クライアント端末１１〜１ｎから受信したレコード内のナンバーとデータベースに格納されている更新対象レコード内のナンバーとが一致する場合にのみ、更新対象レコード内のナンバーを新規生成ナンバーで置き換えて更新することができる。
【００４７】
次に、本実施形態に係るデータ処理方法を用いた実施例について説明する。本実施例は、本実施形態に係るデータ処理方法を社員データベース処理に適用したものである。なお、本実施例において、全てのデータベース操作は、起算日当日に行われるものとする。
本実施例において、サーバ２１の記録媒体２７には、社員に対する手当金を管理する社員データベースのスキーマが構築されている。この社員データベースは、社員名、手当金、及び、ナンバーの３つのカラムを有する。
【００４８】
まず、第１のユーザが社員データベース内にレコードを作成する場合のクライアント端末１１及びサーバ２１の動作について、図９のフローチャートを参照しながら説明する。なお、第１のユーザはクライアント端末１１を使用するものとする。
第１のユーザが、社員名及び手当金を含むデータ（４社員分）をクライアント端末１１に入力し、クライアント端末１１が、社員名及び手当金を含むデータ（４社員分）をサーバ２１に送信する（ステップＳ５０１）。
【００４９】
サーバ２１は、クライアント端末１１から社員名及び手当金を含むデータ（４社員分）を受信すると、４つのナンバーを生成し、それぞれのデータにナンバーを付加したレコード４１〜４４を作成し、社員データベースに格納する（ステップＳ６０１）。図１０（ａ）は、このようにして４つのレコードが格納された社員データベース４０を示す図である。図１０（ａ）に示すように、レコード４１には、“００００１００００００００００００１”という値のナンバーが含まれている。この値は、このナンバーが起算日当日に生成され、サーバ２１が起算日当日に一度もリブートされておらず、このナンバーが起算日当日に生成された最初のナンバーであることを示している。
【００５０】
次に、第２及び第３のユーザがこの社員データベース内のレコード４１を重複して更新しようとする場合のクライアント端末１２及び１３並びにサーバ２１の動作について、図１１のフローチャートを参照しながら説明する。なお、第２のユーザはクライアント端末１２を使用し、第３のユーザはクライアント端末１３を使用するものとする。
まず、第２のユーザが、レコード４１の読み出しを要求し、クライアント端末１２が、レコード４１の読み出し要求をサーバ２１に送信する（ステップＳ７１１）。
【００５１】
サーバ２１は、クライアント端末１２からレコード４１の読み出し要求を受信すると、社員データベース４０からレコード４１を読み出して、クライアント端末１２に送信する（ステップＳ６１１）。クライアント端末１２は、サーバ２１からレコード４１を受信し、表示する。
次に、第２のユーザが、表示されたレコード４１内の所望のデータを編集する（ステップＳ７１２）。ここでは、第２のユーザが、レコード４１内の手当金の金額を５０，０００円から５５，０００円に編集するものとする。図１０（ｂ）は、第２のユーザがレコード４１を編集した結果であるレコード４５を示す図である。
【００５２】
一方、この時、第３のユーザが、レコード４１の読み出しを要求し、クライアント端末１３が、レコード４１の読み出し要求をサーバ２１に送信する（ステップＳ８１１）。
サーバ２１は、クライアント端末１３からレコード４１の読み出し要求を受信すると、社員データベース４０からレコード４１を読み出して、クライアント端末１３に送信する（ステップＳ６１２）。クライアント端末１３は、サーバ２１からレコード４１を受信し、表示する。
次に、第３のユーザは、表示されたレコード４１内の所望のデータを編集する（ステップＳ８１２）。ここでは、第３のユーザが、レコード４１内の手当金の金額を５０，０００円から５７，０００円に編集するものとする。図１０（ｃ）は、第２のユーザがレコード４１を編集した結果であるレコード４６を示す図である。
【００５３】
他方、第２のユーザが、編集したレコード４５の送信を要求し、クライアント端末１２が、レコード４５をサーバ２１に送信する（ステップＳ７１３）。
サーバ２１は、クライアント端末１２からレコード４５を受信すると、レコード４５のナンバーと社員データベース４０に格納されているレコード４１のナンバーとが一致することを確認した後、新しいナンバーを生成する。本実施例では、新しいナンバーは、“００００１００００００００００００５”となる。そして、サーバ２１は、レコード４５のナンバーを新しいナンバーで置き換え、レコード４５を社員データベース４０に格納する（ステップＳ６１３）。図１０（ｄ）は、レコード４５を格納した後の社員データベース４０を示す図である。
【００５４】
一方、第３のユーザが、編集したレコード４６の送信を要求し、クライアント端末１３が、レコード４６をサーバ２１に送信する（ステップＳ８１３）。
サーバ２１は、クライアント端末１３からレコード４６を受信すると、レコード４６のナンバーと社員データベース４０に格納されているレコード４５のナンバーとを比較する。しかし、本実施例においては、レコード４５は既に第２のユーザによって更新されており、レコード４５のナンバーとレコード４６のナンバーは一致しない。そのため、サーバ２１は、レコード４６を社員データベースに格納せず、その旨を示す警告メッセージをクライアント端末１３に送信する（ステップＳ６１４）。
クライアント端末１３は、サーバ２１から受信した警告メッセージを表示する（ステップＳ８１４）。
【００５５】
このように、クライアント端末１２及び１３から受信したレコード内のナンバーと社員データベース４０に格納されているレコード内のナンバーを比較し、一致する場合にのみレコードを更新するので、同一のレコードに対する第２及び第３のユーザの重複した更新を防止することができる。
【００５６】
次に、本発明の第２の実施形態に係るデータ処理方法について説明する。
図１２は、本実施形態に係るデータ処理方法を実施するためのシステムを示す図である。
図１２に示すように、このシステム２は、クライアント端末１１〜１ｎと、サーバ５１とを備えている。
クライアント端末１１〜１ｎ及びサーバ５１は、ネットワーク３１によって相互に接続されている。
【００５７】
図１３は、サーバ５１を示す図である。図１３に示すように、サーバ５１は、システムデート管理部２２と、システムイベントナンバー生成部２３と、レコード作成部２４と、レコード読出し部２５と、レコード更新部２６と、記録媒体２７と、レコード処理部５２とを含んでいる。
レコード処理部５２は、記録媒体２７内のデータベースに格納されたレコードに対して所定の処理を行う。
【００５８】
次に、レコード処理部５２の動作について説明する。図１４は、レコード処理部５２のレコード処理動作の概要を示すフローチャートである。以下、レコード処理部５２のレコード読み出し動作について、図１４を参照しながら説明する。
【００５９】
まず、レコード処理部５２は、所定のデータを含むレコードを記録媒体２７内のデータベースから検索する（ステップＳ９０１）。
次に、レコード処理部５２は、ステップＳ９０１にて検索したレコード内のナンバーより小さいナンバーを含むレコードをデータベースから抽出する（ステップＳ９０２）。
そして、レコード処理部５２は、ステップＳ９０２にて抽出したレコードに対し所定の処理を行う（ステップＳ９０３）。
このように、レコード処理部５２は、所定のデータを含むレコード内のナンバーより小さいナンバーを含むレコードに対してのみ、所定の処理を行うことができる。
【００６０】
次に、本実施形態に係るデータ処理方法を用いた実施例について説明する。本実施例は、本実施形態に係るデータ処理方法を決算処理に適用したものである。なお、本実施例において、起算日は１９９９年４月１日であり、決算日は２０００年３月３１日であるものとする。
本実施例において、サーバ５１の記録媒体２７には、伝票データベースが構築されている。この伝票データベースは、入力日、計上日、伝票内容、及び、ナンバーの４つのカラムを有する。
図１５は、記録媒体２７内の伝票データベースを示す図である。図１５において、この伝票データベース６０には、レコード作成部２４又はレコード更新部２６によってレコード６１〜７１の１１のレコードが格納されている。
【００６１】
次に、サーバ５１のレコード処理部５２の動作について、図１６のフローチャートを参照しながら説明する。
サーバ５１のレコード処理部５２は、クライアント端末１１〜１ｎから決算開始指示を受信すると、図１６の処理を開始する。
まず、レコード処理部５２は、伝票締めを指示するレコードを伝票データベースから検索する（ステップＳ９１１）。本実施例においては、伝票締めを指示するレコードは、レコード７０である。
【００６２】
次に、レコード処理部５２は、ステップＳ９０１にて検索したレコード７０のナンバー（”００３６８００００００００００００２”）よりも小さいナンバーを含むレコードを抽出する（ステップＳ９１２）。本実施例においては、レコード７０のナンバーよりも小さいナンバーを含むレコードは、レコード６１〜６９である。
次に、レコード処理部５２は、ステップＳ９０２にて抽出したレコード６１〜６９の内で計上日が２０００年３月３１日以前であるレコード（本実施例においては、レコード６１〜６４、６６、及び、６８）を集計し、決算処理を行う（ステップＳ９１３）。
【００６３】
このように、ユーザが適切な時に伝票締めを指示するレコード７０を伝票データベースに格納することにより、レコード処理部５２によって決算処理される対象となるレコード６１〜６４、６６、及び、６８を特定することができ、レコード７０の格納後に伝票データベースに格納されたレコード７１を決算処理の対象から外すことができる。従って、決算処理が終了するまで伝票データを含むレコード（本実施例においては、レコード７１）の入力を禁止したり、記録媒体２７内の仮の記録領域に伝票データを仮入力し決算処理終了後に伝票データベース６０に格納し直す必要がない。
なお、伝票締めを指示するレコード７０を伝票データベース６０に格納した後に、何らかの事情によりレコード７１をも決算対象とする必要が生じた場合には、レコード７０を削除し、伝票締めを指示する新たなレコードをレコード７１の次に作成すれば良い。
【００６４】
以上説明した各実施形態及び各実施例において、サーバ２１の他にサブサーバを設置してサーバを多重化することにより、ナンバーの生成をより確実にすることができる。
【００６５】
【発明の効果】
以上述べた様に、本発明の第１の観点によれば、データが編集されたレコード内のナンバーと更新対象レコード内のナンバーとが一致する場合にのみレコードを更新するので、同一レコードに対する複数ユーザの重複読み出しを可能にしつつ、重複更新を防止することができる。また、本発明の第２の観点によれば、複数の装置の内のいずれかの装置によって指示されたデータを含むレコード内のナンバーより小さいナンバーを含むレコードにのみ集計処理を行うので、データの入力とデータに対する処理とを並行して行うことができる。
【図面の簡単な説明】
【図１】本発明の第１の実施形態に係るデータ処理方法を実施するためのシステムを示す図である。
【図２】図１のサーバの構成を示す図である。
【図３】システムイベントナンバーのフォーマットを示す図である。
【図４】本発明の第１の実施形態に係るデータ処理方法の起動処理を示すフローチャートである。
【図５】本発明の第１の実施形態に係るデータ処理方法のシステムイベントナンバー生成処理を示すフローチャートである。
【図６】本発明の第１の実施形態に係るデータ処理方法のレコード作成処理を示すフローチャートである。
【図７】本発明の第１の実施形態に係るデータ処理方法のレコード読出処理を示すフローチャートである。
【図８】本発明の第１の実施形態に係るデータ処理方法のレコード更新処理を示すフローチャートである。
【図９】本発明の第１の実施形態の実施例に係るデータ処理方法のレコード作成処理を示すフローチャートである。
【図１０】本発明の第１の実施形態の実施例に係るデータ処理方法によって処理される社員データベースを示す図である。
【図１１】本発明の第１の実施形態の実施例に係るデータ処理方法のレコード更新処理を示すフローチャートである。
【図１２】本発明の第２の実施形態に係るデータ処理方法を実施するためのシステムを示す図である。
【図１３】図１２のサーバの構成を示す図である。
【図１４】本発明の第２の実施形態に係るデータ処理方法のレコード処理を示すフローチャートである。
【図１５】本発明の第２の実施形態の実施例に係るデータ処理方法によって処理される伝票データベースを示す図である。
【図１６】本発明の第２の実施形態の実施例に係るデータ処理方法の決算処理を示すフローチャートである。
【符号の説明】
１、２ データ処理システム
１１〜１ｎ クライアント端末
２１、５１ サーバ
２２ システムデート管理部
２３ システムイベントナンバー生成部
２４ レコード作成部
２５ レコード読出し部
２６ レコード更新部
２７ 記録媒体
３１ ネットワーク
４０ 社員データベース
４１〜４６ レコード
５２ レコード処理部
６０ 伝票データベース
６１〜７１ レコード
Claims (16)
- 複数の装置と通信することによりデータを処理するサーバであって、
複数のレコードを記録する記録手段と、
所定の起算日から現在までの累積日数を計数してその値を出力する累積日数計数手段と、
第ｎ番目のナンバー生成要求に応じて、ｘ（ｉ）＜ｘ（ｎ）（ｉ＝１、・・・、（ｎ−１））を満たすナンバーｘ（ｎ）であって、前記累積日数計数手段が出力した値を上位桁とし、その日に起動又はリブートされた回数の値を中位桁とし、その日にナンバー生成を要求された回数の値を下位桁とするナンバーを生成するナンバー生成手段と、
前記複数の装置の内のいずれかの装置からデータを受信した場合に、前記ナンバー生成手段にナンバー生成要求を行い、受信したデータ及び前記ナンバー生成手段から出力されたナンバーを含むレコードを前記記録手段に書き込むレコード作成手段と、
前記複数の装置の内のいずれかの装置から前記記録手段に記録されたレコードを読み出す旨の要求を受信した場合に、要求されたレコードを前記記録手段から読み出して前記装置に出力するレコード読出し手段と、
前記複数の装置の内のいずれかの装置からデータが編集されたレコードを受信した場合に、受信したレコード内のナンバーと前記記録手段に記録されている更新対象のレコード内のナンバーとが一致するか否かをチェックし、受信したレコード内のナンバーと前記記録手段に記録されている更新対象のレコード内のナンバーとが一致する場合に、前記ナンバー生成手段にナンバー生成要求を行い、受信したレコード内のナンバーを前記ナンバー生成手段から出力されたナンバーで置き換えたレコードを前記記録手段に書き込むレコード更新手段と、
を具備するデータ処理サーバ。 - 複数の装置と通信することによりデータを処理するサーバであって、
複数のレコードを記録する記録手段と、
所定の起算日から現在までの累積日数を計数してその値を出力する累積日数計数手段と、
第ｎ番目のナンバー生成要求に応じて、ｘ（ｉ）＜ｘ（ｎ）（ｉ＝１、・・・、（ｎ−１））を満たすナンバーｘ（ｎ）であって、前記累積日数計数手段が出力した値を上位桁とし、その日に起動又はリブートされた回数の値を中位桁とし、その日にナンバー生成を要求された回数の値を下位桁とするナンバーを生成して出力するナンバー生成手段と、
前記複数の装置の内のいずれかの装置からデータを受信した場合に、前記ナンバー生成手段にナンバー生成要求を行い、受信したデータ及び前記ナンバー生成手段から出力されたナンバーを含むレコードを前記記録手段に書き込むレコード作成手段と、
前記記録手段に記録されているレコードの内で前記複数の装置の内のいずれかの装置によって指示されたデータを含むレコード内のナンバーより小さいナンバーを有するレコードに対して集計処理を行うレコード処理手段と、
を具備するデータ処理サーバ。 - 前記複数の装置の内のいずれかの装置から前記記録手段に記録されたレコードを読み出す旨の要求を受信した場合に、要求されたレコードを前記記録手段から読み出して前記装置に出力するレコード読出し手段と、
前記複数の装置の内のいずれかの装置からデータが編集されたレコードを受信した場合に、受信したレコード内のナンバーと前記記録手段に記録されている更新対象のレコード内のナンバーとが一致するか否かをチェックし、受信したレコード内のナンバーと前記記録手段に記録されている更新対象のレコード内のナンバーとが一致する場合に、前記ナンバー生成手段にナンバー生成要求を行い、受信したレコード内のナンバーを前記ナンバー生成手段から出力されたナンバーで置き換えたレコードを前記記録手段に書き込むレコード更新手段と、
を更に具備する請求項２記載のデータ処理サーバ。 - 前記記録手段が記録するレコードが伝票に関するレコードであり、前記レコード処理手段が、前記記録手段に記録されているレコードの内で前記複数の装置の内のいずれかの装置によって指示されたデータを含むレコード内のナンバーより小さいナンバーを有するレコードを集計し、決算処理を行うものであることを特徴とする請求項２又は３記載のデータ処理サーバ。
- 前記ナンバー生成手段が生成したナンバーを所定時に記録するナンバー記録手段を更に具備し、
前記ナンバー生成手段が、起動又はリブートされた時に前記ナンバー記録手段に記録されているナンバーの上位桁の値と前記累積日数計数手段が出力する累積日数の値とを比較し、前記ナンバー記録手段に記録されているナンバーの上位桁の値が前記累積日数計数手段が出力する累積日数の値以上の場合には、前記ナンバー記録手段に記録されているナンバーの上位桁を上位桁とし、前記ナンバー記録手段に記録されているナンバーの中位桁をインクリメントした値を中位桁とし、その日のその時からナンバー生成を要求された回数の値を下位桁とするナンバーを生成し、前記ナンバー記録手段に記録されているナンバーの上位桁の値が前記累積日数計数手段が出力する累積日数の値より小さい場合には、前記累積日数計数手段が出力した値を上位桁とし、その日に起動又はリブートされた回数の値を中位桁とし、その日のその時からナンバー生成を要求された回数の値を下位桁とするナンバーを生成することを特徴とする請求項１〜４のいずれか１項に記載のデータ処理サーバ。 - 前記ナンバー記録手段が、前記ナンバー生成手段が生成したナンバーの中位桁に変動があった時にナンバーを記録することを特徴とする請求項５記載のデータ処理サーバ。
- 前記ナンバー生成手段が、ナンバーの下位桁からキャリーが発生した場合には、キャリーをナンバーの中位桁に加算することを特徴とする請求項１〜６のいずれか１項記載のデータ処理サーバ。
- 複数の装置と通信することによりデータを処理する方法であって、
所定の起算日から現在までの累積日数を計数してその値を出力するステップ（ａ）と、
ナンバー生成手段において、第ｎ番目のナンバー生成要求に応じて、ｘ（ｉ）＜ｘ（ｎ）（ｉ＝１、・・・、（ｎ−１））を満たすナンバーｘ（ｎ）であって、ステップ（ａ）が出力した値を上位桁とし、その日に起動又はリブートされた回数の値を中位桁とし、その日にナンバー生成を要求された回数の値を下位桁とするナンバーを生成するステップ（ｂ）と、
前記複数の装置の内のいずれかの装置からデータを受信した場合に、前記ナンバー生成手段にナンバー生成要求を行い、受信したデータ及び前記ナンバー生成手段から出力されたナンバーを含むレコードを記録媒体に記録するステップ（ｃ）と、
前記複数の装置の内のいずれかの装置からレコードを読み出す旨の要求を受信した場合に、要求されたレコードを前記記録媒体から読み出して前記装置に出力するステップ（ｄ）と、
前記複数の装置の内のいずれかの装置からデータが編集されたレコードを受信した場合に、受信したレコード内のナンバーと前記記録媒体に記録されている更新対象のレコード内のナンバーとが一致するか否かをチェックし、受信したレコード内のナンバーと前記記録媒体に記録されている更新対象のレコード内のナンバーとが一致する場合に、前記ナンバー生成手段にナンバー生成要求を行い、受信したレコード内のナンバーを前記ナンバー生成手段から出力されたナンバーで置き換えたレコードを前記記録媒体に書き込むステップ（ｅ）と、
を具備するデータ処理方法。 - 複数の装置と通信することによりデータを処理する方法であって、
所定の起算日から現在までの累積日数を計数してその値を出力するステップ（ａ）と、
ナンバー生成手段において、第ｎ番目のナンバー生成要求に応じて、ｘ（ｉ）＜ｘ（ｎ）（ｉ＝１、・・・、（ｎ−１））を満たすナンバーｘ（ｎ）であって、ステップ（ａ）が出力した値を上位桁とし、その日に起動又はリブートされた回数の値を中位桁とし、そ の日にナンバー生成を要求された回数の値を下位桁とするナンバーを生成するステップ（ｂ）と、
前記複数の装置の内のいずれかの装置からデータを受信した場合に、前記ナンバー生成手段にナンバー生成要求を行い、受信したデータ及び前記ナンバー生成手段から出力されたナンバーを含むレコードを記録媒体に書き込むステップ（ｃ）と、
前記記録媒体に記録されているレコードの内で前記複数の装置の内のいずれかの装置によって指示されたデータを含むレコード内のナンバーより小さいナンバーを有するレコードに対して集計処理を行うステップ（ｄ）と、
を具備するデータ処理方法。 - 前記複数の装置の内のいずれかの装置から前記記録媒体に記録されたレコードを読み出す旨の要求を受信した場合に、要求されたレコードを前記記録媒体から読み出して前記装置に出力するステップ（ｅ）と、
前記複数の装置の内のいずれかの装置からデータが編集されたレコードを受信した場合に、受信したレコード内のナンバーと前記記録媒体に記録されている更新対象のレコード内のナンバーとが一致するか否かをチェックし、受信したレコード内のナンバーと前記記録媒体に記録されている更新対象のレコード内のナンバーとが一致する場合に、前記ナンバー生成手段にナンバー生成要求を行い、受信したレコード内のナンバーを前記ナンバー生成手段から出力されたナンバーで置き換えたレコードを前記記録媒体に書き込むステップ（ｆ）と、
を更に具備する請求項９記載のデータ処理方法。 - 前記記録媒体に記録されるレコードが伝票に関するレコードであり、ステップ（ｄ）が、前記記録手段に記録されているレコードの内で前記複数の装置の内のいずれかの装置によって指示されたデータを含むレコード内のナンバーより小さいナンバーを有するレコードを集計し、決算処理を行うものであることを特徴とする請求項９又は１０記載のデータ処理方法。
- ステップ（ｂ）において生成したナンバーを所定時に記録するステップ（ｇ）を更に具備し、
ステップ（ｂ）が、起動又はリブートされた時にステップ（ｇ）において記録されたナンバーの上位桁の値とステップ（ａ）において出力された累積日数の値とを比較し、ステップ（ｇ）において記録されたナンバーの上位桁の値がステップ（ａ）において出力された累積日数の値以上の場合には、ステップ（ｇ）において記録されたナンバーの上位桁を上位桁とし、ステップ（ｇ）において記録されたナンバーの中位桁をインクリメントした値を中位桁とし、その日のその時からナンバー生成を要求された回数の値を下位桁とするナンバーを生成し、ステップ（ｇ）において記録されたナンバーの上位桁の値がステップ（ａ）において出力された累積日数の値より小さい場合には、ステップ（ａ）において出力された値を上位桁とし、その日に起動又はリブートされた回数の値を中位桁とし、その日のその時からナンバー生成を要求された回数の値を下位桁とするナンバーを生成するステップを含むことを特徴とする請求項８〜１１のいずれか１項に記載のデータ処理方法。 - ステップ（ｇ）が、ステップ（ｂ）によって生成されたナンバーの中位桁に変動があった時にナンバーを記録するステップを含むことを特徴とする請求項１２記載のデータ処理サーバ。
- ステップ（ｂ）が、ナンバーの下位桁からキャリーが発生した場合には、キャリーをナンバーの中位桁に加算するステップを含むことを特徴とする請求項８〜１３のいずれか１項記載のデータ処理サーバ。
- 複数の装置と通信することによりデータを処理するためにＣＰＵで読み取り可能な記録媒体であって、
所定の起算日から現在までの累積日数を計数してその値を出力する手順（ａ）と、
ナンバー生成手段において、第ｎ番目のナンバー生成要求に応じて、ｘ（ｉ）＜ｘ（ｎ）（ｉ＝１、・・・、（ｎ−１））を満たすナンバーｘ（ｎ）であって、手順（ａ）が出力した値を上位桁とし、その日に起動又はリブートされた回数の値を中位桁とし、その日 にナンバー生成を要求された回数の値を下位桁とするナンバーを生成する手順（ｂ）と、
前記複数の装置の内のいずれかの装置からデータを受信した場合に、前記ナンバー生成手段にナンバー生成要求を行い、受信したデータ及び前記ナンバー生成手段から出力されたナンバーを含むレコードを記録媒体に記録する手順（ｃ）と、
前記複数の装置の内のいずれかの装置からレコードを読み出す旨の要求を受信した場合に、要求されたレコードを前記記録媒体から読み出して前記装置に出力する手順（ｄ）と、
前記複数の装置の内のいずれかの装置からデータが編集されたレコードを受信した場合に、受信したレコード内のナンバーと前記記録媒体に記録されている更新対象のレコード内のナンバーとが一致するか否かをチェックし、受信したレコード内のナンバーと前記記録媒体に記録されている更新対象のレコード内のナンバーとが一致する場合に、前記ナンバー生成手段にナンバー生成要求を行い、受信したレコード内のナンバーを前記ナンバー生成手段から出力されたナンバーで置き換えたレコードを前記記録媒体に書き込む手順（ｅ）と、
を前記ＣＰＵに実行させるためのプログラムを記録した記録媒体。 - 複数の装置と通信することによりデータを処理するためにＣＰＵで読み取り可能な記録媒体であって、
所定の起算日から現在までの累積日数を計数してその値を出力する手順（ａ）と、
ナンバー生成手段において、第ｎ番目のナンバー生成要求に応じて、ｘ（ｉ）＜ｘ（ｎ）（ｉ＝１、・・・、（ｎ−１））を満たすナンバーｘ（ｎ）であって、手順（ａ）が出力した値を上位桁とし、その日に起動又はリブートされた回数の値を中位桁とし、その日にナンバー生成を要求された回数の値を下位桁とするナンバーを生成する手順（ｂ）と、
前記複数の装置の内のいずれかの装置からデータを受信した場合に、前記ナンバー生成手段にナンバー生成要求を行い、受信したデータ及び前記ナンバー生成手段から出力されたナンバーを含むレコードを記録媒体に書き込む手順（ｃ）と、
前記記録媒体に記録されているレコードの内で前記複数の装置の内のいずれかの装置によって指示されたデータを含むレコード内のナンバーより小さいナンバーを有するレコードに対して集計処理を行う手順（ｄ）と、
を前記ＣＰＵに実行させるためのプログラムを記録した記録媒体。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001023005A JP3615150B2 (ja) | 2001-01-31 | 2001-01-31 | データ処理サーバ及び方法並びにデータ処理プログラムを記録した記録媒体 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001023005A JP3615150B2 (ja) | 2001-01-31 | 2001-01-31 | データ処理サーバ及び方法並びにデータ処理プログラムを記録した記録媒体 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2002229833A JP2002229833A (ja) | 2002-08-16 |
| JP3615150B2 true JP3615150B2 (ja) | 2005-01-26 |
Family
ID=18888340
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2001023005A Expired - Fee Related JP3615150B2 (ja) | 2001-01-31 | 2001-01-31 | データ処理サーバ及び方法並びにデータ処理プログラムを記録した記録媒体 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3615150B2 (ja) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP5105922B2 (ja) * | 2007-03-22 | 2012-12-26 | 日本電気株式会社 | 情報更新システム、情報記憶サーバ、情報更新方法、及び、プログラム |
| CN103384399B (zh) | 2012-05-02 | 2017-04-12 | 阿里巴巴集团控股有限公司 | 近场传递信息的方法、信息传达和接受客户端、信息*** |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH04336342A (ja) * | 1991-05-14 | 1992-11-24 | Nec Software Kansai Ltd | レコード更新管理方式 |
| JPH06332856A (ja) * | 1993-05-18 | 1994-12-02 | Nippon Yunishisu Kk | オンライン業務処理方式 |
| JP2002236747A (ja) * | 2001-02-07 | 2002-08-23 | Sanyo Electric Co Ltd | 診療データ入力装置 |
-
2001
- 2001-01-31 JP JP2001023005A patent/JP3615150B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2002229833A (ja) | 2002-08-16 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110495132B (zh) | 用于在分布式网络节点内生成、上传和执行代码区块的***和方法 | |
| US9244953B2 (en) | Systems and methods for asynchronous schema changes | |
| CN102142024B (zh) | 在分布式数据库中使用递增捕捉来进行逻辑数据备份和回退 | |
| IL276744A (en) | Integrated feedback based on a touring agent for full transactions with the 'blockchain' system | |
| US7676503B2 (en) | Hybrid computer restore using network service | |
| US20060259960A1 (en) | Server, method and program product for management of password policy information | |
| DE102005038866A1 (de) | Sicheres elektronisches Auslieferungssiegel für ein informationsverarbeitendes System | |
| JP2006508473A (ja) | 記憶システムにおけるデータ回復技術 | |
| WO2007105274A1 (ja) | 適用パッチ選別装置及び適用パッチ選別方法 | |
| US20070214195A1 (en) | Idempotent journal mechanism for file system | |
| WO2005114487A2 (en) | Method and apparatus for updating a database using table staging and queued relocation and deletion | |
| CN113141369B (zh) | 基于人工智能的防火墙策略管理方法及相关设备 | |
| CN101710373A (zh) | 嵌入式***的文件操作方法 | |
| JP3615150B2 (ja) | データ処理サーバ及び方法並びにデータ処理プログラムを記録した記録媒体 | |
| JP2006277574A (ja) | 医用機器におけるソフトウェア構成管理システム | |
| US11556519B2 (en) | Ensuring integrity of records in a not only structured query language database | |
| EP3779755A1 (en) | A computer-implemented method for cross-chain-interoperability | |
| WO2011042961A1 (ja) | 更新管理装置及び方法 | |
| KR102164779B1 (ko) | 기록된 거래의 수정이 가능한 블록체인 | |
| JP2004355203A (ja) | データの更新・履歴・集計管理方式 | |
| JP4348770B2 (ja) | 設計図面の編集履歴管理システム | |
| JP2008293229A (ja) | 履歴データ処理装置および方法 | |
| JP2004013867A (ja) | 複製データベースシステム、データベース装置及びそれに用いるデータベース更新方法並びにそのプログラム | |
| JPH10154090A (ja) | データ管理システム | |
| JP2000010766A (ja) | プログラム修正抽出適用システムおよび修正抽出適用プログラムを格納した記憶媒体 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20040518 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040712 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20041020 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20041028 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 Ref document number: 3615150 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| S531 | Written request for registration of change of domicile |
Free format text: JAPANESE INTERMEDIATE CODE: R313531 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20071112 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101112 Year of fee payment: 6 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20131112 Year of fee payment: 9 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| LAPS | Cancellation because of no payment of annual fees |