(57)【要約】【課題】  データ処理装置がデータベースサーバから検索処理結果を逐次取得する際に、データベースサーバからのデータ供給が停止し、データ取得を再開する場合に、中断による遅延時間を短縮させることができる。【解決手段】  本発明は、データ処理装置に関する。そして、本発明のデータ処理装置は、データベースから検索処理を実行して主キーに基づく順序で、所定件数のレコードを１つの送信単位データとして送信する処理を、データベースサーバに依頼する手段と、供給されたデータの処理を行う手段と、供給された送信単位データの最後の順序のレコードについて主キーの項目のデータを最終受信位置情報として保持する手段と、データ供給が中断した後、最終受信位置情報に基づいて、検索結果のうちデータベースサーバから供給されなかったレコードのみを検索処理してデータ送信処理することを依頼する手段とを有することを特徴とする。【選択図】      図１
2015022554.tif 000002
【特許請求の範囲】
【請求項１】
複数のレコードのデータが蓄積されたデータベースから検索処理を実行し、その検索処理による検索結果について、１又は複数の項目で構成される主キーに基づく順序で、所定件数のレコードを１つの送信単位データとして送信するデータ送信処理を、データベースサーバに依頼する第１の検索依頼手段と、
上記データベースサーバから供給された各送信単位データに含まれるレコードのデータ処理を行うデータ処理手段と、
上記データベースサーバから供給された送信単位データを構成する最後の順序のレコードについて、少なくとも主キーの項目のデータを最終受信位置情報として保持する最終受信位置情報保持手段と、
上記第１の検索依頼手段により依頼した検索処理に基づく上記データベースサーバからのデータ供給が中断した後、上記最終受信位置情報保持手段が保持している最終受信位置情報に基づいて、上記第１の検索依頼手段が依頼した検索処理の検索結果のうち上記データベースサーバから供給されなかったレコードのみを検索処理し、その検索結果について上記データ送信処理を依頼する第２の検索依頼手段と
を有することを特徴とするデータ処理装置。
【請求項２】
上記第２の検索依頼手段は、上記第１の検索依頼手段により依頼した検索処理に基づく上記データベースサーバからのデータ供給が中断した後、上記第１の検索依頼手段が依頼した検索処理の検索結果のうち、上記最終受信位置情報保持手段が保持している最終受信位置情報に係るレコードより後の順序のレコードのみを検索処理し、その検索結果についてデータ送信処理を依頼することを特徴とする請求項１に記載のデータ処理装置。
【請求項３】
コンピュータを、
複数のレコードのデータが蓄積されたデータベースから検索処理を実行し、その検索処理による検索結果について、１又は複数の項目で構成される主キーに基づく順序で、所定件数のレコードを１つの送信単位データとして送信するデータ送信処理を、データベースサーバに依頼する第１の検索依頼手段と、
上記データベースサーバから供給された各送信単位データに含まれるレコードのデータ処理を行うデータ処理手段と、
上記データベースサーバから供給された送信単位データを構成する最後の順序のレコードについて、少なくとも主キーの項目のデータを最終受信位置情報として保持する最終受信位置情報保持手段と、
上記第１の検索依頼手段により依頼した検索処理に基づく上記データベースサーバからのデータ供給が中断した後、上記最終受信位置情報保持手段が保持している最終受信位置情報に基づいて、上記第１の検索依頼手段が依頼した検索処理の検索結果のうち上記データベースサーバから供給されなかったレコードのみを検索処理し、その検索結果について上記データ送信処理を依頼する第２の検索依頼手段と
して機能させることを特徴とするデータ処理プログラム。
【請求項４】
１又は複数のデータベースサーバと、上記データベースサーバに検索処理を依頼するデータ処理装置とを備えるデータベースシステムにおいて、上記データ処理装置として請求項１又は２に記載のデータ処理装置を適用したことを特徴とするデータベースシステム。
【請求項５】
データベースサーバから通信制御に係るデータを取得するデータ処理装置と、上記データ処理装置が取得したデータを用いて通信装置間の通信制御処理を行う通信制御処理手段とを備える通信制御装置において、上記データ処理装置として請求項１又は２に記載のデータ処理装置を適用したことを特徴とする通信制御装置。
【請求項６】
複数の通信装置と、上記通信装置間の通信制御処理を行う通信制御装置とを備えるネットワークシステムにおいて、上記通信制御装置として請求項５に記載の通信制御装置を適用したことを特徴とするネットワークシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、データ処理装置、データ処理プログラム、データベースシステム、通信制御装置、及びネットワークシステムに関し、例えば、データベースサーバから多量の検索データを取得するデータベースクライアント（ＲＤＢＭＳ（Ｒｅｌａｔｉｏｎａｌ  ＤａｔａＢａｓｅ  Ｍａｎａｇｅｍｅｎｔ  Ｓｙｓｔｅｍ）のデータベースクライアント）を備える通信制御装置に適用し得る。
【背景技術】
【０００２】
従来のデータベースシステムでは、データベースクライアントから発行されたトランザクション（データ検索要求）に対する応答結果が、多量のデータとなる場合、一般的には、検索結果を任意のレコード数単位に小分けし、データベースサーバからデータを取得するフェッチ処理を採用することが多い。
【０００３】
従来のデータベースクライアントにおけるフェッチ機能（ＲＤＢＭＳに実装されているフェッチ機能）では、データベースサーバから、所定数（フェッチ処理する単位）分の検索結果についてカーソルをオープンして、カーソルオープンしたレコードについてフェッチ処理する（データ取得する）動作を繰りかえすことにより多量データを順次取得する。
【０００４】
従来のデータベースクライアントでは、このフェッチ機能により、多量データを取得する為のバッファ（メモリ）を検索結果の多量データ全レコード数分のサイズよりも小さく実装することができる。
【０００５】
従来、フェッチ機能に対応したデータベースシステム（データベースクライアント）としては、例えば、特許文献１の記載技術がある。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００９−２４５２８３
【発明の概要】
【発明が解決しようとする課題】
【０００７】
従来のデータベースクライアントでは、フェッチ機能により、カーソルオープン及びフェッチ処理を繰り返す場合、データベースサーバとの間で通信セッションを維持し、当該セッションでカーソルの位置が維持・管理される。したがって、従来のデータベースクライアントでは、フェッチ機能によりデータ取得を開始した場合、検索結果のレコードの全てのフェッチ処理がするまで、通信セッションが維持される必要がある。
【０００８】
従来のデータベースクライアントにおいて、フェッチ機能によりデータ取得中にデータベースサーバとの間の通信セッションが、何等かの障害（例えば、ネットワーク障害やデータベースサーバの故障等）により切断された場合、カーソル情報は破棄され、検索結果の取得が途中終了することになる。このカーソルには、取得対象データに関するフェッチ情報、すなわち、どのデータを取得したかが記録されている。したがって、従来のデータベースクライアントにおいて、セッションが切断されカーソルがクローズされると、以降のデータ取得が実施できないこととなる。
【０００９】
このような場合、従来のデータベースクライアントは、障害の復旧後、再度検索を実施し、結果を取得し直す事となるが、検索結果のレコード数が増加すれば、それだけフェッチ回数、全データ取得までの所要時間も増加するため、障害発生時のリスクは大きく、データ検索処理が完了しないことによるシステムヘの影響が懸念される。
【００１０】
例えば、通信キャリアのネットワーク上に構築されたＳＩＰ（Ｓｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）サーバ（例えば、ＳＩＰ通信の呼制御を行う呼制御装置等）では、当該通信制御装置で必要となる分の顧客データ（加入者データ）をデータベースサーバから取得して動作するものがある。通常、通信キャリアの通信制御装置で管理される顧客データは大量であるため、通信制御装置の処理能力を考慮して、データベースクライアントのフェッチ機能を用いたデータ取得が行われる場合がある。しかしながら、この通信制御装置で、フェッチ機能により顧客データの取得中に障害があった場合、サービス開始できない状態が長期間継続してしまうおそれがある。
【００１１】
そのため、データ処理装置（例えば、データベースクライアント）がデータベースサーバから検索処理結果を逐次取得（例えば、フェッチ処理によりデータ取得する場合）する際に、データベースサーバからのデータ供給が停止し、データ取得を再開する場合に、中断による遅延時間を短縮させるデータ処理装置、データ処理プログラム、データベースシステム、通信制御装置、及びネットワークシステムが望まれている。
【課題を解決するための手段】
【００１２】
第１の本発明のデータ処理装置は、（１）複数のレコードのデータが蓄積されたデータベースから検索処理を実行し、その検索処理による検索結果について、１又は複数の項目で構成される主キーに基づく順序で、所定件数のレコードを１つの送信単位データとして送信するデータ送信処理を、データベースサーバに依頼する第１の検索依頼手段と、（２）上記データベースサーバから供給された各送信単位データに含まれるレコードのデータ処理を行うデータ処理手段と、（３）上記データベースサーバから供給された送信単位データを構成する最後の順序のレコードについて、少なくとも主キーの項目のデータを最終受信位置情報として保持する最終受信位置情報保持手段と、（４）上記第１の検索依頼手段により依頼した検索処理に基づく上記データベースサーバからのデータ供給が中断した後、上記最終受信位置情報保持手段が保持している最終受信位置情報に基づいて、上記第１の検索依頼手段が依頼した検索処理の検索結果のうち上記データベースサーバから供給されなかったレコードのみを検索処理し、その検索結果について上記データ送信処理を依頼する第２の検索依頼手段とを有することを特徴とする。
【００１３】
第２の本発明のデータ処理プログラムは、コンピュータを、（１）複数のレコードのデータが蓄積されたデータベースから検索処理を実行し、その検索処理による検索結果について、１又は複数の項目で構成される主キーに基づく順序で、所定件数のレコードを１つの送信単位データとして送信するデータ送信処理を、データベースサーバに依頼する第１の検索依頼手段と、（２）上記データベースサーバから供給された各送信単位データに含まれるレコードのデータ処理を行うデータ処理手段と、（３）上記データベースサーバから供給された送信単位データを構成する最後の順序のレコードについて、少なくとも主キーの項目のデータを最終受信位置情報として保持する最終受信位置情報保持手段と、（４）上記第１の検索依頼手段により依頼した検索処理に基づく上記データベースサーバからのデータ供給が中断した後、上記最終受信位置情報保持手段が保持している最終受信位置情報に基づいて、上記第１の検索依頼手段が依頼した検索処理の検索結果のうち上記データベースサーバから供給されなかったレコードのみを検索処理し、その検索結果について上記データ送信処理を依頼する第２の検索依頼手段として機能させることを特徴とする。
【００１４】
第３の本発明は、１又は複数のデータベースサーバと、上記データベースサーバに検索処理を依頼するデータ処理装置とを備えるデータベースシステムにおいて、上記データ処理装置として第１の本発明のデータ処理装置を適用したことを特徴とするデータベースシステム。
【００１５】
第４の本発明の通信制御装置は、データベースサーバから通信制御に係るデータを取得するデータ処理装置と、上記データ処理装置が取得したデータを用いて通信装置間の通信制御処理を行う通信制御処理手段とを備える通信制御装置において、上記データ処理装置として第１の本発明のデータ処理装置を適用したことを特徴とする通信制御装置。
【００１６】
第５の本発明は、複数の通信装置と、上記通信装置間の通信制御処理を行う通信制御装置とを備えるネットワークシステムにおいて、上記通信制御装置として第４の本発明の通信制御装置を適用したことを特徴とするネットワークシステム。
【発明の効果】
【００１７】
本発明によれば、データ処理装置がデータベースサーバから検索処理結果を逐次取得する際に、データベースサーバからのデータ供給が停止し、データ取得を再開する場合に、中断による遅延時間を短縮させることができる。
【図面の簡単な説明】
【００１８】
【図１】実施形態に係るネットワークシステムの全体構成について示したブロック図である。
【図２】実施形態に係るデータベースサーバが有する顧客データベースの構成例について示した説明図である。
【図３】実施形態に係るデータベースクライアントがデータベースサーバに送信する検索要求のＳＱＬ文（プライマリキーが１つの場合）について示した説明図である。
【図４】実施形態に係るデータベースクライアントとデータベースサーバとの間のデータ取得シーケンス（正常系の動作）について示したシーケンス図である。
【図５】実施形態に係るデータベースサーバが取得する顧客データベースの検索結果（プライマリキーが１つの場合）について示した説明図である。
【図６】実施形態に係るデータベースクライアントとデータベースサーバとの間のデータ取得シーケンス（中断が発生した場合、その１）について示したシーケンス図である。
【図７】実施形態に係るデータベースクライアントとデータベースサーバとの間のデータ取得シーケンス（中断が発生した場合、その２）について示したシーケンス図である。
【図８】実施形態に係るデータベースクライアントが、データ取得シーケンスを再開する際に生成するＳＱＬ文（プライマリキーが１つの場合）について示した説明図である。
【図９】実施形態に係るデータベースサーバがデータ取得シーケンス再開時に取得する顧客データベースの検索結果（プライマリキーが１つの場合）について示した説明図である。
【図１０】実施形態に係るデータベースクライアントがデータベースサーバに送信する検索要求のＳＱＬ文（プライマリキーが複数の場合）について示した説明図である。
【図１１】実施形態に係るデータベースサーバが取得する顧客データベースの検索結果（プライマリキーが複数の場合）について示した説明図である。
【図１２】実施形態に係るデータベースクライアントが、データ取得シーケンスを再開する際に生成するＳＱＬ文（プライマリキーが複数の場合）について示した説明図である。
【図１３】実施形態に係るデータベースクライアントが、データ取得シーケンスを再開する際に生成するＳＱＬ文（プライマリキーが複数の場合）の生成論理について示した説明図である。
【図１４】実施形態に係る変形例のデータベースクライアントが生成するＳＱＬ文について示した説明図である。
【発明を実施するための形態】
【００１９】
（Ａ）主たる実施形態
以下、本発明によるデータ処理装置、データ処理プログラム、データベースシステム、通信制御装置、及びネットワークシステムの一実施形態を、図面を参照しながら詳述する。なお、以下では、本発明のデータ処理装置をデータベースクライアントに適用する例について説明する。
【００２０】
（Ａ−１）実施形態の構成
図１は、この実施形態のネットワークシステムの全体構成について示したブロック図である。また、図１では、この実施形態の通信制御装置１０の機能的構成についても示している。
【００２１】
ネットワークシステム１は、通信制御装置１０、２台のデータベースサーバ２０（２０−１、２０−２）、及び通信制御装置１０の配下に接続される複数の通信装置３０を有している。なお、ネットワークシステム１を構成する各装置の台数は限定されないものである。また、通信制御装置１０及びデータベースサーバ２０−１、２０−２は、それぞれネットワークＮ１に接続しており、相互に通信可能な構成となっている、また、通信制御装置１０及び通信装置３０は、それぞれネットワークＮ３に接続しており、相互に通信可能な構成となっている。
【００２２】
通信制御装置１０は、通信装置３０間の通信の通信制御（例えば、ＳＩＰのメッセージ交換による呼制御）を行う装置である。
【００２３】
各通信装置３０は、通信制御装置１０の通信制御に基づいて他の通信装置３０と通信するものである。各通信装置３０としては、例えば、ＳＩＰメッセージ交換に基づいた音声通話、ビデオ通話等に対応したソフトウェアがインストールされたＰＣやスマートホン等を適用することができるため詳しい説明は省略する。
【００２４】
データベースサーバ２０−１、２０−２は、２台で冗長化された１つのデータベースサービスを提供するサーバである。
【００２５】
次に、データベースサーバ２０−１、２０−２の詳細構成について説明する。
【００２６】
データベースサーバ２０−１、２０−２は、通信制御装置１０が通信制御処理を行うために必要な顧客データ（各通信装置３０自体や各通信装置３０を利用する顧客（加入者）に係る情報等を含むデータ）をデータベース化して管理しており、管理しているデータベースを通信制御装置１０に提供する。データベースサーバ２０−１、２０−２は、いずれか一方が現用系（アクティブ状態）として動作し、他方が待機系（スタンバイ状態）として動作する冗長構成（ホットスタンバイ方式）で、動作しているものとする。以下では、通常、データベースサーバ２０−１が現用系として動作し、データベースサーバ２０−２が待機系として動作しているものとして説明する。なお、データベースサーバ２０−１、２０−２の冗長構成の具体的な方式は上述のホットスタンバイに限定されないものであり、コールドスタンバイ方式やクラスタリング方式等の種々の冗長構成を適用することができる。
【００２７】
各データベースサーバ２０は、同じ構成となっており、機能的には、データベースサービスのデータ処理を行うサーバプロセス２１と、データベースのデータストレージとして機能するファイルシステム２２を有している。
【００２８】
サーバプロセス２１は、例えば、種々のＲＤＢＭＳのサーバプラットフォームを用いて構築することができる。また、ファイルシステム２２は、種々のデータストレージ（例えば、ハードディスクドライブ等を用いたデータストレージ）を用いることができる。この実施形態では、サーバプロセス２１は、データベースクライアントからＳＱＬ（Ｓｔｒｕｃｔｕｒｅｄ  Ｑｕｅｒｙ  Ｌａｎｇｕａｇｅ）を用いた命令（プログラム）に基づくデータ処理（データ検索）を受付けることができるＲＤＢＭＳにより構築されているものとして説明する。
【００２９】
また、データベースサーバ２０−１のファイルシステム２２と、データベースサーバ２０−２のファイルシステム２２とは、ネットワークＮ２を介して接続されており、リアルタイムにデータ同期が行われているものとする。データベースサーバ２０間のデータ同期構成については種々のデータストレージと同様の構成を適用することができるため、詳しい説明を省略する。上述の通り、ファイルシステム２２には、通信制御装置１０に提供するための顧客データのデータベースが格納されている。
【００３０】
この実施形態では、データベースサーバ２０のファイルシステム２２に格納される顧客データのデータベース（以下、「顧客データベース」とも呼ぶ）として、図２に示すようなテーブルで示すことができる構造のデータが格納されているものとして説明する。なお、データベースサーバ２０のファイルシステム２２に格納される顧客データベースの具体的な構造については限定されないものである。
【００３１】
図２に示すように、顧客データベースでは、１人の顧客について１つのレコード（１行のデータ）で示されるデータが蓄積されている。図２に示すように、この実施形態において、各レコードには、少なくとも当該顧客に係る、顧客登録番号、氏名、性別、住所、電話番号のデータが含まれているものとするが、各レコードを構成する項目についても限定されないものである。例えば、各レコードを構成する項目として、各種システムに用いるユーザＩＤ、パスワード、アドレス情報（対応する通信装置３０の識別情報）等を含めるようにしてもよい。
【００３２】
次に、通信制御装置１０の詳細構成について説明する。
【００３３】
図１に示すように、通信制御装置１０は、機能的には、データベースクライアント１１、顧客データ記憶部１２、及び通信処理部１３を有している。なお、通信制御装置１０としては、例えば、既存のＰＣやワークステーション等のコンピュータに、データベースクライアント１１及び通信処理部１３等に対応するソフトウェア（本発明のデータ処理プログラムを含むプログラム）をインストールすることにより実現するようにしてもよい。
【００３４】
なお、この実施形態のデータベースシステムは、通信制御装置１０のデータベースクライアント１１、及びデータベースサーバ２０−１、２０−２により構成されているものとして説明する。この実施形態では、データベースクライアント１１は通信制御装置１０に搭載されているものとして説明するが、データベースクライアント１１を単独の装置として構築するようにしてもよい。
【００３５】
顧客データ記憶部１２は、データベースクライアント１１がデータベースサーバ２０−１、２０−２に検索処理を依頼して取得した各レコード（顧客データ）を記憶するための記憶手段である。
【００３６】
通信処理部１３は、ＳＩＰメッセージ等を用いて通信装置３０間の通信制御を行う通信制御手段の機能を担っている。通信処理部１３は、通信制御に際して、顧客データ記憶部１２に記憶されている顧客データを利用するものとする。なお、通信処理部１３が通信制御に用いるプロトコルや、通信処理部１３が通信制御に際しても散る顧客データの項目については限定されないものである。通信処理部１３自体の構成は、種々の通信制御装置（例えば、ＳＩＰサーバ等）と同様の構成を適用することができるため、詳しい説明は省略する。
【００３７】
データベースクライアント１１は、データベースサーバ２０（２０−１、２０−２）から顧客データベースの一部又は全部を検索依頼処理により取得して、顧客データ記憶部１２に記憶する顧客データの登録・更新等の処理を行う。なお、通信制御装置１０がソフトウェア的に実現される場合、データベースクライアント１１に対応するプログラムは、本発明のデータ処理プログラムに該当する。
【００３８】
データベースクライアント１１は、例えば、種々のＲＤＢＭＳのプラットフォームにより提供されるデータベースアプリケーション（ミドルウェア）上で、ユーザプログラムを動作させることにより実現するようにしてもよい。この実施形態において、データベースクライアント１１は、機能的には、データベース処理部１１１、ポインタ保持部１１２、及びデータ取得継続処理１１３の３つの構成要素（プログラム、モジュール）を用いて構成されるものとして説明するが、各構成要素を実現する具体的なモジュール構成については限定されないものである。この実施形態では、説明を簡易とするために、データベースクライアント１１は上述の３つの構成要素を用いて構成されるものとして説明するが、具体的なモジュール構造について限定されるものではない。例えば、１つモジュールに上述の３つの構成要素の各機能を全て盛り込んでデータベースクライアント１１を構成するようにしてもよい。
【００３９】
データベース処理部１１１は、主として、データベースサーバ２０に顧客データベースに対する検索処理を依頼し、その検索結果を処理（この実施形態では、取得した検索結果を顧客データとして、顧客データ記憶部１２に記憶させる処理）するものである。具体的には、データベース処理部１１１は、フェッチ機能を利用した検索処理（顧客データベースに対する検索処理）を、データベースサーバ２０（サーバプロセス２１）に要求して、検索結果（該当するレコードのデータ）の供給を受ける。ここでは、データベース処理部１１１には、１回のフェッチ処理で、取得するレコード数(以下、「フェッチ数」と呼ぶ)として１００が設定されているものとする。言い換えると、データベース処理部１１１は、データベースサーバ２０（サーバプロセス２１）に対して、検索結果のうちフェッチ数のレコードを１つの送信単位として逐次送信を依頼する。なお、データベース処理部１１１がデータ取得の際に用いるフェッチ数は動的に変更するようにしてもよいが、この実施形態のデータベース処理部１１１は、当初設定されたフェッチ数のみを用いるものとして説明する。
【００４０】
また、この実施形態では、データベース処理部１１１は、ＳＱＬ文を用いて、データベースサーバ２０（サーバプロセス２１）に検索処理依頼を行うものとして説明するが、検索処理依頼に用いる具体的なデータベース言語やシーケンスの内容については限定されないものである。例えば、データベースクライアント１１は、図３に示す「ＳＥＬＥＣＴ顧客登録番号、氏名、性別、年齢、住所、電話番号  ＦＲＯＭ  頑客データ  ＯＲＤＥＲ  ＢＹ  顧客登録番号」というＳＱＬ文（ＳＥＬＥＣＴコマンドを用いたＳＱＬ文）を用いて、データベースサーバ２０（サーバプロセス２１）に顧客データを要求することができる。
【００４１】
図３に示すＳＱＬ文は、データベースサーバ２０の「顧客データベース」テーブルのうち、「顧客登録番号、氏名、性別、年齢、住所、電話番号」の項目のデータについて、「顧客登録番号」をプライマリキー（主キー）としてソートされた順序で取得することをあらわしている。以下では、ＳＱＬ文で抽出対象となる項目（ＳＥＬＥＣＴに続く項目、例えば、図３では「顧客登録番号、氏名、性別、年齢、住所、電話番号」の項目）については「抽出項目」と呼ぶものとする。
【００４２】
したがって、データベースクライアント１１から、図３のＳＱＬ文が発行された場合、データベースサーバ２０（サーバプロセス２１）は、顧客データから、各レコードの抽出項目（「顧客登録番号、氏名、性別、年齢、住所、電話番号」）のデータを抽出した検索結果（ＳＱＬ文の処理結果）を展開（例えば、メモリ上に展開）し、その検索結果を、フェッチ数分（１００個のレコード）ずつ、データベースクライアント１１にを送信することになる。また、データベースクライアント１１とデータベースサーバ２０（サーバプロセス２１）との間で、通信セッションが維持されている間は、フェッチした位置（カーソル）は、ミドルウェアで提供される機能により自動的に更新される。以下では、データベースクライアント１１が、データベースサーバ２０（サーバプロセス２１）との間で通信セッションを用いて接続し、フェッチ処理により逐次データ取得する一連の処理（シーケンス）を、「データ取得シーケンス」と呼ぶものとする。データベースクライアント１１とデータベースサーバ２０（サーバプロセス２１）との間の正常時のデータ取得シーケンスについては、種々のＲＤＢＭＳの処理を適用することができるため、詳しい説明は省略する。
【００４３】
そして、ポインタ保持部１１２は、データベース処理部１１１がデータベースサーバ２０からデータをフェッチ処理（フェッチ数分のレコードのデータを取得）する度に最後にフェッチした位置（カーソル位置）をポインタ情報として保持する。具体的には、ポインタ保持部１１２は、データベース処理部１１１が１回のフェッチ処理でフェッチ数分のレコードのデータを取得したときに、当該フェッチ処理で最後に取得したレコード（すなわち、取得したフェッチ数分のレコードのうち、プライマリキーでソートしたときに最後の順序となるレコード）のデータ（少なくともプライマリキーのデータ）を「ポインタ情報」として保持する。
【００４４】
そして、データベース処理部１１１は、フェッチ機能を用いたデータ取得シーケンスにより、データベースサーバ２０−１（サーバプロセス２１）から顧客データの取得中に、通信障害等によりデータ取得シーケンスが中断（通信セッションが切断）した場合には、新たに現用系として動作することになるデータベースサーバ２０−２（サーバプロセス２１）から顧客データの取得を再開することができる。このとき、データベース処理部１１１は、ポインタ保持部１１２に保持されているポインタ情報に基づいて、前回フェッチしたカーソル位置の次のレコードからデータ取得シーケンスを再開するためのＳＱＬ文を作成して、データベースサーバ２０−２（サーバプロセス２１）にデータ取得シーケンスの再開を要求する。言い換えると、このとき、データベース処理部１１１は、データ取得シーケンスが中断した場合、検索結果のうち中断により取得できなかったレコードのデータ送信を依頼するためのＳＱＬ文を生成して、データベースサーバ２０−２（サーバプロセス２１）に送信する
（Ａ−２）実施形態の動作
次に、以上のような構成を有するこの実施形態のネットワークシステム１の動作を説明する。
【００４５】
（Ａ−２−１）データ取得シーケンスの正常動作
まず、通信制御装置１０（データベースクライアント１１）がデータベースサーバ２０−１とのデータ取得シーケンスを正常に完結する場合の動作（特に障害が発生しない場合の正常系の動作）について、図４のシーケンス図を用いて説明する。なお、初期において、通信制御装置１０の顧客データ記憶部１２の内容は初期化された状態（１つもレコードが登録されていない状態）であるものとする。
【００４６】
まず、通信制御装置１０のデータベースクライアント１１が、データベースサーバ２０−１（サーバプロセス２１）に対して、通信セッション(ミドルウェアにより提供される通信セッション)の生成要求を行い、データベースサーバ２０−１（サーバプロセス２１）との間の通信セッションを確立したものとする（Ｓ１０１、Ｓ１０２）。
【００４７】
次に、データベースクライアント１１が、データベースサーバ２０−１（サーバプロセス２１）に対して、上述の図３に示すＳＱＬ文により検索要求（ＳＥＬＥＣＴ文を用いたデータベース処理の要求）を行ったものとする（Ｓ１０３）。なお、このとき、データベースクライアント１１とデータベースサーバ２０−１（サーバプロセス２１）との間の通信セッションにおいて、フェッチ数として１００が設定されているものとする。また、上述の図３に示すように、顧客データの検索要求のプライマリキーは登録顧客番号である。
【００４８】
そして、ＳＱＬ文を受け取ったデータベースサーバ２０−１（サーバプロセス２１）では、ファイルシステム２２の顧客データベースに対して受け取ったＳＱＬ文に基づいた検索処理（ＳＥＬＥＣＴ文を用いたＳＱＬ文の処理）を行い、その検索結果を保持する（Ｓ１０４）。
【００４９】
このとき、データベースサーバ２０−１（サーバプロセス２１）で保持される検索結果をテーブル形式で表すと図５のようになる。図５に示すテーブルでは、各抽出項目のデータを有するレコード（行）が、プライマリキー（顧客登録番号）に基づく順序でソートされた状態となっている。また、図５に示すテーブルでは、顧客登録番号１〜１００００の１００００レコードのデータを有しているものとする。データベースサーバ２０−１（サーバプロセス２１）は、この検索結果のテーブルについて先頭から１００レコードずつデータベースクライアント１１へ送信（フェッチ）する処理を行う。
【００５０】
そして、データベースサーバ２０−１（サーバプロセス２１）は、検索結果から最初の１００レコード（プライマリキーに基づくソート順序が１〜１００番目のレコード）を取得して、データベースクライアント１１に送信する（Ｓ１０５）。
【００５１】
そして、データベースクライアント１１は最初の１００レコードのデータをフェッチ（取得）すると、その１００レコードのデータを処理（顧客データ記憶部１２に追加記録）する（Ｓ１０６）。
【００５２】
また、データベースクライアント１１は最初の１００レコードのデータをフェッチ（取得）すると、フェッチしたレコードうち最後のレコード（プライマリキーのソート順で最後となるレコード）のプライマリキーの値をポインタ保持部１１２に供給して保持させる（Ｓ１０７）。このとき、データベースクライアント１１では、登録番号１〜１００のレコードをフェッチしているので、その最後にあたる登録番号１００をポインタ保持部１１２に供給して保持させる。
【００５３】
次に、データベースクライアント１１は、データベースサーバ２０−１（サーバプロセス２１）に対して次のフェッチ要求（２回目のフェッチ要求）を送信する（Ｓ１０８）。
【００５４】
次のフェッチ要求（２回目のフェッチ要求）を受けると、データベースサーバ２０−１は、検索結果から次の１００レコード（プライマリキーに基づくソート順序が１０１〜２００番目のレコード）を取得して、データベースクライアント１１に送信する（Ｓ１０９）。
【００５５】
そして、データベースクライアント１１は次の１００レコード（プライマリキーに基づくソート順序が１０１〜２００番目のレコード）のデータをフェッチ（取得）すると、その１００レコードのデータを処理（顧客データ記憶部１２に追加記録）し（Ｓ１１０）、さらに、フェッチしたレコードうち最後のレコードのプライマリキーの値（登録顧客番号＝２００）をポインタ保持部１１２に供給して保持させる（Ｓ１１１）。
【００５６】
以後、データベースクライアント１１とデータベースサーバ２０−１との間でデータ取得シーケンスが継続（上述のステップＳ１０８〜Ｓ１１１のフェッチ処理が繰り返し実行）され、データベースクライアント１１が、データベースサーバ２０−１（サーバプロセス２１）に対して、１００回目のフェッチ要求（フェッチ要求）を送信したものとする（Ｓ２０１）。
【００５７】
１００回目のフェッチ要求を受けると、データベースサーバ２０−１は、検索結果から最後の１００レコード（プライマリキーに基づくソート順序が９９０１〜１００００番目のレコード）を取得して、データベースクライアント１１に送信する（Ｓ２０２）。また、データベースサーバ２０−１は、このとき、今回のフェッチで全ての検索結果のレコード送信が完了する旨もデータベースクライアント１１に通知するものとする。
【００５８】
そして、最後の１００レコードのデータのフェッチ（取得）が完了すると、データベースクライアント１１は、その１００レコードのデータを処理（顧客データ記憶部１２に追加記録）し（Ｓ２０３）、さらに、ポインタ保持部１１２のポインタ情報を初期化（破棄）（Ｓ２０４）する。
【００５９】
また、データベースクライアント１１は、最後の１００レコードのデータのフェッチ（取得）が完了すると、データベースサーバ２０−１に対してセッション解放（セッション切断要求）を送信する（Ｓ２０５）。
【００６０】
そして、セッション解放（セッション切断要求）を受けたデータベースサーバ２０−１は、セッション解放を実行し、セッション解放の旨を結果応答として、データベースクライアント１１に返答する（Ｓ２０６）。
【００６１】
データベースクライアント１１におけるデータ取得シーケンスは正常系の場合、以上のようなシーケンスにより行われる。
【００６２】
（Ａ−２−２）データ取得シーケンスの異常系動作
次に、データベースクライアント１１がデータベースサーバ２０−１とデータ取得シーケンスを実行している間に、データベースサーバ２０−１に障害が発生し、データ取得シーケンスが中断した場合の動作について、図６、図７のシーケンス図を用いて説明する。
【００６３】
図６、図７のシーケンス図では、上述の図４のシーケンス図と同様の処理のステップについては同一のステップ番号（符号）を付している。
【００６４】
まず、上述の正常系の動作と同様に、データベースクライアント１１により、データベースサーバ２０−１（サーバプロセス２１）との間でデータ取得シーケンスが開始され、フェッチ処理が開始され（上述のステップＳ１０１〜Ｓ１１１と同様の処理）、継続してフェッチ処理が繰り返されたものとする。
【００６５】
そして、その後、データベースクライアント１１から、データベースサーバ２０−１（サーバプロセス２１）に、５０回目のフェッチ処理を要求して（Ｓ３０１）、フェッチ数分のレコード（１００レコード）のデータを取得し（Ｓ３０２）、顧客データ記憶部１２に追加登録したものとする（Ｓ３０３）。また、このとき、データベースクライアント１１は、フェッチしたレコードうち最後のレコードのプライマリキーの値（登録顧客番号＝５０００）をポインタ保持部１１２に供給して保持させる（Ｓ３０４）。
【００６６】
そして、データベースクライアント１１による５０回目のフェッチ処理が終了した後、次のフェッチ処理が終了する前に、データベースサーバ２０−１に障害が発生し動作を停止したものとする（Ｓ４０１）。
【００６７】
その後、データベースサーバ２０−２が、データベースサーバ２０−１の障害発生を検知し、待機系から現用系（アクティブ系）として動作するように切り替わったものとする（Ｓ４０２）。
【００６８】
その後、データベースクライアント１１により、データベースサーバ２０−１に障害が発生し、データ取得シーケンスが中断したこと、及びデータベースサーバ２０−２が現用系に切り替わったことが認識され、接続先をデータベースサーバ２０−２に切替えたものとする（Ｓ４０３）。
【００６９】
なお、データベースサーバ２０−１からデータベースサーバ２０−２への現用系の切替え、及び、データベースクライアント１１におけるサーバ切替の構成については、種々の冗長化されたデータベースシステムの構成を適用することができるため詳しい説明を省略する。例えば、データベースクライアント１１とデータベースサーバ２０−１との間の通信セッションがＴＣＰにより管理されている場合には、例えば、データベースクライアント１１において、一定時間以上当該通信セッション（ＴＣＰセッション）でパケット送受信ができない場合に通信セッション切断を検知することができる。
【００７０】
次に、データベースクライアント１１は、ポインタ保持部１１２に保持されているポインタ情報（顧客登録番号＝５０００）に基づいて、前回フェッチしたカーソル位置の次のレコードからデータ取得シーケンスを再開するためのＳＱＬ文を作成する（Ｓ４０４）。
【００７１】
具体的には、データベースクライアント１１は、ポインタ保持部１１２に保持されているポインタ情報（顧客登録番号＝５０００）に基づいて、図８に示すＳＱＬ文を生成する。図８に示すＳＱＬ文では、ＳＥＬＥＣＴ文の検索条件として、初期のＳＱＬ文（上述の図３のＳＱＬ文）に、ソート順序がポインタ情報（顧客登録番号＝５０００）以後となるレコードを抽出する検索条件である「ＷＨＥＲＥ  顧客登録番号＞５０００」を追加したＳＱＬ文を生成する。
【００７２】
そして、通信制御装置１０のデータベースクライアント１１は、データベースサーバ２０−２（サーバプロセス２１）に対して、通信セッションの生成要求を行い、データベースサーバ２０−２（サーバプロセス２１）との間のセッションを確立する（Ｓ４０５、Ｓ４０６）。
【００７３】
次に、データベースクライアント１１が、データベースサーバ２０−２（サーバプロセス２１）に対して、上述のステップＳ４０４で生成したＳＱＬ文（上述の図８）により検索要求を行う（Ｓ４０７）。
【００７４】
そして、ＳＱＬ文を受け取ったデータベースサーバ２０−２（サーバプロセス２１）では、ファイルシステム２２の顧客データベースから受け取ったＳＱＬ文に基づいた検索処理を行い、その検索結果を保持する（Ｓ４０８）。
【００７５】
このとき、データベースサーバ２０−２（サーバプロセス２１）で保持される検索結果例をテーブル形式で表すと図９のようになる。このとき、データベースサーバ２０−２（サーバプロセス２１）で保持される検索結果は、図９に示すように顧客登録番号５００１〜１００００の５０００レコードのデータで構成されることになる。データベースサーバ２０−２（サーバプロセス２１）は、この検索結果のテーブルについて１００レコードずつデータベースクライアント１１へ送信（フェッチ）する処理を、あと５０回行うことになる。
【００７６】
そして、データベースサーバ２０−２（サーバプロセス２１）は、検索結果から最初の１００レコード（プライマリキーに基づくソート順序が１〜１００番目のレコード、顧客登録番号が５００１〜５１００のレコード）を取得して、データベースクライアント１１に送信する（Ｓ４０９）。
【００７７】
そして、データベースクライアント１１は、１００レコードのデータをフェッチ（取得）すると、その１００レコードのデータを処理（顧客データ記憶部１２に追加記録）し（Ｓ４１０）、さらに、今回フェッチしたレコードうち最後のレコードのプライマリキーの値（登録顧客番号＝５１００）を、ポインタ情報としてポインタ保持部１１２に供給して保持させる（Ｓ４１１）。
【００７８】
そして、その後、データベースクライアント１１は、データベースサーバ２０−２（サーバプロセス２１）に、再開後の２回目のフェッチ処理を要求して（Ｓ４１２）、フェッチ数分のレコード（顧客登録番が５１０１〜５２００の１００レコード）のデータを取得し（Ｓ４１３）、顧客データ記憶部１２に追加登録したものとする（Ｓ４１４）。また、このとき、データベースクライアント１１は、今回フェッチしたレコードうち最後のレコードのプライマリキーの値（登録顧客番号＝５２００）を、ポインタ情報としてポインタ保持部１１２に供給して保持させる（Ｓ４１５）。
【００７９】
以後データベースクライアント１１とデータベースサーバ２０−２との間でデータ取得シーケンスが継続（上述のステップＳ４１１〜Ｓ４１５の処理が繰り返し実行）され、データベースクライアント１１が、データベースサーバ２０−２（サーバプロセス２１）に対して、再開後５０回目のフェッチ要求（フェッチ要求）を送信したものとする（Ｓ５０１）。
【００８０】
再開後５０回目のフェッチ要求を受けると、データベースサーバ２０−２は、検索結果から最後の１００レコード（プライマリキーに基づくソート順序が９９０１〜１００００番目のレコード）を取得して、データベースクライアント１１に送信する（Ｓ５０２）。
【００８１】
そして、データベースクライアント１１は、最後の１００レコードのデータのフェッチ（取得）が完了すると、その１００レコードのデータを処理（顧客データ記憶部１２に追加記録）し（Ｓ５０３）、さらに、ポインタ保持部１１２のポインタ情報を初期化（破棄）（Ｓ５０４）する。
【００８２】
また、データベースクライアント１１は、最後の１００レコードのデータのフェッチ（取得）が完了すると、データベースサーバ２０−２に対してセッション解放（セッション切断要求）を送信する（Ｓ５０５）。
【００８３】
そして、セッション解放（セッション切断要求）を受けたデータベースサーバ２０−２は、セッション解放を実行し、セッション解放の旨を結果応答として、データベースクライアント１１に返答する（Ｓ５０６）。
【００８４】
（Ａ−２−３）プライマリキーが複数の項目で構成される場合
上述の例では、通信制御装置１０（データベースクライアント１１）が、顧客データを取得する順序を決定するためのプライマリキーは、１つの項目（顧客登録番号）のみを用いているが、実際に加入者データを処理する際にはプライマリキーに複数項目が適用される場合もあり得る。
【００８５】
以下では、プライマリキーが２つ以上の項目で構成される場合のネットワークシステム１の動作例について説明する。
【００８６】
例えば、顧客データ中に、同一世帯となるユーザのレコードが存在している場合を考えると、その世帯は、住所、及び、電話番号（固定電話の場合）が同一となると考えられる。そして、顧客データの各レコードを、世帯ごとにソートした検索結果を得るためのＳＱＬ文例は図１０のようになる。
【００８７】
図１０に示すＳＱＬ文では、「ＯＲＤＥＲ  ＢＹ  住所、電話番号、氏名」と記述し、３つのプライマリキーを「住所、電話番号、氏名」の順で適用する旨が記載されている。ただし、ここでは、説明を簡易とするため、顧客データの同一世帯中に同姓同名（氏名文字列が全くの同一）のユーザのレコードが存在しないことと仮定する。
【００８８】
そして、データベースクライアント１１から、図１０に示すＳＱＬ文を用いたデータ検索要求が、データベースサーバ２０に供給されると、データベースサーバ２０では、図１１に示すような検索結果例が得られるものとする。
【００８９】
この例によれば、ＳＱＬ文の条件となる「ＯＲＤＥＲ  ＢＹ  住所、電話番号、氏名」は、「住所による昇順ソート且つ、電話番号によるソート、且つ、氏名によるソート」である。したがって、図１１のような検索結果が得られた場合、顧客番号００００２のレコードと顧客番号００８００のレコードは、住所と電話番号が一致するため、同一世帯とみなすことができる。また、図１１のような検索が得られた場合顧客登録番号００００１のレコードのユーザと、顧客登録番号００００３のレコードのユーザについても同一世帯とみなすことができる。
【００９０】
そして、データベースクライアント１１において、図１０に示すＳＱＬ文でデータ取得シーケンス（フェッチ処理の繰り返し処理）を行う場合、フェッチ数分のレコードをフェッチするごとに、当該フェッチで最後に取得したレコードのプライマリキーのデータ（すなわち、住所、電話番号、及び氏名の項目のデータ）を「ポインタ情報」として保持する。
【００９１】
ここで、仮に、データベースクライアント１１（ポインタ保持部１１２）で保持したポインタ情報が、「住所＝×××××」、「電話番号=  ｎｎｎｎｎｎｎｎｎｎ」、「氏名＝ＺＺＺＺ」という内容であった場合を想定する。
【００９２】
この場合、データベースクライアント１１がデータ取得シーケンス再開後にポインタ情報に基づいて生成するＳＱＬ文を図１２に示す。
【００９３】
データベースクライアント１１は、データ取得シーケンスを再開すると、まず、図１２（ａ）に示すように、検索条件に「ＷＨＥＲＥ  住所＝×××××  AND  電話番号=  ｎｎｎｎｎｎｎｎｎｎ  氏名  ＞  ＺＺＺＺ」という条件を加えたＳＱＬ文を生成して、データ取得シーケンスを実行する（検索結果がなくなるまでデータベースサーバ２０からフェッチする処理を繰り返す）。
【００９４】
次に、データベースクライアント１１は、図１２（ｂ）に示すように、検索条件に「ＷＨＥＲＥ  住所＝×××××  AND  電話番号  >  ｎｎｎｎｎｎｎｎｎｎ」という条件を加えたＳＱＬ文を生成して、データ取得シーケンスを実行する。
【００９５】
最後に、データベースクライアント１１は、図１２（ｃ）に示すように、検索条件に「ＷＨＥＲＥ  住所  ＞  ×××××」という条件を加えたＳＱＬ文を生成して、データ取得シーケンスを実行する。
【００９６】
この例では、上述の通り、プライマリキーが「住所、電話番号、氏名」の順序で複数の項目で構成されているため、データベースクライアント１１は、データ取得シーケンス再開後に、上述の３つのＳＱＬ文を実行することにより、正常動作した場合の検索結果（上述の図１０のＳＱＬ文の検索結果）と同様の検索結果を顧客データ記憶部１２に保持することができる。
【００９７】
例えば、データベースクライアント１１において、フェッチ数を「１」として、上述の図１０のＳＱＬ文によりデータ取得シーケンスを行った場合の例について説明する。この場合、図１０のＳＱＬ文で取得される検索結果は、同様に図１１の内容となる。このとき、データベースクライアント１１において、検索結果のうち顧客登録番号「００００１」番までフェッチが実施された後に障害が発生し、データ取得シーケンスが中断したものとする。このとき、ポインタ保持部１１２には、ポインタ情報として、「住所＝東京都Ａ区Ｂ町１−１−１、電話番号＝０３−１１１１−１１１１、氏名＝佐藤  太郎」という情報が保持される。
【００９８】
そしてこの場合、検索結果には、顧客登録番号「００００１」と同一世帯のデータが存在する可能性があるため、データベースクライアント１１が継続的な検索を実施する際には、まず、「住所が同一、且つ、電話番号が同一であり、氏名の文字列がソート上、顧客番号００００１の氏名より順序が後となる」データの検索（上述の図１２（ａ）のＳＱＬ文による検索）を実施する必要がある。この時、該当するレコード（同一世帯の他のユーザのレコード）が存在する場合、データベースクライアント１１は、そのレコードのデータを継続検索処理上、最初にフェッチして、顧客データ記憶部１２に追加しなければ、「世帯単位に検索する」仕様に反することになるためである。
【００９９】
なお、通常データベース上の検索では、文字列の比較については、登録の文字列をバイナリコードとして扱い、その値の昇順（または、降順）によりソートされるため、単純な数値の比較とは検索方式が異なる。データベースサーバ２０における文字列の具体的な比較方式については限定されないものであり、種々のコード体系に基づく方式を適用することができる。
【０１００】
再開後１回目の条件による検索（上述の図１２（ａ）のＳＱＬ文による検索）にて、データ取得シーケンスが終了した場合（「全てのレコードのデータ取得」、または、「該当レコードなし」となった場合）、データベースクライアント１１は、次に、「住所が同一、且つ、電話番号が障害発生時の最終フェッチデータの電話番号（＝０３−１１１１−１１１１）よりも検索順序が後にある」レコードを検索（上述の図１２（ｂ）のＳＱＬ文による検索））する必要がある。再開後２回目の条件による検索（上述の図１２（ｂ）のＳＱＬ文による検索）は、同一世帯において、例えば、顧客データ登録時の電話番号が、携帯電話の番号であった場合などが考えられるために必要な処理である。
【０１０１】
そして、再開後２回目の条件による検索（上述の図１２（ｂ）のＳＱＬ文による検索）にて、データ取得シーケンスが終了した場合、データベースクライアント１１は、同一世帯の未取得データを全て取得できたことになり、次の検索は、本来の生成リスト上の次の世帯以降のデータ検索となるため、「ポインタ情報の住所（＝東京都Ａ区Ｂ町１−１−１）以後の検索順序」のレコードを検索（上述の図１２（ｃ）のＳＱＬ文による検索））する必要がある。
【０１０２】
結果として、データベースクライアント１１は、データ取得シーケンス再開後に、上述の３つのＳＱＬ文による検索処理（データ取得シーケンス）を順に実行し、顧客データ記憶部１２にその検索結果を追加する処理（上述の図６、図７等と同様の処理）を行うことにより、中断する前に取得したデータを併せて、正常動作時と同等の結果を得られる事になる。
【０１０３】
上述の具体例に基づいて、データベースクライアント１１がデータ取得シーケンス再開時に生成するＳＱＬ文の検索条件（ＷＨＥＲＥ以後の記述）を一般化した表現で図示すると、図１３のようになる。
【０１０４】
図１３（ａ）は、ｎ個のプライマリキーのカラム（項目）をそれぞれ「Ｃ１、Ｃ２、…、Ｃｎ−２、Ｃｎ−１、Ｃｎ」とした場合のポインタ情報を示している。なお、図１３（ａ）では、ｎ個のカラム「Ｃ１、Ｃ２、…、Ｃｎ−２、Ｃｎ−１、Ｃｎ」のそれぞれについてポインタ保持部１１２が保持したポインタ情報を「Ｖ１、Ｖ２、…、Ｖｎ−２、Ｖｎ−１、Ｖｎ」と図示している。例えば、上述の図１０の例のようにプライマリキーが、「住所、電話番号、氏名」の場合、カラムＣ１（Ｖ１）が「住所」、カラムＣ２（Ｖ２）が「電話番号」、カラムＣ３（Ｖ３）が「氏名」となり、さらに、カラム数ｎ＝３となる。
【０１０５】
そして、図１３の一般化した例において、データベースクライアント１１がデータ取得シーケンスを再開したとき生成するｎ個のＳＱＬ文の検索条件（ＷＨＥＲＥ以後の記述）は、それぞれ図１３（ｂ）の内容となる。
【０１０６】
図１３（ｂ）において、データ取得シーケンス再開後の１回目の検索条件では、カラムＣ１〜Ｃｎ−１については、ポインタ情報の値（Ｖ１〜Ｖｎ−１）とイコール条件「＝」としてＷＨＥＲＥ句に付与し、さらに、カラムＣｎについては、ポインタ情報の値Ｖｎに対して＞（大なり）の条件としてＷＨＥＲＥ句に付与している。
【０１０７】
また、図１３（ｂ）において、データ取得シーケンス再開後の２回目の検索条件では、カラムＣ１〜Ｃｎ−２については、ポインタ情報の値（Ｖ１〜Ｖｎ−２）とイコール条件「＝」としてＷＨＥＲＥ句に付与し、カラムＣｎ−１については、ポインタ情報の値Ｖｎ−１に対して「＞」（大なり）の条件としてＷＨＥＲＥ句に付与している。
【０１０８】
データベースクライアント１１は、以上のような付与論理での検索条件の生成を繰り返す。
【０１０９】
そして、図１３（ｂ）に示すように、データ取得シーケンス再開後のｎ−１回目の検索条件では、カラムＣ１については、ポインタ情報の値（Ｖ１）とイコール条件「＝」としてＷＨＥＲＥ句に付与し、カラムＣ２については、ポインタ情報の値Ｖ２に対して「＞」（大なり）の条件としてＷＨＥＲＥ句に付与している。
【０１１０】
さらにまた、図１３（ｂ）に示すように、データ取得シーケンス再開後のｎ回目の検索条件では、カラムＣ１について、ポインタ情報の値Ｖ１に対して「＞」（大なり）の条件としてＷＨＥＲＥ句に付与している。
【０１１１】
プライマリキーの構成が変わった場合でも、データベースクライアント１１（データベース処理部１１１）は、図１３に示す順序で検索条件を設定したＳＱＬ文を生成し、それぞれのＳＱＬ文を用いてデータ取得シーケンスを実行することができる。
【０１１２】
通常ＳＥＬＥＣＴコマンドの「ＯＲＤＥＲ  ＢＹ」の句では、ソートに用いるカラム（項目）が優先度の高いものから順に記述される。例えば、上述の図１０の例では「ＯＲＤＥＲ  ＢＹ」の後に「住所、電話番号、氏名」と記述されているため、プライマリキーの中でも「住所」が最も優先度の高いカラム（項目）として設定されている。これは、顧客データ（加入者データ）の中で世帯を分類するキー（カラム）として、住所が最も重要だからである。そのため、上述の図１２の例では、データベースクライアント１１は、データシーケンス再開後１回目の検索条件のＳＱＬ文と、２回目の検索条件のＳＱＬ文で、住所（世帯）が同じユーザのレコードを検索した後、３回目の検索条件のＳＱＬ文で当該住所（世帯）よりも検索順序が後となるレコードを検索処理している。同様の処理を図１３の一般化した例で説明すると、データベースクライアント１１は、データ取得シーケンス再開後１回目〜ｎ−１回目の検索条件のＳＱＬ文で、最も優先度の高いカラムＣ１＝Ｖ１（ポインタ情報の値と同一）で未取得のレコード（まだフェッチしていないレコード）の検索処理を実行し、ｎ回目の検索条件のＳＱＬ文で、カラムＣ１がＶ１以後の検索順序となるレコードの検索処理を行っていることになる。
【０１１３】
なお、図１２、図１３に示すＳＱＬ文はあくまで、上述の処理の具体例であり、利用するミドルウェア（データベースアプリケーション）の仕様に沿って同様の処理が可能であれば、別の記述内容であってもよい。
【０１１４】
（Ａ−３）実施形態の効果
この実施形態によれば、以下のような効果を奏することができる。
【０１１５】
データベースクライアント１１は、データ取得シーケンスが中断した場合、検索結果のうち中断により取得できなかったレコードのデータ送信を依頼するためのＳＱＬ文を生成して、データベースサーバ２０−２（サーバプロセス２１）に送信し、データ取得シーケンスを再開している。これにより、データベースクライアント１１では、データ取得シーケンスの中断前に取得した検索結果と、データ取得シーケンス再開後に取得した検索結果を合わせて、正常動作時と同等の結果を得られる事になる。したがって、データベースクライアント１１では、データ取得シーケンスで、全ての検索結果についてデータ取得が完了するまでの間に、中断が複数回発生した場合でも、その都度、検索条件を変更（ＳＱＬ文にポインタ保持部１１２が保持するポインタ情報に基づく検索条件を設定）するだけで、継続的なデータ取得シーケンスが可能となる。すなわち、データベースクライアント１１では、データ取得シーケンスに中断が発生した場合、その中断による遅延時間は、データ取得シーケンスを再開する動作（データベースサーバとの通信セッションの確立や新たなＳＱＬ文の生成送信処理等）を行う時間しか発生しないため、従来よりも短くすることができる。
【０１１６】
特に、通信キャリアの通信制御装置（ＳＩＰサーバ等）で用いられる顧客データ（加入者データ）の登録レコード数は膨大な数となるため、従来技術では、例えば百万件単位のレコード登録についてデータ取得シーケンスを最初から行う場合の遅延時間も非常に長い時間となるおそれがある。また、通信キャリアの通信制御装置では、顧客データが揃わない状態でサービス開始することは困難であるため、データ取得シーケンスの遅延が、キャリアサービスに影響を与える場合もあり得る。そのため、本発明のデータベースクライアント（データ処理装置、データ処理プログラム）を通信キャリアの通信制御装置に用いる場合、より大きな効果を奏することができる。
【０１１７】
（Ｂ）他の実施形態
本発明は、上記の実施形態に限定されるものではなく、以下に例示するような変形実施形態も挙げることができる。
【０１１８】
（Ｂ−１）上記の実施形態では、説明を簡易とするために、データベースクライアント１１のデータ取得シーケンスで用いるＳＱＬ文に付与する初期の検索条件（初期のＷＨＥＲＥ句）は無い例について説明したが、任意の検索条件を初期から付与してもよい。
【０１１９】
また、本方式を適用した検索条件においては、データ検索範囲を絞り込むためのＷＨＥＲＥ句は任意に付与してよく、適用条件として付与するソート条件項目は、任意に付与されたＷＨＥＲＥ句カラムによって、絞り込まれたデータ範囲内において、一意性が得られる為の項目となる。
【０１２０】
図１４は、データベースクライアント１１がデータ取得シーケンスに用いるＳＱＬ文（初期から検索条件が付与されているＳＱＬ文）の例について示した説明図である。
【０１２１】
図１４（ａ）は、データ取得シーケンスの初期のＳＱＬ文を示している。また、図１４（ｂ）は、データ取得シーケンス再開時のＳＱＬ文を示している。なお、図１４ではプライマリキーは「顧客登録番号」だけとなっている。
【０１２２】
図１４（ａ）では、例として、ＷＨＥＲＥ句に、「男性で、年齢が３０歳以上、東京都在住」という条件で検索するための検索条件として「ＷＨＥＲＥ  性別＝男  ＡＮＤ  年齢＞＝３０  ＡＮＤ  住所  ＬＩＫＥ  東京都」が付与されている。
【０１２３】
そして、データベースクライアント１１が図１４（ａ）のＳＱＬ文を用いてデータ取得シーケンスを実行中に中断が発生し、再開する場合には、図１４（ｂ）に示すように、「ＷＨＥＲＥ  性別＝男  ＡＮＤ  年齢＞＝３０  ＡＮＤ  住所ＬＩＫＥ  東京都  ＡＮＤ  顧客登録番号＞ｎｎｎｎ」という検索条件を付与したＳＱＬ文を用いることができる。なお、図１４（ｂ）のＳＱＬ文における「ｎｎｎｎ」は、ポインタ保持部１１２に保持されているポインタ情報の値（プライマリキー「顧客登録番号」の値）である。
【０１２４】
（Ｂ−２）上記の実施形態では、本発明のデータベースクライアント（データ処理装置、データ処理プログラム）を、通信制御装置の顧客データ（加入者データ）の処理に適用したが、本発明のデータベースクライアント（データ処理装置、データ処理プログラム）の利用用途は限定されないものであり、「データベースから特定の条件において検索を実施し、その結果を、複数回のフェッチにより取得する」全てのシステムにおいて適用が可能である。
【０１２５】
（Ｂ−３）上記の各実施形態では、データベースクライアント１１がデータベースサーバ２０からフェッチしたデータについて、顧客データ記憶部１２に追加記録する処理のみを行っているが、フェッチしたデータについて種々の加工処理（例えば、データの表示形式や内容を変換する処理）を行うようにしてもよい。その場合、本発明のデータベースクライアント１１では、データ取得シーケンスで中断が発生した場合の遅延時間短縮の効果はより大きなものとなる。
【０１２６】
（Ｂ−４）上記の実施形態ではデータベースサーバは冗長化されている構成として説明したが、データベースサーバは冗長化されていなくてもよい。その場合、データベースクライアントは、データ取得シーケンスが中断した場合、データベースサーバのサービス復旧後（例えば、通信障害等の復旧後）に、同じデータベースサーバとデータ取得シーケンスを再開することになる。
【符号の説明】
【０１２７】
１…ネットワークシステム、１０…ＳＩＰサーバ、２０、２０−１、２０−２…データベースサーバ、２１…サーバプロセス、２２…ファイルシステム、１０…通信制御装置、１１…データベースクライアント、１１１…データベース処理部、１１２…ポインタ保持部、…顧客デ憶部、１３…通信処理部、３０…通信装置、Ｎ１、Ｎ２、Ｎ３…ネットワーク。
【図１】
2015022554.tif 000003
【図２】
2015022554.tif 000004
【図３】
2015022554.tif 000005
【図４】
2015022554.tif 000006
【図５】
2015022554.tif 000007
【図６】
2015022554.tif 000008
【図７】
2015022554.tif 000009
【図８】
2015022554.tif 000010
【図９】
2015022554.tif 000011
【図１０】
2015022554.tif 000012
【図１１】
2015022554.tif 000013
【図１２】
2015022554.tif 000014
【図１３】
2015022554.tif 000015
【図１４】
2015022554.tif 000016