■SI Object Browser 掲示板
|
ユーザの皆様、開発者、サポート担当者の交流のための掲示板です！ ユーザーの皆様同士で教え合ったりもできる交流の場にしたいと思っていますので、相互協力をよろしくお願いします。 なお、過去に同じようなQ&Aがあるケースも多いので、投稿前にキーワード検索してみてください。 |
 |
| ※各投稿のカラーは対象となる製品に対応しています。【■…OB ■…OBER ■…全般 ■…その他】 ※ライセンスに関するお問合せにつきましては、お問い合わせページよりご連絡いただきますようお願いいたします。 ※誹謗中傷や公序良俗に反する書き込みはご遠慮ください。運営側の判断によりメッセージを削除する場合があります。 ※環境依存や技術的調査が必要な問題については掲示板上ではお答えしかねます。ご了承ください。 | |
OB上のデータの扱い方について
2001/11/01 18:16
OB
6
Take
いつもお世話になっております。
ORACLEで開発をしています。
PRO*COBOLを主流に開発をしている者です。
単刀直入ですが、OBで表示するデータのHEX表示機能を希望します。
さらに上記機能の理由とともにOB操作上、発生した現象を報告します。
PRO*COBOLを使用してシステムを構築する途中に発生した出来事です。
COBOLにはLOW-VALUEが存在します。これはDBに存在するNULLとは異なるものです。
開発中のプログラムではDBのレコードにLOW-VALUEが発生する場合はしばしばあります。
OBでデータを表示した場合、文字の後の空白はすべてカットされた状態で表示されます。
例えば、10byte中5byteの文字列が入っている場合に残り5byteは空白かLOW-VALUEかの判断が出来ません。
さらに、LOW-VALUEが入っていた場合、対象レコードはOB上でデータの更新が全く出来ない状態になってしまいます。
よって更新処理と削除処理が出来ません。
ＳＱＬを実行すれば更新・削除が出来ます。（LOW-VALUEが入っていない項目を抽出条件とする）
余談ですがACCESSの場合は存在するデータの後ろの空白は取り除いていません。LOW-VALUEが入っていたらすぐに見て解りました。データの更新・削除も可能でした。
LOW-VALUEが絡む現象がもう１つあります。
例えば、LOW-VALUEが入っているデータがキーだとします。
(キー長10byte文字型)
"_"をLOW-VALUEとします。
文字列 ABCDEF____
HEX1 4444440000
HEX2 1234560000
このデータと、LOW-VALUEが存在しないデータをINSERTします。
"~"を半角スペースとします
文字列 ABCDEF~~~~
HEX1 4444442222
HEX2 1234560000
この２つのデータは異なるものなのでキーは重複しません。
しかし、OBでは表示が同じになります。
（LOW-VALUEはバイトに文字がが存在しない意味となり、空白はカットされるため）
この場合データは１行しか表示されず、レコードにカーソルを移動させたりすると表示されるデータの中身が様々な表示になります（表示レコードが可変する）。
上記理由により、HEX表示機能か、あるいは空白削除機能の排除を希望します。
以上、宜しく御願いします。
ORACLEで開発をしています。
PRO*COBOLを主流に開発をしている者です。
単刀直入ですが、OBで表示するデータのHEX表示機能を希望します。
さらに上記機能の理由とともにOB操作上、発生した現象を報告します。
PRO*COBOLを使用してシステムを構築する途中に発生した出来事です。
COBOLにはLOW-VALUEが存在します。これはDBに存在するNULLとは異なるものです。
開発中のプログラムではDBのレコードにLOW-VALUEが発生する場合はしばしばあります。
OBでデータを表示した場合、文字の後の空白はすべてカットされた状態で表示されます。
例えば、10byte中5byteの文字列が入っている場合に残り5byteは空白かLOW-VALUEかの判断が出来ません。
さらに、LOW-VALUEが入っていた場合、対象レコードはOB上でデータの更新が全く出来ない状態になってしまいます。
よって更新処理と削除処理が出来ません。
ＳＱＬを実行すれば更新・削除が出来ます。（LOW-VALUEが入っていない項目を抽出条件とする）
余談ですがACCESSの場合は存在するデータの後ろの空白は取り除いていません。LOW-VALUEが入っていたらすぐに見て解りました。データの更新・削除も可能でした。
LOW-VALUEが絡む現象がもう１つあります。
例えば、LOW-VALUEが入っているデータがキーだとします。
(キー長10byte文字型)
"_"をLOW-VALUEとします。
文字列 ABCDEF____
HEX1 4444440000
HEX2 1234560000
このデータと、LOW-VALUEが存在しないデータをINSERTします。
"~"を半角スペースとします
文字列 ABCDEF~~~~
HEX1 4444442222
HEX2 1234560000
この２つのデータは異なるものなのでキーは重複しません。
しかし、OBでは表示が同じになります。
（LOW-VALUEはバイトに文字がが存在しない意味となり、空白はカットされるため）
この場合データは１行しか表示されず、レコードにカーソルを移動させたりすると表示されるデータの中身が様々な表示になります（表示レコードが可変する）。
上記理由により、HEX表示機能か、あるいは空白削除機能の排除を希望します。
以上、宜しく御願いします。
返信を投稿
OB
初音玲
>ORACLEで開発をしています。
>PRO*COBOLを主流に開発をしている者です。
大変ですね。
ObjectBrowserの開発者でも関係者でもないので、単なる技術的好奇心からですが、
ちょっと質問させていただきます。
>COBOLにはLOW-VALUEが存在します。これはDBに存在するNULLとは異なるものです。
>開発中のプログラムではDBのレコードにLOW-VALUEが発生する場合はしばしばあります。
>OBでデータを表示した場合、文字の後の空白はすべてカットされた状態で表示されます。
>例えば、10byte中5byteの文字列が入っている場合に残り5byteは空白かLOW-VALUEかの
>判断が出来ません。
それって、LOW-VALUEなのにカットされるということでしょうか？
「LOW-VALUEはNULLと異なるもの」、「文字の後の空白はすべてカットされた状態」
という記載からすると、LOW-VALUEなるものを空白と同等に扱ってしまうって点に
まず問題があるのかなぁといったところですよね。
#質問の後半に
#>（LOW-VALUEはバイトに文字がが存在しない意味となり、空白はカットされるため）
#という事なので、両方ともカットされるって事でいいのかな。
文字列って事は、VARCHAR2とかCHARって事ですよね。その中に文字列じゃないもの
を設定しているときにどのように表示したら良いだろう考えてしまいました。
そのLOW-VALUEをSQL*Plusなどで検索したり表示したりするとどのように見えるの
でしょうか。
あと、SQL*PlusでLOW-VALUEを扱う方法ってあるのでしょうか？
まったく個人的な意見ですが、COBOLのLOW-VALUEってある種のNULLですよね。
NULLがあるのだから、それ以外に同じようなLOW-VALUEを使う意味ってのがない気も
します。
COBOLで書かれたホストのシステムをOracleを使ったものに作り直した事も何件かあ
りますが、これといって特にNULL以外にLOW-VALUEが欲しいと思う局面に出会った事
もなかったので。
>上記理由により、HEX表示機能か、あるいは空白削除機能の排除を希望します。
実現するのならば、HEX表示機能にしても空白削除抑止機能にしても、設定（やボタ
ン）によって切り替えられるようにして、現在の使い勝手も残して欲しいです。
だって、CHAR型の後ろ空白なんてGUIじゃ邪魔ですから。
>PRO*COBOLを主流に開発をしている者です。
大変ですね。
ObjectBrowserの開発者でも関係者でもないので、単なる技術的好奇心からですが、
ちょっと質問させていただきます。
>COBOLにはLOW-VALUEが存在します。これはDBに存在するNULLとは異なるものです。
>開発中のプログラムではDBのレコードにLOW-VALUEが発生する場合はしばしばあります。
>OBでデータを表示した場合、文字の後の空白はすべてカットされた状態で表示されます。
>例えば、10byte中5byteの文字列が入っている場合に残り5byteは空白かLOW-VALUEかの
>判断が出来ません。
それって、LOW-VALUEなのにカットされるということでしょうか？
「LOW-VALUEはNULLと異なるもの」、「文字の後の空白はすべてカットされた状態」
という記載からすると、LOW-VALUEなるものを空白と同等に扱ってしまうって点に
まず問題があるのかなぁといったところですよね。
#質問の後半に
#>（LOW-VALUEはバイトに文字がが存在しない意味となり、空白はカットされるため）
#という事なので、両方ともカットされるって事でいいのかな。
文字列って事は、VARCHAR2とかCHARって事ですよね。その中に文字列じゃないもの
を設定しているときにどのように表示したら良いだろう考えてしまいました。
そのLOW-VALUEをSQL*Plusなどで検索したり表示したりするとどのように見えるの
でしょうか。
あと、SQL*PlusでLOW-VALUEを扱う方法ってあるのでしょうか？
まったく個人的な意見ですが、COBOLのLOW-VALUEってある種のNULLですよね。
NULLがあるのだから、それ以外に同じようなLOW-VALUEを使う意味ってのがない気も
します。
COBOLで書かれたホストのシステムをOracleを使ったものに作り直した事も何件かあ
りますが、これといって特にNULL以外にLOW-VALUEが欲しいと思う局面に出会った事
もなかったので。
>上記理由により、HEX表示機能か、あるいは空白削除機能の排除を希望します。
実現するのならば、HEX表示機能にしても空白削除抑止機能にしても、設定（やボタ
ン）によって切り替えられるようにして、現在の使い勝手も残して欲しいです。
だって、CHAR型の後ろ空白なんてGUIじゃ邪魔ですから。
返信を投稿
OB
Take
こんにちは。
お答えします。
>#質問の後半に
>#>（LOW-VALUEはバイトに文字がが存在しない意味となり、空白はカットされるため）
>#という事なので、両方ともカットされるって事でいいのかな。
まったくその通りです。表示上では同じです。
>文字列って事は、VARCHAR2とかCHARって事ですよね。その中に文字列じゃないもの
>を設定しているときにどのように表示したら良いだろう考えてしまいました。
>そのLOW-VALUEをSQL*Plusなどで検索したり表示したりするとどのように見えるの
>でしょうか。
>あと、SQL*PlusでLOW-VALUEを扱う方法ってあるのでしょうか？
SQLでは、HEX表示する関数が存在します。それを使えば可能です。
関数名は忘れました。
>まったく個人的な意見ですが、COBOLのLOW-VALUEってある種のNULLですよね。
>NULLがあるのだから、それ以外に同じようなLOW-VALUEを使う意味ってのがない気も
>します。
多少扱いが違います。
NULLというのはDB上の扱いになります。
しかしLOW-VALUEはCOBOL上のもので、文字を格納するためのバイトは確保するが中身が存在しない状態です。
そのため、親記事の例ではHEX1とHEX2という表現で表しました。
>COBOLで書かれたホストのシステムをOracleを使ったものに作り直した事も何件かあ
>りますが、これといって特にNULL以外にLOW-VALUEが欲しいと思う局面に出会った事
>もなかったので。
データとしてLOW-VALUEが欲しいと言う人はまず少ないでしょう。
これは、開発途中のテストデータから発生することが多く、デバッグの効率を向上させたいが為に提案しました。
>実現するのならば、HEX表示機能にしても空白削除抑止機能にしても、設定（やボタ
>ン）によって切り替えられるようにして、現在の使い勝手も残して欲しいです。
切り替え可能の方が良さそうですね。
空白をカットして表示した場合に区別できれば問題はありません。
お答えします。
>#質問の後半に
>#>（LOW-VALUEはバイトに文字がが存在しない意味となり、空白はカットされるため）
>#という事なので、両方ともカットされるって事でいいのかな。
まったくその通りです。表示上では同じです。
>文字列って事は、VARCHAR2とかCHARって事ですよね。その中に文字列じゃないもの
>を設定しているときにどのように表示したら良いだろう考えてしまいました。
>そのLOW-VALUEをSQL*Plusなどで検索したり表示したりするとどのように見えるの
>でしょうか。
>あと、SQL*PlusでLOW-VALUEを扱う方法ってあるのでしょうか？
SQLでは、HEX表示する関数が存在します。それを使えば可能です。
関数名は忘れました。
>まったく個人的な意見ですが、COBOLのLOW-VALUEってある種のNULLですよね。
>NULLがあるのだから、それ以外に同じようなLOW-VALUEを使う意味ってのがない気も
>します。
多少扱いが違います。
NULLというのはDB上の扱いになります。
しかしLOW-VALUEはCOBOL上のもので、文字を格納するためのバイトは確保するが中身が存在しない状態です。
そのため、親記事の例ではHEX1とHEX2という表現で表しました。
>COBOLで書かれたホストのシステムをOracleを使ったものに作り直した事も何件かあ
>りますが、これといって特にNULL以外にLOW-VALUEが欲しいと思う局面に出会った事
>もなかったので。
データとしてLOW-VALUEが欲しいと言う人はまず少ないでしょう。
これは、開発途中のテストデータから発生することが多く、デバッグの効率を向上させたいが為に提案しました。
>実現するのならば、HEX表示機能にしても空白削除抑止機能にしても、設定（やボタ
>ン）によって切り替えられるようにして、現在の使い勝手も残して欲しいです。
切り替え可能の方が良さそうですね。
空白をカットして表示した場合に区別できれば問題はありません。
返信を投稿
OB
こけもも
後スペースのあるなしを区別したいのであれば、varchar2 型を使えばよろしいのでは？
char 型に low-value ( chr(0) の事ですよね )を入れるのは次の開発や保守に余計な
混乱を与えると思います。というか実際過去に混乱しました。
ちなみに varchar2 型ならば OOB でもある程度区別つきますよ。
参照したいだけならビューを作って確認という手もありますし。
create view employee_dmp as
select rawtohex(last_name) from employee
とか。
char 型に low-value ( chr(0) の事ですよね )を入れるのは次の開発や保守に余計な
混乱を与えると思います。というか実際過去に混乱しました。
ちなみに varchar2 型ならば OOB でもある程度区別つきますよ。
参照したいだけならビューを作って確認という手もありますし。
create view employee_dmp as
select rawtohex(last_name) from employee
とか。
返信を投稿
OB
Take
こんにちは。
>後スペースのあるなしを区別したいのであれば、varchar2 型を使えばよろしいのでは？
>char 型に low-value ( chr(0) の事ですよね )を入れるのは次の開発や保守に余計な
>混乱を与えると思います。というか実際過去に混乱しました。
私共も過去に混乱しました。
しかし、COBOLで開発上LOW-VALUEは発生する可能性があります。
現在COBOLのレコードでXタイプを表す項目はChar型で定義する規則で開発しています。
Varchar2型を使用することは出来ません。
レス記事でも述べましたが、発生して困るときはデバッグ時です。
動作テストして発生したデータがLOW-VALUEを含む場合もあります。
親記事でも述べましたが空白カットによってデータが正常に表示されません。
更新・削除処理も出来ません。
その部分が修正されれば問題はありませんが・・・。
>後スペースのあるなしを区別したいのであれば、varchar2 型を使えばよろしいのでは？
>char 型に low-value ( chr(0) の事ですよね )を入れるのは次の開発や保守に余計な
>混乱を与えると思います。というか実際過去に混乱しました。
私共も過去に混乱しました。
しかし、COBOLで開発上LOW-VALUEは発生する可能性があります。
現在COBOLのレコードでXタイプを表す項目はChar型で定義する規則で開発しています。
Varchar2型を使用することは出来ません。
レス記事でも述べましたが、発生して困るときはデバッグ時です。
動作テストして発生したデータがLOW-VALUEを含む場合もあります。
親記事でも述べましたが空白カットによってデータが正常に表示されません。
更新・削除処理も出来ません。
その部分が修正されれば問題はありませんが・・・。
返信を投稿
OB
初音玲
スレッドが２つに枝分かれしたので、こっちの枝に乗り換えました。
>>後スペースのあるなしを区別したいのであれば、varchar2 型を使えばよろしいのでは？
>>char 型に low-value ( chr(0) の事ですよね )を入れるのは次の開発や保守に余計な
>>混乱を与えると思います。というか実際過去に混乱しました。
>私共も過去に混乱しました。
>しかし、COBOLで開発上LOW-VALUEは発生する可能性があります。
>現在COBOLのレコードでXタイプを表す項目はChar型で定義する規則で開発しています。
>Varchar2型を使用することは出来ません。
今後もLOW-VALUEを扱うのであれば、その規則自体を見直してみる必要も
あるかもしれませんよ。
あとは、トリガーでLOW-VALUEのみはNULL、後ろLOW-VALUEは除去、なん
て仕組みを作って、データ投入時にLOW-VALUEの混入を除去し、もちろん
参照側でもLOW-VALUEを前提としない...というのもアリかも。
>レス記事でも述べましたが、発生して困るときはデバッグ時です。
>動作テストして発生したデータがLOW-VALUEを含む場合もあります。
SELECT RAWTOHEX(hogehoge) FROM hoge
という感じでSQL*Plusのように16進数にして表示すれば、Object Browser
でも表示可能なようです。
問題は、更新・削除時か。。。
>>後スペースのあるなしを区別したいのであれば、varchar2 型を使えばよろしいのでは？
>>char 型に low-value ( chr(0) の事ですよね )を入れるのは次の開発や保守に余計な
>>混乱を与えると思います。というか実際過去に混乱しました。
>私共も過去に混乱しました。
>しかし、COBOLで開発上LOW-VALUEは発生する可能性があります。
>現在COBOLのレコードでXタイプを表す項目はChar型で定義する規則で開発しています。
>Varchar2型を使用することは出来ません。
今後もLOW-VALUEを扱うのであれば、その規則自体を見直してみる必要も
あるかもしれませんよ。
あとは、トリガーでLOW-VALUEのみはNULL、後ろLOW-VALUEは除去、なん
て仕組みを作って、データ投入時にLOW-VALUEの混入を除去し、もちろん
参照側でもLOW-VALUEを前提としない...というのもアリかも。
>レス記事でも述べましたが、発生して困るときはデバッグ時です。
>動作テストして発生したデータがLOW-VALUEを含む場合もあります。
SELECT RAWTOHEX(hogehoge) FROM hoge
という感じでSQL*Plusのように16進数にして表示すれば、Object Browser
でも表示可能なようです。
問題は、更新・削除時か。。。
返信を投稿
OB
Take
こんにちは。
>今後もLOW-VALUEを扱うのであれば、その規則自体を見直してみる必要も
>あるかもしれませんよ。
基本的にLOW-VALUEをDB上に存在させておく訳にはいきません。
システムリリース時にはLOW-VALUEを発生させないシステムに仕上げます。
>SELECT RAWTOHEX(hogehoge) FROM hoge
>という感じでSQL*Plusのように16進数にして表示すれば、Object Browser
>でも表示可能なようです。
・・・・仕方ないかも知れませんが、見にくいですよね。コレ。
LOW-VALUEの判断は出来ますが。
更新・削除処理もSQLで何とかなります。
LOW-VALUEの判断をSQLでやるならば、更新・削除処理もSQLでやらざる得ません。
この機能をテーブルデータ表示時に欲しいですね。
>今後もLOW-VALUEを扱うのであれば、その規則自体を見直してみる必要も
>あるかもしれませんよ。
基本的にLOW-VALUEをDB上に存在させておく訳にはいきません。
システムリリース時にはLOW-VALUEを発生させないシステムに仕上げます。
>SELECT RAWTOHEX(hogehoge) FROM hoge
>という感じでSQL*Plusのように16進数にして表示すれば、Object Browser
>でも表示可能なようです。
・・・・仕方ないかも知れませんが、見にくいですよね。コレ。
LOW-VALUEの判断は出来ますが。
更新・削除処理もSQLで何とかなります。
LOW-VALUEの判断をSQLでやるならば、更新・削除処理もSQLでやらざる得ません。
この機能をテーブルデータ表示時に欲しいですね。
返信を投稿
OB