JPH1097449A

JPH1097449A - 多値局所化ストリング

Info

Publication number: JPH1097449A
Application number: JP9112058A
Authority: JP
Inventors: Mark J Finger; ジェイフィンガーマーク
Original assignee: Informix Software Inc
Current assignee: Informix Software Inc
Priority date: 1996-04-29
Filing date: 1997-04-30
Publication date: 1998-04-14
Also published as: EP0805407A2; US5812964A; AU711392B2; CA2203471A1; MX9703123A; AU1906897A; BR9701960A; EP0805407A3

Abstract

(57)【要約】（修正有）【課題】データ項目をユーザプログラム及びソースプ
ログラムに使用できる方法の提供。【解決手段】ユーザ及びソースプログラムがデータ項
目にアクセスするユーザ及びソースインターフェイスを
用意し、ユーザ及びソースのローカル性を与え、データ
項目を記憶するユーザ及びソースバッファを用意し、ユ
ーザバッファ及びソースバッファの内容の状態メモリを
維持し、新たなデータがユーザバッファに記憶されると
きにソースバッファの状態を非カレントにそしてユーザ
バッファをカレントにセットし、新たなデータがソース
バッファに記憶されるときにユーザバッファの状態を非
カレントにそしてソースバッファをカレントにセットす
る。ユーザバッファの状態がカレントの場合はユーザバ
ッファの内容を読み取り、非カレントの場合はソースバ
ッファの内容をソースのローカル性からユーザのローカ
ル性へ変換してその変換された内容をユーザバッファに
記憶する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、一般に、異なる地
方で異なる表現をもつテキスト、日付及び通貨のような
データの取り扱いに係る。

【０００２】

【従来の技術】コンピュータプログラムは、使用プログ
ラム又はユーザプログラムとは異なるソース及び／又は
文字、表現、分類、日時、通貨、番号、等々に対し国又
は言語に特有の慣習で互いに異なるソースにより与えら
れたデータを使用する。使用プログラム及びそのデータ
ソースは、１つのコンピュータにあってもよいし、又は
多数のコンピュータに分散されてもよい。このような分
散の一般的な例として、クライエント／サーバアーキテ
クチャーで実施されている拡張スプレッドシートプログ
ラム及びデータベースが含まれ、この場合、クライエン
トは、ユーザ又はアプリケーションプログラムであり、
そしてサーバ（１つ又は複数）は、ソースであると共
に、データの行先のこともある。

【０００３】クライエント／サーバの実施について考え
ると、異なるサーバ間及びサーバとクライエントとの間
でデータの表現の仕方が相違すると、異なるソースから
のデータを使用したり統合したりするのが困難になる。
このような問題は、データ自体について生じると共に、
名前、例えば、データへのアクセスを得るのに使用され
るデータベースのフィールド名についても生じる。

【０００４】これらの相違は、キャラクタセットの相違
として最も頻繁に生じる。例えば、中国語をサポートす
る台湾のＵＮＩＸシステムは、通常、約５９，０００文
字のキャラクタセットを有する。又、中国語をサポート
する台湾のマイクロソフトウインドウズシステムは、通
常は、その文字数の半分以下のキャラクタセットしか有
していない。ＵＮＩＸシステムのデータベースサーバか
らのフィールド名を例えばマイクロソフトウインドウズ
システムで表すべき場合には、幾つかの文字が変換にお
いて失われる。これらの変換不能な文字は、ウインドウ
ズアプリケーションに四角形又は他のデフォールト文字
として現れる。フィールド名をデータベースサーバに変
換して戻した場合は、データベースサーバがデフォール
ト文字を明確に分析することができず、従って、フィー
ルド文字はもはや確認することができない。

【０００５】同様の問題が照合（分類順序）でも生じ
る。というのは、ストリングを分類するルールがキャラ
クタセットで異なるからである。例えば、あるキャラク
タセッ

【０００６】

【外１】をＮの後に）配置するが、別のキャラクタセットは、ア
クセントのある文字をア

【０００７】

【外２】

【０００８】

【発明の構成】一般に、本発明は、その１つの観点にお
いて、データを記憶するためのユーザバッファ、ユーザ
のローカル性を表すユーザローカル性情報、データを記
憶するためのソースバッファ、ソースのローカル性を表
すソースローカル性情報、及びユーザバッファ及びソー
スバッファに記憶されたデータの状態を指示するための
状態フラグをコンピュータがメモリに維持するようにさ
せる命令と；新たなデータがユーザバッファに記憶され
るときにソースデータが非カレントでありそしてユーザ
データがカレントであることを指示するために状態フラ
グをセットする命令と；新たなデータがソースバッファ
に記憶されるときにユーザデータが非カレントでありそ
してソースデータがカレントであることを指示するため
に状態フラグをセットする命令と；ユーザローカル性情
報及びソースローカル性情報を用いて、ソースデータが
カレントでそしてユーザデータが非カレントである場合
にソースバッファのデータを変換しそしてその変換され
たデータをユーザバッファに記憶し、次いで、ユーザデ
ータ及びソースデータの両方がカレントであることを指
示するために状態フラグをセットする命令と；ユーザロ
ーカル性情報及びソースローカル性情報を用いて、ユー
ザデータがカレントでそしてソースデータが非カレント
である場合にユーザバッファのデータを変換しそしてそ
の変換されたデータをソースバッファに記憶し、次い
で、ソースデータ及びユーザデータの両方がカレントで
あることを指示するために状態フラグをセットする命令
と；ソースバッファ及びユーザバッファの両方をデータ
項目のインスタンスとして同時に維持する命令とを有す
るプログラムされたコンピュータ読み取り可能な媒体を
特徴とする。

【０００９】本発明は、その実施形態において、次のよ
うな特徴を含む。上記命令は、データを記憶するための
第２のバッファ、第２のローカル性を表す第２のローカ
ル性情報、及び第２のバッファに記憶されたデータの状
態を指示するための状態フラグをコンピュータがメモリ
に維持するようにする命令も含む。又、上記命令は、デ
ータに対するユーザ側インターフェイスを形成するため
にコンピュータプログラムルーチンの第１セットを与
え；データに対するソース側インターフェイスを形成す
るためにコンピュータプログラムルーチンの第２セット
を与え；データ項目を読み取る要求に応答し、その要求
がユーザ側インターフェイスからのユーザ側要求である
場合にはユーザバッファから読み取りを行い、そしてそ
の要求がソース側インターフェイスからのソース側要求
である場合にはソースバッファから読み取りを行い；そ
の要求がユーザ側要求であって且つユーザデータが非カ
レントである場合にはソースバッファのデータを変換し
てユーザバッファに記憶させ；そしてその要求がソース
側要求であって且つソースデータが非カレントである場
合にはユーザバッファのデータを変換してソースバッフ
ァに記憶させるようにコンピュータに行わせる命令も含
む。

【００１０】一般的に、本発明は、その別の観点におい
て、データ項目をユーザプログラム及びソースプログラ
ムに使用できるようにするためのコンピュータで実施さ
れる方法を特徴とする。この方法は、ユーザプログラム
が読み取り又は書き込みのためにデータ項目へのアクセ
スを得るためのユーザインターフェイスを用意し；ソー
スプログラムが読み取り又は書き込みのためにデータ項
目へのアクセスを得るためのソースインターフェイスを
用意し；ユーザのローカル性を与え；ソースのローカル
性を与え；データ項目を記憶するためのユーザバッファ
を用意し；データ項目を記憶するためのソースバッファ
を用意し；ユーザバッファ内容及びソースバッファ内容
の状態を記憶するように状態メモリを維持し；新たなデ
ータがユーザインターフェイスを経てユーザバッファに
記憶されるときにソースバッファの状態を非カレントに
そしてユーザバッファの状態をカレントにセットし；新
たなデータがソースインターフェイスを経てソースバッ
ファに記憶されるときにユーザバッファの状態を非カレ
ントにそしてソースバッファの状態をカレントにセット
し；ユーザバッファの状態がカレントである場合にユー
ザバッファの内容を読み取り、そしてユーザバッファの
状態が非カレントである場合にはソースバッファの内容
をソースのローカル性からユーザのローカル性へ変換し
てその変換された内容をユーザバッファが読み取られる
前にユーザバッファに記憶することにより、データ項目
を読み取るためのユーザインターフェイスからの要求を
満足し；そしてソースバッファの状態がカレントである
場合にソースバッファの内容を読み取り、そしてソース
バッファの状態が非カレントである場合にはユーザバッ
ファの内容をユーザのローカル性からソースのローカル
性へ変換してその変換された内容をソースバッファが読
み取られる前にソースバッファに記憶することにより、
データ項目を読み取るためのソースインターフェイスか
らの要求を満足するという段階を備えている。

【００１１】本発明の実施は次の特徴を含む。上記方法
において、ソースプログラムはサーバであり、そしてユ
ーザプログラムはサーバに対するクライエントである。
上記方法において、ソースプログラムは、データベース
を管理するデータベースサーバ及びデータベースへのア
クセス要求を取り扱うデータベースエンジンであっても
よい。上記方法において、データベースは、データベー
スエンジンを含む関係（リレーショナル）データベース
マネージメントシステムにより管理される関係データベ
ースであってもよい。上記方法において、データ項目
は、データベースの記録のフィールド名であってもよ
い。上記方法において、データ項目のローカル性は、デ
ータソースにおいてデータベースのフィールドに対して
定められたローカル性であってもよい。上記方法におい
て、データ項目のローカル性は、データソースにおいて
データベースに対して定められたローカル性であっても
よい。上記方法において、データ項目のローカル性は、
データソースに対して定められたローカル性である。上
記方法において、データソースは、分散したオブジェク
トの集合であってもよく、そしてデータ項目は、分散し
たオブジェクトの１つにあってもよい。上記方法におい
て、データ項目は、ＯＬＥオブジェクトであってもよ
い。

【００１２】又、本発明は、その実施形態において、第
２のプログラムが読み取り又は書き込みのためにデータ
項目へのアクセスを得るための第２のインターフェイス
を用意し；第２のローカル性を与え；データ項目を記憶
するための第２のバッファを用意し；第２のバッファ内
容の状態を記憶するように状態メモリを維持し；新たな
データがユーザインターフェイスを経てユーザバッファ
に記憶されるか又はソースインターフェイスを経てソー
スバッファに記憶されるときは第２バッファの状態を非
カレントにセットし；新たなデータが第２インターフェ
イスを経て第２バッファに記憶されるときはユーザバッ
ファの状態を非カレントに、ソースバッファを非カレン
トに、そして第２バッファをカレントにセットし；そし
てソースバッファの状態がカレントである場合は第２バ
ッファの内容を読み取り、そして第２バッファの状態が
非カレントである場合はユーザバッファの内容をユーザ
のローカル性から又はソースバッファの内容をソースの
ローカル性から第２のローカル性へ変換し、この変換さ
れた内容を第２バッファが読み取られる前に第２バッフ
ァに記憶することにより、データ項目を読み取るための
第２インターフェイスからの要求を満足するという段階
を備えている。

【００１３】本発明の効果は、とりわけ次の通りであ
る。本発明は、別のキャラクタセットを用いるもののよ
うな異なるローカル性をもつプログラム及びシステム間
を適合できるようにする。本発明は、例えば、更新状態
において文字が失われるという問題を低減する。又、本
発明は、融通性のあるデータ操作を可能にする。

【００１４】

【発明の実施の形態】以下、添付図面を参照し、本発明
の好ましい実施形態を詳細に説明する。図１を参照すれ
ば、コンピュータ８０上で実行されるユーザプログラム
１０２は、中間要素を介してデータベース１１２と通信
する。特に、ユーザプログラム１０２は、ユーザ側イン
ターフェイス１４２を経てクライエント側インターフェ
イスサービスを与える多値ストリングクラスで実施され
るクライエントプロセスと通信する。コンピュータ８０
は、データベースエンジン１１０及びデータベースイン
ターフェイス１６０を経てデータベース１１２と通信す
る。

【００１５】データベース１１２から記録が要求される
と、データベースエンジン１１０によりデータベースか
ら記録が検索される。通常、接続層１０８が存在し、デ
ータベースエンジン１１０及びコンピュータ８０は、こ
の接続層１０８を経て通信する。例えば、オンラインワ
ークグループサーバｖ．７．１２データベースエンジン
では、インフォーミックスＩ／コネクトランタイムライ
ブラリーであるデータベースが、インフォーミックスリ
レーショナルオブジェクトマネージャーｖ．１．０のよ
うなアプリケーションプログラムと通信することがで
き、これらは全てカリフォルニア州、メンロパークのイ
ンフォーミックスソフトウェア社から入手できるもので
ある。

【００１６】図２を参照すれば、ストリングであるデー
タ項目を有する記録がデータベースから読み取られる
（ステップ２０２）。説明を簡単化するため、記録は、
タイプキャラクタストリングの単一データ項目を有する
ものと仮定する。ストリングデータは、最初に、データ
ベースストリングバッファ１１６に記憶され（ステップ
２０４）、そしてデータベースフラグ「カレント」が
「真」にセットされる（ステップ２０６）。データベー
スのストリングバッファ１１６は、多値局所化ストリン
グバッファの一部分である２つのバッファの一方であ
る。他方のバッファはユーザストリングバッファ１１４
である。データベースフラグカレント及びユーザフラグ
カレントは、「フラグ」１９０として記憶される。

【００１７】図３を参照すれば、ユーザ又はクライエン
トがデータを要求するときは（ステップ２０１）、クラ
イエント又はユーザ側インターフェイス１４２を経て行
い、これは、データベースストリングバッファ１１６か
らではなくユーザストリングバッファ１１４からデータ
を得る。ユーザストリングバッファ１１４の内容は、ユ
ーザフラグ「カレント」が「真」の場合に返送される
（ステップ２０９）。

【００１８】例えば、編集動作中に、データベース項目
をユーザ１０２に与えるべき場合には、以下に述べるよ
うに、ストリングが変換される（ステップ２１２）。

【００１９】コンバータ１１８は、データベースストリ
ングを、データベースにおけるその形態から、ユーザ１
０２に適した形態へと変換する。通常、これは、簡単な
キャラクタセット変換である。この変換は、使用及びデ
ータ項目の両方のローカル性に基づく。「ローカル性(l
ocale)」とは、文字、分類、日時、通貨、番号等に対す
る国又は言語に特有の慣習に関する情報の集合を意味す
る。データ項目のローカル性は、一般に、その発生ソー
ス、データベース又はデータベースサーバのローカル性
であるが、データベースのフィールドに特定に関連して
いてもよく、例えば、関係データベースにおいては、ロ
ーカル性がカラムに関連している。データベースのロー
カル性情報は、データベースのローカル性バッファ１２
４に記憶され、そしてユーザのローカル性情報は、ユー
ザのローカル性バッファ１２０に記憶される。ユーザの
ローカル性情報は、例えば、コンバータ１１８のような
コンバータモジュールに内在してもよい。

【００２０】コンバータ１８は、ローカル性情報を使用
し（ステップ２０９及び２１０）、例えば、変換ルック
アップテーブルを用いることにより従来の方法で変換を
行う（ステップ２１２）。

【００２１】変換により生じたストリングは、ユーザバ
ッファ１１４に記憶され、「ユーザストリング」と称さ
れる（ステップ２１４）。変換が行われたデータベース
ストリングは、データベースストリングバッファ１１６
に元の形態で残される。

【００２２】この段階において、ユーザストリング及び
データベースストリングの両方は、データベースからの
未編集のデータを表し、ユーザストリングは変換されて
はいるが、未編集のままである。ユーザフラグ「カレン
ト」は、対応するデータベースフラグと一致するように
「真」にセットされる（ステップ２１６）。

【００２３】図４を参照すれば、異なるデータ項目、こ
こに示す例では、異なるストリングが、ユーザ側インタ
ーフェイスを経てユーザストリングバッファ１１４へ送
られたときに、データベースフラグ「カレント」は、
「偽」にセットされ、データベースストリングがデータ
項目のカレント状態をもはや表さないことを示す。

【００２４】図５を参照すれば、データベース側インタ
ーフェイスを経てデータベースにデータを書き戻すべき
ときには、ソース又はデータベースストリングバッファ
１１６に記憶されたデータベースストリングが与えられ
る（ステップ４２６）。データベースストリングフラグ
「カレント」が「真」である場合には（ステップ４２
８）、データベースストリングが直接与えられる。デー
タベースストリングフラグが「偽」である場合には、ユ
ーザストリングが最初にユーザのローカル性からデータ
ベース又はソースのローカル性に変換される（ステップ
４２０）。この変換の結果は、データベースストリング
バッファ１１６にデータベースストリングとして記憶さ
れ（ステップ４２２）、そしてデータベースストリング
フラグは、「偽」にセットされる（ステップ４２４）。
両方の場合に、データが必要とされるまで変換を遅延す
ることができる。

【００２５】ある場合には、ソースローカル性のあるキ
ャラクタがユーザローカル性に対応キャラクタをもたな
いか或いはそれとは逆の場合に、完全に正しい変換を実
行できないことがある。このため、結局のところ、ユー
ザストリングからデータベースストリングへの（或いは
それとは逆の）変換を呼び出して、両バッファをカレン
ト状態にし（それらのフラグ「カレント」が「真」にセ
ットされる）、そしてフラグ１９０の変換状態フラグを
セットして、エラー又は例外的状態が生じたかどうか指
示し、もしそうであれば、データのどこに生じたか指示
する（ステップ４１６）ためのルーチンが設けられる。
これらのルーチン及びフラグは、例えば文字の変換結果
が失われたかどうか決定するために何時でも使用でき
る。

【００２６】異なるローカル性から検索され及びそこに
送られるデータの問題は、データベースのアプリケーシ
ョンに限定されない。例えば、データ項目は、２つ以上
のローカル性を有する２つ以上のピアプロセスにより交
換することができる。図１に戻ると、データは、第２の
接続層２０８からインターフェイス１６４を経て読み取
られる。同じユーザバッファ１１４を使用してもよい
が、異なる第２のソースバッファ１５６が読み取られた
データを保持し、そして第２のソースローカル性１５８
がローカル性情報を保持する。このように、データは、
１つのソースから読み取られ、ユーザにより編集され、
そしてそれ自身のローカル性を有する第２のソースへ書
き込まれる。データ項目は、ＯＬＥ（マイクロソフト）
又はＯｐｅｎＤｏｃ（アップルコンピュータ）オブジ
ェクトのような分散されたオブジェクトに存在してもよ
い。ＯＬＥオブジェクトは、通常、単にＯＬＥオブジェ
クトであることによりローカル性を有し、そしてオブジ
ェクト又はオブジェクトのデータ項目には、より多くの
ローカル性情報が関連してもよい。更に、ユーザプログ
ラム又はプロセスは、それ自身のローカル性で分散オブ
ジェクトにおいて見つけることもできる。

【００２７】上記のシステム及び方法は、以下に述べる
ように、マイクロソフト・ファンデーション・クラス
（ＭＦＣ）に規定されたオブジェクトクラスのフレーム
ワークで実施することができる。ここでは、クライエン
ト／サーバデータベースシステムについて特定の実施を
説明する。

【００２８】クラスＬＣＳｔｒｉｎｇを定義する。これ
は、上記のユーザデータバッファとして働くＭＦＣＣ
Ｓｔｒｉｎｇを含む。ＬＣＳｔｒｉｎｇのデータメンバ
ーの１つは、クラスＬＣＳＤａｔａの可変長さ構造体に
対するポインタである。ＬＣＳＤａｔａ構造体は、次の
データメンバーを含む。（１）ｍＤＢＤａｔａは、データベースストリングに
対応し、ＤＢＬｏｃａｌｅキャラクタセットにおいてデ
ータベースエンジンから受け取ったストリングを記憶す
るのに使用される。ｍＤＢＤａｔａは、キャラクタが
多バイトフォーマットであることを示す。（２）ｍＣｌｉｅｎｔＳｔｒｉｎｇは、Ｃｌｉｅｎｔ
Ｌｏｃａｌｅキャラクタセットのユーザストリングを記
憶するのに使用される。

【００２９】（３）ＭＢＤＬｏｃａｌｅは、データベ
ースのローカル性情報をアクセスするために特定のロー
カル性に対し独特の識別子の値を記憶するのに使用され
る。キーとなる値は、タイプＧＬｏｃａｌｅＫｅｙであ
る。（４）ｍｆＣｕｒｒｅｎｔは、どんな情報がカレント
であるかを指示するフラグを記憶するのに使用される。
ｍｆＣｕｒｒｅｎｔは、ユーザストリングフラグＬＣ
ＳｔｒＣ又はデータベースストリングフラグＬＣＳｔｒ
Ｄに対応する。（５）ｍＤＢＤａｔａＬｅｎｇｔｈは、論理キャラク
タにおけるｍＤＢＤａｔａの長さを記憶するのに使用
される。

【００３０】（６）ｍＡｌｌｏｃＬｅｎｇｔｈは、ｍ
ＤＢＤａｔａの割り当てられた長さ（バイト）を記憶
するのに使用される。（７）ｍＤＢＢｙｔｅＬｅｎｇｔｈは、実際に記憶さ
れるときのｍＤＢＤａｔａの長さ（バイト）を記憶す
るのに使用される。この値は、ｍｅｍｃｐｙのようなフ
ァンクションを用いてストリングをコピーするのに適し
ている。（８）ｍｂＣｕｍＬｏｓｓＴｏＤＢ及びｍｂＣｕｍ
ＬｏｓｓＦｒｏｍＤＢは、フラグがクリアされた以前の
発生時から変換ロスが生じたかどうかを指示するフラグ
を記憶するのに使用される。これらフラグは、変換の方
向に特定のものであり、指定がＬＣＳｔｒｉｎｇを伴う
か又は指定がコピーコンストラクタであった場合に指定
にわたって保持される。

【００３１】（９）ｔｃｈａｒＢｕｆ及びｔｃｈａｒＢ
ｕｆＳｉｚｅは、変換動作中に使用されるバッファであ
り、必要に応じて成長することができる。これらバッフ
ァを使用するファンクションは、マルチスレッドアプリ
ケーションに使用するために識別された厳密な領域を有
していなければならない。（１０）ｍｎＲｅｆＣｏｕｎｔは、ＬＣＳｔｒｉｎｇ
の参照回数のカウントを記憶するのに使用される。ＬＣ
Ｓｔｒｉｎｇに対するコピー及び指定動作に対して増加
される。通常の減少は、デストラクタにおいて生じる。
０まで減少されると、エントリーが削除される。ストリ
ングがある方法により変更される場合には、その変更さ
れたストリングに対して新たなｍｎＲｅｆＣｏｕｎｔ
が形成され、古いストリングのｍｎＲｅｆＣｏｕｎｔ
は減少される。

【００３２】（１１）ｄｂｗｃｈａｒＢｕｆ、ｄｂｗｃ
ｈａｒＢｕｆＳｉｚｅ、ｍｂｃｈａｒＢｕｆ及びｍｂｃ
ｈａｒＢｕｆＳｉｚｅは、ＵＮＩＣＯＤＥがクライエン
トにおいてイネーブルされた場合に使用されるバッファ
である。これらは、最初に、割り当てられず、必要に応
じて成長される。

【００３３】クラスＧＬｏｃａｌｅは、ローカル性情報
に対して定義される。ＧＬｏｃａｌｅＭｇｒは、ＧＬｏ
ｃａｌｅをマネージメントするためのクラスである。特
定のローカル性は、ローカル性ストリング又はＧＬｏｃ
ａｌｅＫｅｙ値により選択することができる。デフォー
ルトの場合には、静的なユーザローカル性Ｃｌｉｅｎｔ
Ｌｏｃａｌｅ及びデータベースローカル性ＤＢＬｏｃａ
ｌｅの２つのローカル性がある。データベース又は他の
ソースへの多数の同時接続は、ソース側に２つ以上のロ
ーカル性を生じる。

【００３４】クラスＬＣＳｔｒｉｎｇは、次のコンスト
ラクタを有する。（１）LCString () （２）LCString (const CString& stringSrc) （３）LCString (TCHAR ch, int nRepeat=1) （４）LCString (LPCSTR lpsz) （５）LCString (LPCWSTR lpsz) （６）LCString (LPCTSTR lpch, int nLength) （７）LCString (const unsigned cha*psz) 以上のコンストラクタ（１）−（７）は、同じ名前のＣ
Ｓｔｒｉｎｇコンストラクタに対応し、デフォールトデ
ータベース（ＤＢ）及びクライエントローカル性キー値
を使用する。

【００３５】（８）LCString (const LCString& String
Src)は、同じカレントフラグ及びローカル性でＬＣＳｔ
ｒｉｎｇの厳密なローカル性コピーを行う。（９）LCString (GLocaleKey locKey, const gl mcha
r t* psz) は、サーバからのデータを取り扱うための
ものである。（１０）LCString (LPCTSTR gl, const gl mchar t*
psz) は、適切なＧＬｏｃａｌｅＫｅｙが使用できない
場合にエンジンからのデータを取り扱うためのものであ
る。（１１）LCString (LCurrency& value, LPCTSTR fmt) （１２）LCString (LNumber& value, LPCTSTR fmt) （１３）LCString (LDataTime& value, LPCTSTR fmt) （１４）LCString (LCurrency& value, const LCString
& fmt) （１５）LCString (LNumber& value, const LCString&
fmt) （１６）LCString (LDataTime& value, const LCString
& fmt) 以上のコンストラクタ（１１）−（１６）は、アーギュ
メントに含まれたＤＢＬｏｃａｌｅのフォーマット情報
を用いて、アーギュメントと同じローカル性におけるス
トリングを形成する。

【００３６】次の属性及び方法は、クラスＬＣＳｔｒｉ
ｎｇに対して定義される。int GetLength () constは、
クライエント側のストリングの長さをＴＣＨＡＲ単位で
返送する。int DBGetLength () constは、ＤＢＬｏｃａ
ｌｅストリングの長さを論理キャラクタカウントで返送
する。BOOL IsEmpty () const は、ストリングの長さが
０である場合に「真」を返送する。void Empty () は、
ストリングを空（即ち、長さ０）にする。TCHAR GetAt
(int nIndex) const は、ＴＣＨＡＲオフセットｎＩｎ
ｄｅｘのＴＣＨＡＲを返送する。

【００３７】void SetAt(int nIndex, TCHAR ch)は、Ｔ
ＣＨＡＲオフセットｎＩｎｄｅｘのＴＣＨＡＲをｃｈに
セットする。LCString DBGetAt(int nIndex) constは、
ＤＢＬｏｃａｌｅキャラクタセット特性を用いてＤＢ対
応ストリングの論理キャラクタオフセットｎＩｎｄｅｘ
において論理キャラクタを返送する。void DBSetAt(int
nIndex, const LCString& ch)は、論理キャラクタオフ
セットｎＩｎｄｅｘの論理キャラクタをｃｈにセットす
る。ストリングのバイト長さは、多バイト状態において
変更することができる。TCHAR operator [] (int Inde
x) const は、ＧｅｔＡｔ（）と同じである。operator
LPCTSTR () const は、ＣＳｔｒｉｎｇ内部ストリング
バッファへのアクセスを与えるキャストオペレータであ
る。

【００３８】operator const CString*() は、内部ＣＳ
ｔｒｉｎｇへのアクセスを与えるキャストオペレータで
あるが、これは、リードオンリアクセスである。

【００３９】クラスＬＣＳｔｒｉｎｇに対して定義され
たオーバーロード指定は、次の通りである。（１）const LCString& operator=(const LCString& st
ringSrc) （２）const LCString& operator=(const CString& str
ingSrc) （３）const LCString& operator=(TCHAR ch) （４）const LCString& operator=(char ch) （５）const LCString& operator=(LPCSTR lpsz) （６）const LCString& operator=(LPCWSTR lpsz) （７）const LCString& operator=(const unsigned cha
r* psz)

【００４０】クラスＬＣＳｔｒｉｎｇに対して定義され
たオーバーロードストリング連結ファンクションは、次
の通りであり、これは、第２のオペレータを第１のオペ
ランドに連結する。（１）const LCString& operator+=(const CString& st
ring) （２）const LCString& operator+=(const LCString& s
tring) （３）const LCString& operator+=(TCHAR ch) （４）const LCString& operator+=(char ch) （５）const LCString& operator+=(LPCTSTR lpsz)

【００４１】次のオペレーションは、２つのストリング
を連結し、新たなＬＣＳｔｒｉｎｇインスタンスを形成
する。（１）friend LCString AFXAPI operator+(const LCStr
ing& s1, constCString& s2) （２）friend LCString AFXAPI operator+(const CStri
ng& s1, constLCString& s2) （３）friend LCString AFXAPI operator+(const LCStr
ing& s1, constLCString& s2) （４）friend LCString AFXAPI operator+(const LCStr
ing& s1, TCHAR ch) （５）friend LCString AFXAPI operator+(TCHAR ch, c
onst LCString& s1) （６）friend LCString AFXAPI operator+(const LCStr
ing& s1, char ch) （７）friend LCString AFXAPI operator+(char ch, co
nst LCString& s1) （８）friend LCString AFXAPI operator+(const LCStr
ing& s1, LPCTSTRlpsz) （９）friend LCString AFXAPI operator+(LPCTSTR lps
z, const LCString&s1) 上記オペレーションの結果は、クライエント側又はデー
タベース側のいずれかで有効である。ＤＢＬｏｃａｌｅ
は、次のルールに基づいてセットされる。

【００４２】各ストリングのＤＢＬｏｃａｌｅが同じキ
ャラクタセットを有する場合には、２つの可能性が存在
する。第１に、いずれかのアーギュメントがＤＢＬｏｃ
ａｌｅにおいて有効である場合には、その結果がＤＢＬ
ｏｃａｌｅにおいて有効でありそしてＤＢＬｏｃａｌｅ
は、第１のアーギュメントのローカル性である。第２
に、いずれのアーギュメントもＤＢＬｏｃａｌｅにおい
て有効でない（即ち、ＣｌｉｅｎｔＬｏｃａｌｅに対し
てのみ有効である）場合には、その結果がＣｌｉｅｎｔ
Ｌｏｃａｌｅにおいて有効であるが、ＤＢＬｏｃａｌｅ
は、第１のアーギュメントのローカル性である。

【００４３】ＤＢＬｏｃａｌｅが同じキャラクタセット
値をもたない場合には、３つの可能性が存在する。第１
に、両方のアーギュメントがＤＢＬｏｃａｌｅ側で有効
な場合には、その結果がＤＢＬｏｃａｌｅ側で有効であ
り、その結果、ＤＢＬｏｃａｌｅは、第１のアーギュメ
ントのローカル性となる。第２のアーギュメントは、先
ず、ＣｌｉｅｎｔＬｏｃａｌｅキャラクタセットに変換
され、次いで、そこからＤＢＬｏｃａｌｅキャラクタセ
ットに変換される。

【００４４】第２に、ＤＢＬｏｃａｌｅ側で１つのアー
ギュメントのみが有効である場合には、その結果がＤＢ
Ｌｏｃａｌｅ側で有効となり、その結果、ＤＢＬｏｃａ
ｌｅは、ＤＢＬｏｃａｌｅ側で有効であったストリング
をもつものとなる（第１のアーギュメントであるか第２
のアーギュメントであるかに係わりなく）。

【００４５】第２のケースは、ＳＱＬステートメントを
形成する際に一般的に遭遇する場合である。ＳＱＬシン
タックスは、ファイルのようなＣｌｉｅｎｔＬｏｃａｌ
ｅソースからしばしば受け取られ、ＣｌｉｅｎｔＬｏｃ
ａｌｅキャラクタセットに依然存在する。第１の挿入
は、おそらく、局所化されたサーバ名、テーブル名、カ
ラム名又はテキストである。これは、しばしばデータベ
ースサーバから受け取られ、そしてＤＢＬｏｃａｌｅに
おいて依然有効である。その結果は、名前のローカル性
において有効であり、キャラクタのロスは生じない。

【００４６】第３に、ＤＢＬｏｃａｌｅにおいていずれ
のアーギュメントも有効でない場合には、その結果がＣ
ｌｉｅｎｔＬｏｃａｌｅにおいて有効となり、ＤＢＬｏ
ｃａｌｅは、第１アーギュメントのローカル性となる。

【００４７】１つのアーギュメントがＬＣＳｔｒｉｎｇ
でない場合には（通常は、ＴＣＨＡＲ、ＣＳｔｒｉｎｇ
＆又はＬＰＣＴＳＴＲ）、その結果がＬＣＳｔｒｉｎｇ
アーギュメントのＤＢＬｏｃａｌｅ側で有効となり、Ｄ
ＢＬｏｃａｌｅはＬＣＳｔｒｉｎｇアーギュメントから
得られる。

【００４８】ストリング比較ファンクションは、次の通
りである。Compare(const LPCTSTR lpsz) const は、コ
ードポイントに基づくクライエント側のバージョンを比
較する。DBCompare(const LCString& s2) const は、コ
ードポイントに基づくＤＢ側のバージョンを比較する。
CompareNoCase(LPCTSTR lpsz) const は、全てのキャラ
クタがＣｌｉｅｎｔＬｏｃａｌｅに基づき小文字に変換
された後にコードポイントに基づくクライエント側のバ
ージョンを比較する。DBCompareNoCase(const LCString
& s2) const は、全てのキャラクタがＤＢＬｏｃａｌｅ
に基づき小文字に変換された後にコードポイントに基づ
くＤＢ側のバージョンを比較する。

【００４９】Collate(LPCTSTR lpsz) const は、Ｃｌｉ
ｅｎｔＬｏｃａｌｅ照合分類に基づきクライエント側の
バージョンを比較する。これは、たとえ全てのキャラク
タが同じであっても、エンジンからの異なる順序で分類
されてもよい。DBCollate(const LCString& s2) const
は、ＧＬＳ（インフォーミックス社のＧＬＳライブラリ
ー）アルゴリズムを用いてＤＢＬｏｃａｌｅ照合分類に
基づきＤＢ側のバージョンを比較する。これは、ＤＢサ
ーバとの一貫性が要求されるときに使用しなければなら
ない。

【００５０】簡単なサブストリング抽出ファンクション
は、次の通りである。LCString Mid(int nFirst, int n
Count) constは、クライエント側のバージョンにおいて
ＴＣＨＡＲオフセットｎＦｉｒｓｔで始めてｎＣｏｕｎ
ｔＴＣＨＡＲを抽出する。ｎＣｏｕｎｔが存在しない
場合には、ストリングの残り部分を取り出す。LCString
DBMid(int nFirst, int nCount) constは、ＤＢ側バー
ジョンにおいて論理キャラクタオフセットｎＦｉｒｓｔ
で始めてｎＣｏｕｎｔ論理キャラクタを抽出する。ｎＣ
ｏｕｎｔが存在しない場合には、ストリングの残り部分
を取り出す。LCString Left(int nCount) const は、ク
ライエント側バージョンで始めてｎＣｏｕｎｔＴＣＨ
ＡＲを抽出する。ＭＢＣＳ状態においては、これは、ス
トリングの終わりに部分的キャラクタをチェックしな
い。

【００５１】LCString DBLeft(int nCount) const は、
ＤＢ側バージョンの始めにｎＣｏｕｎｔ論理キャラクタ
を抽出する。LCString Right(int nCount) constは、ク
ライエント側バージョンの最後のｎＣｏｕｎｔＴＣＨ
ＡＲを抽出する。LCString DBRight(int nCount) const
は、ＤＢ側バージョンの最後のｎＣｏｕｎｔ論理キャラ
クタを抽出する。LCString SpanIncluding (LPCTSTR lp
sz) const は、ｌｐｓｚのキャラクタに合致するクライ
エント側ストリングの始めに見つかった全てのキャラク
タを含むストリングを返送する。第１のキャラクタがｌ
ｐｓｚにない場合にはＥｍｐｔｙストリングを返送す
る。

【００５２】LCString SpanExcluding (LPCTSTR lpsz)
const は、ｌｐｓｚのキャラクタに合致しないクライエ
ント側ストリングの始めに見つかった全てのキャラクタ
を含むストリングを返送する。第１のキャラクタがｌｐ
ｓｚのキャラクタに合致する場合にはＥｍｐｔｙストリ
ングを返送する。

【００５３】変換ファンクションは、次の通りである。
void MakeUpper () は、クライエント側バージョンの全
てのキャラクタを大文字にする。void DBMakeUpper ()
は、ＤＢ側バージョンの全てのキャラクタをＤＢＬｏｃ
ａｌｅに基づき大文字にする。void MakeLower () は、
クライエント側バージョンの全てのキャラクタを小文字
にする。void DBMakeLower () は、ＤＢ側バージョンの
全てのキャラクタをＤＢＬｏｃａｌｅに基づき小文字に
する。void MakeReverse () は、クライエント側ストリ
ングの論理キャラクタの順序を逆転する。

【００５４】void DBMakeReverse () は、ＤＢ側ストリ
ングの論理キャラクタの順序を逆転する。

【００５５】ホワイトスペース削除ファンクションは、
次の通りである。void TrimRight () は、クライエント
側バージョンの全ての後続するホワイトスペースキャラ
クタを削除する。void DBTrimRight () は、ＤＢ側バー
ジョンの全ての後続するホワイトスペースキャラクタを
ＤＢＬｏｃａｌｅに基づき削除する。void TrimLeft ()
は、クライエント側バージョンの全ての先導するホワイ
トスペースキャラクタを削除する。void DBTrimLeft ()
は、ＤＢ側バージョンの全ての先導するホワイトスペー
スキャラクタをＤＢＬｏｃａｌｅに基づき削除する。

【００５６】サーチファンクションは、次の通りであ
る。Find(TCHAR ch) const及びFind(LPCTSTR lpsz) con
stは、クライエント側バージョン内におけるｃｈ又はｌ
ｐｓｚの最初の発生のＴＣＨＡＲインデックスを見つけ
る。DBFind(TCHAR ch) const、DBFind(LPCTSTR lpsz) c
onst、及びDBFind(const LCString& lc) constは、ＤＢ
側バージョン内におけるアーギュメントの最初の発生の
論理キャラクタインデックスを見つける。ReverseFind
(TCHAR ch) const は、クライエント側バージョン内に
おけるｃｈの最後の発生のＴＣＨＡＲインデックスを見
つける。DBReverseFind(TCHAR ch) const 、及びDBReve
rseFind(const LCString& lc)const は、ＤＢ側バージ
ョン内におけるアーギュメントの最後の発生の論理キャ
ラクタインデックスを見つける。

【００５７】FindOneOf(LPCTSTR lpsz) const は、ｌｐ
ｓｚの任意のキャラクタのクライエント側バージョンに
おける最初の発生を見つける。DBFindOneOf(LPCTSTR lp
sz) const 、及びDBFindOneOf(const LCString& lc)con
st は、アーギュメントの任意の論理キャラクタのＤＢ
側バージョンにおける最初の発生を見つける。

【００５８】次のものは、Ｃキャラクタアレーとしてス
トリング具現化バッファへのアクセスを与える。LPTSTR
GetBuffer(int nMinBufLength) は、クライエント側バ
ージョンに対する内部ＴＣＨＡＲバッファのポインタを
得る。又、これは、バッファがｎＭｉｎＢｕｆＬｅｎｇ
ｔｈＴＣＨＡＲを保持するに充分なサイズであるよう
に保証する。void ReleaseBuffer(int nNewLength=-1)
は、ＧｅｔＢｕｆｆｅｒ通話及び内部ＴＣＨＡＲバッフ
ァの直接操作の後に内部変数を調整するのに使用され
る。ｎＮｅｗＬｅｎｇｔｈが０以上の場合には、ＴＣＨ
ＡＲオフセットｎＮｅｗＬｅｎｇｔｈにＴＣＨＡＲナル
ターミネータが挿入される。

【００５９】LPTSTR GetBufferSetLength(int nNewLeng
th) は、ＴＣＨＡＲのｎＮｅｗＬｅｎｇｔｈに対して調
整された後にクライエント側バッファに対するポインタ
を返送する。void FreeExtra () は、クライエント側ス
トリングバッファに関連した余計なメモリを解放する。
LPSTR DBGetBuffer(int nMinBufLength)は、ＤＢ側バー
ジョンに対し内部バイトバッファへのポインタを得る。
又、これは、バッファがｎＭｉｎＢｕｆＬｅｎｇｔｈ論
理キャラクタを保持するに充分なサイズであるよう保証
する。void DBReleaseBuffer(int nNewLength=-1) は、
ＤＢＧｅｔＢｕｆｆｅｒ通話及び内部ＤＢバッファの直
接操作の後に内部変数を調整するのに使用される。ｎＮ
ｅｗＬｅｎｇｔｈが０以上の場合には、論理キャラクタ
オフセットｎＮｅｗＬｅｎｇｔｈに論理キャラクタナル
ターミネータが挿入される。

【００６０】LPSTR DBGetBufferSetLength(int nNewLen
gth)は、論理キャラクタにおいてｎＮｅｗＬｅｎｇｔｈ
に対して調整された後にＤＢ側バッファへのポインタを
返送する。void DBFreeExtra () は、ＤＢ側ストリング
バッファに関連した余計なメモリを解放する。

【００６１】次の方法も定義される。〜LCString ()
は、デストラクタである。int GetAllocLength () cons
t は、ＴＣＨＡＲにおけるクライエント側バッファの長
さを得る。DBGetAllocLength () は、ＤＢ側バッファの
長さ（バイト）を得る。このサイズがバイト単位である
理由は、ＤＢサーバにおけるキャラクタセットがクライ
エントマシンと同じ形式でないことがあるからである
（単一バイト、多バイト、ワイドキャラクタ）。BOOL C
umLossToDB () const 及びBOOL CumLossFromDB () は、
内部フラグがリセットされた最後のときから（又は最初
の形成から）変換中のキャラクタがロスした（１つのキ
ャラクタセットのキャラクタが別のキャラクタセットの
キャラクタに合致せず、従って、その場所に構成キャラ
クタが入れられる）場合に「真」を返送する。これらの
フラグは、ＬＣＳｔｒｉｎｇの指定にわたって保存され
る（連結ではなく）と共に、コピーコンストラクタ全体
にわたって保存される。キャラクタのロスは、論理キャ
ラクタの数の変化を指すものではなく、意味の損失を指
す。というのは、元のストリングをもはや再構成できな
いからである。

【００６２】void ResetCumLossToDB ()及びvoid Reset
CumLossFromDB ()は、フラグの内部状態をリセットする
（「偽」へ）。SetDBLocale(GLocaleKey Key) は、ＤＢ
Ｌｏｃａｌｅ側をキーに調整する。手前のローカル性の
キャラクタセットがキーと同じでなく、そしてストリン
グがサーバ側でのみカレントである場合は、新たなロー
カル性が古いものに置き換わる前に、ストリングが最初
にクライエントローカル性に変換される。復帰値は、ア
ーギュメント（キー）である。

【００６３】SetDBLocale(LPCTSTR loc)は、ＤＢＬｏｃ
ａｌｅ側をｌｏｃで定められたローカル性に調整する。
手前のローカル性のキャラクタセットがｌｏｃと同じで
なくそしてストリングがサーバ側でのみカレントである
場合には、新たなローカル性が古いものに置き換わる前
にストリングが先ずクライエントローカル性に変換され
る。復帰値は、もしうまくいけば、ｌｏｃに対して形成
されたＧＬｏｃａｌｅＫｅｙとなる。ForceToDB ()は、
ストリングを強制的にＤＢ側のカレントにする。このフ
ァンクションは、例外を与えるものではなく、例外を捕
らえるものであり、例外又は他の問題に遭遇した場合に
エラーコードを返送する。たとえ欠陥が返送されても有
効なデータはある（おそらく空のストリングのみ）。こ
のファンクションは、特に、ＧｅｔＬｅｎｇｔｈ（）の
ような簡単な問合せ方法が存在する場合に、ある例外的
なケースを回避するために使用できる。返送コードは次
の通りである。

【００６４】（１）LC FORCESUCCESS: 首尾良い返送。
ストリングが首尾良く変換されるか又は既にＤＢ側のカ
レントであり、変換に対するデータロスフラグ（いずれ
かの方向の）は現在セットされない。（２）LC FORCEMEMORY:変換プロセス中にメモリエラー
に遭遇する。それによりＤＢ側に生じるストリングは、
ゼロ長さのストリングであり、ＤＢへの変換に対してデ
ータロスフラグがセットされる。（３）LC FORCGLSCONVERSIONMISSING: 関連する２つの
キャラクタセットに対して変換は行われず、それらは同
じキャラクタセットではない。これは、ＧＬＳの部分が
インストールされず、環境変数が正しく設定されず、又
はこのセットの言語に対して単に何のサポートも現在使
用できないことを意味する。それによりＤＢ側に生じる
ストリングは、ゼロ長さストリングであり、ＤＢへの変
換に対してデータロスフラグがセットされる。

【００６５】（４）LC FORCGLSCONVERSIONERROR: 変換
プロセス中に生じるエラー（データロスではない）。こ
の形式のエラーの主たる原因は、不当なキャラクタに遭
遇することである。その結果、ＤＢ側に生じるストリン
グは、ゼロ長さストリングとなり、ＤＢへの変換に対し
てデータロスフラグがセットされる。（５）LC FORCDATALOSSNOW:ストリングがこのファンク
ションにより変換されたが、変換中にあるデータが失わ
れた。実際の変換が行われそしてデータロスが生じた場
合にのみこの返送が与えられる。（６）LC FORCDATALOSSPREVIOUS: ストリングが首尾良
く変換され、この変換に対してデータロスはなかった
が、累積データロスフラグが依然としてセットされてい
る。これは、ある手前のオペレーションがその手前のオ
ペレーションにおいてデータロスしたことを意味する。
これは、カレントストリングには適用してもしなくても
よい。

【００６６】（７）LC FORCDATAPREVIOUSLOSS: ストリ
ングがＤＢ側で既にカレントであるので変換が必要でな
い。しかしながら、４つのデータロスフラグの少なくと
も１つがセットされている。ロスは、カレントストリン
グの内容に関連する。

【００６７】ForceToClient ()は、ストリングをクライ
エント側において強制的にカレントにする。このファン
クションは、例外を与えるものではなく、例外を捕らえ
るものであり、例外又は他の問題に遭遇した場合にエラ
ーコードを返送する。たとえ欠陥が返送されても有効な
データはある（おそらく空のストリングのみ）。このフ
ァンクションは、特に、ＧｅｔＬｅｎｇｔｈ（）のよう
な簡単な問合せ方法が存在する場合に、ある例外的なケ
ースを回避するために使用できる。返送コードは次の通
りである。（１）LC FORCESUCCESS: 首尾良い返送値。ストリング
が首尾良く変換されるか又は既にクライエント側におい
てカレントであり、変換に対するデータロスフラグ（い
ずれかの方向の）は現在セットされない。

【００６８】（２）LC FORCEMEMORY:変換プロセス中に
メモリエラーに遭遇する。それによりクライエント側に
生じるストリングは、ゼロ長さのストリングであり、ク
ライエントへの変換に対してデータロスフラグがセット
される。（３）LC FORCGLSCONVERSIONMISSING: 関連する２つの
キャラクタセットに対して変換は行われず、それらは同
じキャラクタセットではない。これは、ＧＬＳの部分が
インストールされず、環境変数が正しく設定されず、又
はこのセットの言語に対して単に何のサポートも現在使
用できないことを意味する。それによりクライエント側
に生じるストリングは、ゼロ長さストリングであり、ク
ライエントへの変換に対してデータロスフラグがセット
される。（４）LC FORCGLSCONVERSIONERROR: 変換プロセス中に
生じるエラー（データロスではない）。この形式のエラ
ーの主たる原因は、不当なキャラクタに遭遇することで
ある。その結果、クライエント側のストリングは、ゼロ
長さストリングとなり、クライエントへの変換に対して
データロスフラグがセットされる。

【００６９】（５）LC FORCDATALOSSNOW:ストリングが
このファンクションにより変換されたが、変換中にある
データが失われた。実際の変換が行われそしてデータロ
スが生じた場合にのみこの返送が与えられる。（６）LC FORCDATALOSSPREVIOUS: ストリングが首尾良
く変換され、この変換に対してデータロスはなかった
が、累積データロスフラグが依然としてセットされてい
る。これは、ある手前のオペレーションがその手前のオ
ペレーションにおいてデータロスしたことを意味する。
これは、カレントストリングには適用してもしなくても
よい。（７）LC FORCDATAPREVIOUSLOSS: ストリングがＤＢ側
で既にカレントであるので変換が必要でない。しかしな
がら、４つのデータロスフラグの少なくとも１つがセッ
トされている。ロスは、カレントストリングの内容に関
連する。

【００７０】上記方法とは異なり、UpdateC(BOOL NoExc
eptions=FALSE)及びUpdateDB(BOOLNoExceptions=FALSE)
は、ForceToClient 及びForceToDB をサポートする内
部の（保護された）方法であるが、新たなアーギュメン
トが追加されている。アーギュメントが「真」である場
合には、全ての例外（新たなものにより生じたメモリ例
外を含む）が捕らえられそして返送値に変換される。更
に、このルーチン内で検出されたエラーは、アーギュメ
ントが「真」の場合にエラー値を返送し、そしてアーギ
ュメントが「偽」の場合に例外を与える。実際の返送値
は、ForceToClient 及びForceToDB の返送値に合致す
る。

【００７１】以下の方法は、エンジンファンクションと
同等のものを与える。DBSafeMid(int offset, int leng
th) const は、バイトベースのオフセット及び長さ値を
使用する（他の殆どの場合の論理キャラクタベースとは
対照的に）。いずれかのオフセット又は長さ値がストリ
ングの始め又は終わりに部分的な論理キャラクタを生じ
る場合には、部分的なキャラクタバイトがスペースキャ
ラクタ（’ ’）と置き換えられる。ストリングが「Ａ
１Ａ２Ｂ１Ｂ２Ｃ１Ｃ２」（即ち３つのマルチバイトキ
ャラクタ）である場合には、ＤＢＳａｆｅＭｉｄ（１，
４）が「Ｂ１Ｂ２」を返送する。添字は、マルチバイト
キャラクタのバイト記述を表す。

【００７２】次のルーチンは、参照カウント能力を与え
ることができる。LockBuffer () は、ＣＳｔｒｉｎｇの
符号に合致し、有効なクライエントバッファのポインタ
を返送する。このコールは、ＬＣＳｔｒｉｎｇのこのイ
ンスタンスに対し参照カウント動作をオフにする。これ
は、このインスタンスに対し内部データの個別のコピー
が作られる（このデータを探している他のインスタンス
がある場合に）ことを意味し、そしてロックされる間に
別のＬＣＳｔｒｉｎｇに対して指定／コピーされる場合
には、その行先インスタンスに対してデータの個別のコ
ピーが作られる（アンロック時の参照カウント動作とは
対照的に）。LockBuffer () は、ユーザがバッファを変
更し、従って、ＤＢバッファの内容を無効化すると仮定
する。更に、ＤＢ側のカレント性を必要とするこのイン
スタンスに何らかのアクセスがなされた場合は、「アサ
ート」に失敗する。

【００７３】LockDBBuffer () は、LockBufferと等価で
あるが、有効なＤＢ側バッファに対するポインタを含ん
でいる。このコールは、ＬＣＳｔｒｉｎｇのこのインス
タンスに対する参照カウント動作をオフにする。これ
は、内部データの個別のコピーがこのインスタンスに対
してなされる（このデータを探している他のインスタン
スがある場合に）ことを意味し、そしてロックされる間
に別のＬＣＳｔｒｉｎｇに対して指定／コピーされる場
合には、その行先インスタンスに対してデータの個別の
コピーが作られる（アンロック時の参照カウント動作と
は対照的に）。

【００７４】LockDBBuffer () は、ユーザがバッファを
変更し、従って、クライエントバッファの内容を無効化
すると仮定する。更に、クライエント側のカレント性を
必要とするこのインスタンスに何らかのアクセスがなさ
れた場合は、「アサート」に失敗する。ReleaseBuffer
()は、LockBuffer () 又はLockDBBuffer () のいずれか
によりロックされたバッファをアンロックする。ＴＣＨ
ＡＲオフセット（インデックス）からストリングへのPr
evCharIndex(int index) constは、クライエント側スト
リングにおける手前の論理キャラクタのＴＣＨＡＲイン
デックスを決定する。首尾良い返送値は、ゼロ以上であ
って且つＧｅｔＬｅｎｇｔｈ（）未満である。インデッ
クスが０である（ストリングを始めを指す）か又はスト
リングの外側である場合には、返送値が−１となる。こ
れは、インデックスを変更するための「−−」演算子に
代わって使用しなければならない。

【００７５】ＴＣＨＡＲオフセット（インデックス）か
らクライエント側ストリングへのGetCharValue(int ind
ex) const は、その位置における論理キャラクタ値を返
送する。首尾良い返送値は、０≦返送値≦ＵＣＨＡＲ
ＭＡＸ（ほとんどのマイクロソフトの場合に２５５又は
６５５３６）となる。返送値は、ストリングマーカーの
終わり（==GetLength() ）を指す場合に０となる。イン
デックスがストリングの外側の場合には、返送値が−１
となる。

【００７６】次のファンクションの各々は、ＴＣＨＡＲ
オフセット（ｎＩｎｄｅｘ）における論理キャラクタを
テストする。各ファンクションは、論理キャラクタが特
徴をもつ場合には「真」（１）を返送する。キャラクタ
が特徴をもたないか又はそのストリングに対するインデ
ックス値の範囲を外れている場合には、「偽」（０）を
返送する。（１）IsAlnum(int nIndex) const （２）IsAlpha(int nIndex) const （３）IsBlank(int nIndex) const （４）IsControl(int nIndex) const （５）IsDigit(int nIndex) const （６）IsGraph(int nIndex) const

【００７７】次の方法は、例外の取り扱いをサポートす
る。GLocaleMgr::Init(void(*))(int, LPCTSTR, LPCTST
R)=DoExcept)は、「アプリケーションで定められた」例
外ハンドラーをインストールし、次いで、ＧＬｏｃａｌ
ｅＭｇｒデータを初期化する。このファンクションは、
ＤＬＬのＬｏａｄＬｉｂｒａｒｙの直後にコールされね
ばならない。アーギュメントは、以下のデフォールトフ
ァンクションに対するアプリケーション置き換えであ
る。これは、エラーのカスタム処理を行えるようにす
る。void DoExcept(int error, LPCTSTR msg, LPCTSTR
arg)は、ＬＣＳｔｒｉｎｇＤＬＬに対するデフォールト
「ユーザ例外」ハンドラーである。これは、メッセージ
ボックスを表示し、次いで、ＣＵｓｅｒＥｘｃｅｐｔｉ
ｏｎを与える。いかなる置き換えも、アーギュメントを
何らかの仕方で（どこかに記憶する）処理しそして何ら
かの種類の例外を与えることができる（もし必要であれ
ば、エラー数及びメッセージを含む多数の特殊な例外を
もつことができる）。

【００７８】ＬＣＳｔｒｉｎｇを使用するために、ＧＬ
ｏｃａｌｅＭｇｒを、サーバへの接続を行う前にデフォ
ールトローカル性と共に設定しなければならない。更
に、各付加的なサーバのローカル性を、接続の前にＧＬ
ｏｃａｌｅＭｇｒ：：ＧＬＡｄｄＲｅｆｅｒｅｎｃｅと
共に入力しなければならず、そしてＧＬｏｃａｌｅＫｅ
ｙを、ＬＣＳｔｒｉｎｇの形成に使用するために記憶し
なければならない。

【００７９】接続の直後にカラム（フィールド）ごとに
ローカル性を有するデータベースの場合には、付加的な
ローカル性情報を収集しそしてＧＬｏｃａｌｅＭｇｒに
挿入し、それにより生じるＧＬｏｃａｌｅＫｅｙを記憶
しなければならない。

【００８０】接続の前にＤＢＬｏｃａｌｅが分からない
場合には、次の手順を使用することができる。デフォー
ルトＤＢＬｏｃａｌｅは、クライエントのローカル性
（又は別のデータベースに関連したもののような所望の
任意のローカル性）と同じにセットすることができる。
データベースは、オープンしていて、ローカル性情報を
決定するために問い合わせされ、そしてＤＢＬｏｃａｌ
ｅを適切に設定することができる。これを行うために転
送される全ての初期情報は、全てのキャラクタセットに
共通で且つ同じ基本的な位置にある７ビットのＡＳＣＩ
Ｉセクションに限定される。

【００８１】ＬＣＳｔｒｉｎｇを形成する１つの方法
は、「ｌｏｃＫｅｙ」がＧＬｏｃａｌｅＫｅｙであり、
そして「ｂｕｆｆｅｒ」が「ｃｈａｒ＊」変数である
ような「ｎｅｗＬＣＳｔｒｉｎｇ（ｌｏｃＫｅｙ，ｂ
ｕｆｆｅｒ）」である。バッファは、これに対してゼロ
ターミネータをもたねばならない。これが固定のキャラ
クタフィールドである場合には、これにターミネータを
もつ余裕を有していなければならないか、又はゼロター
ミネータを含むに充分な大きさのバッファへ移動しなけ
ればならない。このバッファは、データベースサーバか
らの全ての転送が多バイトフォーマットであるので、キ
ャラクタに基づくものとなる。

【００８２】データベースにデータを書き込むために、
ＤＢＧｅｔＢｕｆｆｅｒ（）及びＤＢＧｅｔＢｙｔ
ｅ（）を用いて、サーバへコピーして戻すためのキャラ
クタがアクセスされる。これらの方法は、常に、サーバ
への転送に予想されるｃｈａｒ＊多バイトフォーマット
にストリングを有する。パッディングが行われる場合
は、バッファ方法がコールされる前に行われる（例え
ば、固定キャラクタに対し）。

【００８３】データベースの記録においてフィールドを
編集するために、ＬＣＳｔｒｉｎｇを用いる実施は、次
の通りである。ｍＤＢＤａｔａは、データベースエン
ジン１１０から受け取られ、そしてデータベースのスト
リングバッファ１１６に記憶される。ユーザキャラクタ
セットに対して変換が必要とされる場合には、コンバー
タ１１８は、ｍＤＢＤａｔａ及びＧＬｏｃａｌｅから
のローカル性情報を用いて変換を実行する（ステップ２
１２）。ＧＬｏｃａｌｅは、ＧＬｏｃａｌｅＫｅｙｍ
ＤＢＤａｔａを経て得ることができる。ｍＤＢＤａ
ｔａは、ｍＤＢＬｏｃａｌｅへのポインタである。Ｇ
ＬｏｃａｌｅＫｅｙは、ＧＬｏｃａｌｅＭｇｒにおいて
ＧＬｏｃａｌｅ情報をアクセスするためのキー値を表
す。ＧＬｏｃａｌｅＭｇｒは、ユーザのローカル性を表
す静的な要素である。データ要素ｔｃｈａｒＢｕｆは、
変換中にバッファとして使用される。

【００８４】変換結果は、ユーザストリングバッファ１
１４にｍＣｌｉｅｎｔＳｔｒｉｎｇとして入れられ
る。ｍＤＢＤａｔａは、不変のままである。次いで、
ユーザは、ユーザストリングバッファ１１４に記憶され
たｍＣｌｉｅｎｔＳｔｒｉｎｇを変更、修正、又は他
の方法で編集することができる。このような編集が行わ
れる場合には、それにより生じるストリングが指定オペ
レーションを経てＬＣＳｔｒｉｎｇへ戻される。ユーザ
フラグＬＣＳｔｒＣは、依然として「真」にセットさ
れ、一方、データベースフラグＬＣＳｔｒＤは、「偽」
にセットされる。記録は、データベースに返送される。
これは「更新」オペレーションと称される。このオペレ
ーションは、通常は、適当なツールを経て「更新」スト
リングを構成することを伴う。このストリングは、デー
タベースエンジンに送られ、データベースを変更する。

【００８５】「更新」ストリングを構成する際に、ユー
ザストリングｍＣｌｉｅｎｔＳｔｒｉｎｇへのアクセ
スがなされる。というのは、これは、記録に対して編集
が行われた場合のほとんどのカレント情報を表すからで
ある。データベースストリングｍＤＢＤａｔａを変換
するための変換が行われ、新たに編集されたユーザスト
リングの変換形態となるようにされる。ｍＣｌｉｅｎ
ｔＳｔｒｉｎｇが編集されたかどうかは、ＬＣＳｔｒＤ
の状態を検査することにより決定される。ｍＤＢＤａｔ
ａにおいてテストを行い、有効な変換が生じるよう確保
される。

【００８６】例えば、キャラクタのロスが生じたかどう
かに対応するように適当なフラグがセットされる。ユー
ザは、これらのフラグをテストし、変換が有効であるか
どうか決定する。これらのテストは、データベーススト
リングがデータベースに書き戻される前に行われる。変
換の結果は、ＤＢｄａｔａに記憶され、そしてデータベ
ースストリングフラグＬＣＳｔｒＤが「真」にリセット
される。ｍＣｌｉｅｎｔＳｔｒｉｎｇに編集が行われ
なかった場合には、変換が不要である。「更新」ステー
トメントは、データベースストリングであるｍＤＢＤ
ａｔａを用いて構成される。

【００８７】この実施形態は、上記の編集オペレーショ
ンに限定されるものではない。例えば、２つの異なるロ
ーカル性からのストリングが辞書の順序で比較される場
合には、比較の順序が国によって異なる。従って、比較
は、不定又は無効のオペレーションとなる。ユーザのロ
ーカル性内の初期テストは、サーバへのコールがなされ
る前にこれを決定することができる。好ましい実施形態
について本発明を以上に詳細に説明したが、本発明は、
これらに限定されるものではなく、本発明の範囲は、請
求の範囲によって限定されるものとする。

【図面の簡単な説明】

【図１】本発明によるシステムのブロック図である。

【図２】本発明の方法のフローチャートである。

【図３】データ項目を変換する本発明の方法のフローチ
ャートである。

【図４】データを編集する本発明の方法のフローチャー
トである。

【図５】データを変換する本発明の方法のフローチャー
トである。

【符号の説明】

８０コンピュータ９０プロセッサ１０２ユーザプログラム１０８接続層１１０データベースエンジン１１２データベース１１４ユーザバッファ１１６ソースバッファ１１８コンバータ１２０ユーザのローカル性１２４ソースのローカル性１５０データ項目１６０データベースインターフェイス１７０メモリ１９０フラグ２００ソース

Claims

【特許請求の範囲】

【請求項１】データを記憶するためのユーザバッファ
をメモリに維持し；ユーザのローカル性を表すユーザロ
ーカル性情報をメモリに維持し；データを記憶するため
のソースバッファをメモリに維持し；ソースのローカル
性を表すソースローカル性情報をメモリに維持し；ユー
ザバッファ及びソースバッファに記憶されたデータの状
態を指示するための状態フラグをメモリに維持し；新た
なデータがユーザバッファに記憶されるときにソースデ
ータが非カレントでありそしてユーザデータがカレント
であることを指示するために状態フラグをセットし；新
たなデータがソースバッファに記憶されるときにユーザ
データが非カレントでありそしてソースデータがカレン
トであることを指示するために状態フラグをセットし；
ユーザローカル性情報及びソースローカル性情報を用い
て、ソースデータがカレントでそしてユーザデータが非
カレントである場合にソースバッファのデータを変換し
そしてその変換されたデータをユーザバッファに記憶
し、次いで、ユーザデータ及びソースデータの両方がカ
レントであることを指示するために状態フラグをセット
し；ユーザローカル性情報及びソースローカル性情報を
用いて、ユーザデータがカレントでそしてソースデータ
が非カレントである場合にユーザバッファのデータを変
換しそしてその変換されたデータをソースバッファに記
憶し、次いで、ソースデータ及びユーザデータの両方が
カレントであることを指示するために状態フラグをセッ
トし；そしてソースバッファ及びユーザバッファの両方
をデータ項目のインスタンスとして同時に維持する；と
いうことをコンピュータに行わせるための命令を備えた
ことを特徴とするコンピュータ読み取り可能な媒体に存
在するコンピュータプログラム。
【請求項２】データに対するユーザ側インターフェイ
スを形成するためにコンピュータプログラムルーチンの
第１セットを用意し；データに対するソース側インター
フェイスを形成するためにコンピュータプログラムルー
チンの第２セットを用意し；データ項目を読み取る要求
に応答し、その要求がユーザ側インターフェイスからの
ユーザ側要求である場合にはユーザバッファから読み取
りを行い、そしてその要求がソース側インターフェイス
からのソース側要求である場合にはソースバッファから
読み取りを行い；その要求がユーザ側要求であって且つ
ユーザデータが非カレントである場合にはソースバッフ
ァのデータを変換してユーザバッファに記憶させ；そし
てその要求がソース側要求であって且つソースデータが
非カレントである場合にはユーザバッファのデータを変
換してソースバッファに記憶させる；という命令を更に
備えた請求項１に記載のプログラム。
【請求項３】データ項目をユーザプログラム及びソー
スプログラムに使用できるようにするためのコンピュー
タで実施される方法において、ユーザプログラムが読み取り又は書き込みのためにデー
タ項目へのアクセスを得るためのユーザインターフェイ
スを用意し；ソースプログラムが読み取り又は書き込み
のためにデータ項目へのアクセスを得るためのソースイ
ンターフェイスを用意し；ユーザのローカル性を与え；
ソースのローカル性を与え；データ項目を記憶するため
のユーザバッファを用意し；データ項目を記憶するため
のソースバッファを用意し；ユーザバッファ内容及びソ
ースバッファ内容の状態を記憶するように状態メモリを
維持し；新たなデータがユーザインターフェイスを経て
ユーザバッファに記憶されるときにソースバッファの状
態を非カレントにそしてユーザバッファの状態をカレン
トにセットし；新たなデータがソースインターフェイス
を経てソースバッファに記憶されるときにユーザバッフ
ァの状態を非カレントにそしてソースバッファの状態を
カレントにセットし；ユーザバッファの状態がカレント
である場合にユーザバッファの内容を読み取り、そして
ユーザバッファの状態が非カレントである場合にはソー
スバッファの内容をソースのローカル性からユーザのロ
ーカル性へ変換してその変換された内容をユーザバッフ
ァが読み取られる前にユーザバッファに記憶することに
より、データ項目を読み取るためのユーザインターフェ
イスからの要求を満足し；そしてソースバッファの状態がカレントである場合にソースバ
ッファの内容を読み取り、そしてソースバッファの状態
が非カレントである場合にはユーザバッファの内容をユ
ーザのローカル性からソースのローカル性へ変換してそ
の変換された内容をソースバッファが読み取られる前に
ソースバッファに記憶することにより、データ項目を読
み取るためのソースインターフェイスからの要求を満足
する；という段階を備えたことを特徴とする方法。
【請求項４】上記ソースプログラムはサーバであり、
そして上記ユーザプログラムはサーバに対するクライエ
ントである請求項３に記載の方法。
【請求項５】上記ソースプログラムは、データベース
を管理するデータベースサーバ及びデータベースへのア
クセス要求を取り扱うデータベースエンジンである請求
項４に記載の方法。
【請求項６】上記データベースは、データベースエン
ジンを含む関係データベースマネージメントシステムに
より管理される関係データベースである請求項５に記載
の方法。
【請求項７】上記データ項目は、データベースの記録
のフィールドの名前である請求項５に記載の方法。
【請求項８】上記データ項目のローカル性は、データ
ソースにおいてデータベースのフィールドに対して定義
されたローカル性である請求項５に記載の方法。
【請求項９】上記データ項目のローカル性は、データ
ソースにおいてデータベースに対して定義されたローカ
ル性である請求項５に記載の方法。
【請求項１０】上記データ項目のローカル性は、デー
タソースに対して定義されたローカル性である請求項５
に記載の方法。
【請求項１１】上記データソースは分散したオブジェ
クトの集合であり、そして上記データ項目は、分散した
オブジェクトの１つにある請求項３に記載の方法。
【請求項１２】上記分散したオブジェクトの１つは、
ＯＬＥオブジェクトである請求項１１に記載の方法。
【請求項１３】第２のプログラムが読み取り又は書き
込みのためにデータ項目へのアクセスを得るための第２
のインターフェイスを用意し；第２のローカル性を与
え；データ項目を記憶するための第２のバッファを用意
し；第２のバッファの内容の状態を記憶するように状態
メモリを維持し；新たなデータがユーザインターフェイ
スを経てユーザバッファに記憶されるか又はソースイン
ターフェイスを経てソースバッファに記憶されるときは
第２バッファの状態を非カレントにセットし；新たなデ
ータが第２インターフェイスを経て第２バッファに記憶
されるときはユーザバッファの状態を非カレントに、ソ
ースバッファを非カレントに、そして第２バッファをカ
レントにセットし；そしてソースバッファの状態がカレ
ントである場合は上記第２バッファの内容を読み取り、
そして第２バッファの状態が非カレントである場合はユ
ーザバッファの内容をユーザのローカル性から又はソー
スバッファの内容をソースのローカル性から第２のロー
カル性へ変換し、この変換された内容を第２バッファが
読み取られる前に第２バッファに記憶することにより、
データ項目を読み取るための第２のインターフェイスか
らの要求を満足する；という段階を更に備えた請求項３
に記載の方法。