■SI Object Browser 掲示板
|
ユーザの皆様、開発者、サポート担当者の交流のための掲示板です! ユーザーの皆様同士で教え合ったりもできる交流の場にしたいと思っていますので、相互協力をよろしくお願いします。 なお、過去に同じようなQ&Aがあるケースも多いので、投稿前にキーワード検索してみてください。 |
|
| ※各投稿のカラーは対象となる製品に対応しています。【■…OB ■…OBER ■…全般 ■…その他】 ※ライセンスに関するお問合せにつきましては、お問い合わせページよりご連絡いただきますようお願いいたします。 ※誹謗中傷や公序良俗に反する書き込みはご遠慮ください。運営側の判断によりメッセージを削除する場合があります。 ※環境依存や技術的調査が必要な問題については掲示板上ではお答えしかねます。ご了承ください。 | |
検索オプション
タケP
V7.0を使用しています。
データを条件指定で絞り込んだ後、値の更新をおこない
たいのですが、セルがロック?されてしまって出来ません。
どこかオプションの設定で解除できるのでしょうか?。
初歩的な質問で済みませんが、どなたか教えて下さいませ。
データを条件指定で絞り込んだ後、値の更新をおこない
たいのですが、セルがロック?されてしまって出来ません。
どこかオプションの設定で解除できるのでしょうか?。
初歩的な質問で済みませんが、どなたか教えて下さいませ。
返信を投稿
OB
後迫@SI
こんばんは
後迫@SIです。
3点ほど確認したい事があるのですがよろしいでしょうか?
①「結果を編集可能にする」ボタン(データタブにある鉛筆のアイコンです)
は押されていますでしょうか?
②条件指定して絞り込みした後に編集できなくなるということですが、
条件指定する前は編集可能なのでしょうか?
③SQL実行画面からSELECT文でデータを取り出し、編集することは可能でしょうか?
よろしくお願いいたします。
後迫@SIです。
3点ほど確認したい事があるのですがよろしいでしょうか?
①「結果を編集可能にする」ボタン(データタブにある鉛筆のアイコンです)
は押されていますでしょうか?
②条件指定して絞り込みした後に編集できなくなるということですが、
条件指定する前は編集可能なのでしょうか?
③SQL実行画面からSELECT文でデータを取り出し、編集することは可能でしょうか?
よろしくお願いいたします。
返信を投稿
OB
タケP
さっそくの回答ありがとうございます。宜しくお願い致します。
>3点ほど確認したい事があるのですがよろしいでしょうか?
>
>①「結果を編集可能にする」ボタン(データタブにある鉛筆のアイコンです)
> は押されていますでしょうか?
押してありました。条件指定して抽出後に一度解除してから再度押したところ、
「この結果セットには書き込み出来ません。」とエラーになりました。
条件指定しない全件表示状態の場合には、解除後押下出来ました。
>②条件指定して絞り込みした後に編集できなくなるということですが、
> 条件指定する前は編集可能なのでしょうか?
条件指定する前(全件)の場合は、編集可能です。
>③SQL実行画面からSELECT文でデータを取り出し、編集することは可能でしょうか?
なんと、SQL実行結果を編集出来るんですか。バリバリ編集出来ました。
今まではテーブルのデータ欄で全件表示させてからガーッとスクロールさせて
対象データまでたどりついてから更新していました(数万件データがあるともう
スクロールだけで数十秒かかり、もう大変!)。SQL実行画面でSELECT * FROM TABLE
WHERE~ ;で抽出してから操作するだけでも、作業効率は格段アップです。ありが
とうございます。
>3点ほど確認したい事があるのですがよろしいでしょうか?
>
>①「結果を編集可能にする」ボタン(データタブにある鉛筆のアイコンです)
> は押されていますでしょうか?
押してありました。条件指定して抽出後に一度解除してから再度押したところ、
「この結果セットには書き込み出来ません。」とエラーになりました。
条件指定しない全件表示状態の場合には、解除後押下出来ました。
>②条件指定して絞り込みした後に編集できなくなるということですが、
> 条件指定する前は編集可能なのでしょうか?
条件指定する前(全件)の場合は、編集可能です。
>③SQL実行画面からSELECT文でデータを取り出し、編集することは可能でしょうか?
なんと、SQL実行結果を編集出来るんですか。バリバリ編集出来ました。
今まではテーブルのデータ欄で全件表示させてからガーッとスクロールさせて
対象データまでたどりついてから更新していました(数万件データがあるともう
スクロールだけで数十秒かかり、もう大変!)。SQL実行画面でSELECT * FROM TABLE
WHERE~ ;で抽出してから操作するだけでも、作業効率は格段アップです。ありが
とうございます。
返信を投稿
OB
タケP
次々と済みません。
時間があったのでこの掲示板をすみからすみまで
読んでたんですが、過去の発言で「データタブ上のデータを
更新できない」というKAMAさんの発言がありまして、参照させて
いただいたところ、項目名を大文字で記述したらこちらも
更新出来ました。バンザイです。色々とありがとうございました。
今回は初投稿でしたが、今後もお世話になりますので宜しくお願い
いたします。
時間があったのでこの掲示板をすみからすみまで
読んでたんですが、過去の発言で「データタブ上のデータを
更新できない」というKAMAさんの発言がありまして、参照させて
いただいたところ、項目名を大文字で記述したらこちらも
更新出来ました。バンザイです。色々とありがとうございました。
今回は初投稿でしたが、今後もお世話になりますので宜しくお願い
いたします。
返信を投稿
OB
後迫@SI
こんばんは
後迫@SIです。
>時間があったのでこの掲示板をすみからすみまで
>読んでたんですが、過去の発言で「データタブ上のデータを
>更新できない」というKAMAさんの発言がありまして、参照させて
>いただいたところ、項目名を大文字で記述したらこちらも
>更新出来ました。バンザイです。色々とありがとうございました。
おっしゃる通り、過去に同様の不具合をいただいておりました。
大変申し訳ございません。
対応方法は条件でテーブル項目名を大文字で記述する方法と、
もうひとつはオプションにて「データ編集時の自動COMMITを行わない」の
チェックボックスをはずしていただく方法のどちらかだという事です。
この不具合に関しましては次期バージョン8.0にて修正させていただく予定です。
>今回は初投稿でしたが、今後もお世話になりますので宜しくお願い
>いたします。
こちらこそ宜しくお願いいたします。
みなさまからのご質問お待ちしております。
後迫@SIです。
>時間があったのでこの掲示板をすみからすみまで
>読んでたんですが、過去の発言で「データタブ上のデータを
>更新できない」というKAMAさんの発言がありまして、参照させて
>いただいたところ、項目名を大文字で記述したらこちらも
>更新出来ました。バンザイです。色々とありがとうございました。
おっしゃる通り、過去に同様の不具合をいただいておりました。
大変申し訳ございません。
対応方法は条件でテーブル項目名を大文字で記述する方法と、
もうひとつはオプションにて「データ編集時の自動COMMITを行わない」の
チェックボックスをはずしていただく方法のどちらかだという事です。
この不具合に関しましては次期バージョン8.0にて修正させていただく予定です。
>今回は初投稿でしたが、今後もお世話になりますので宜しくお願い
>いたします。
こちらこそ宜しくお願いいたします。
みなさまからのご質問お待ちしております。
返信を投稿
OB
こんばんは
後迫@SIです。
みなさまにお知らせがあります。
Ver.8のリリースに先駆け「Ver.8情報のページ」をつくりました。
今は、リリース前の情報ということで動作環境と新機能しかない
とてつもなく寂しいページですがどんどんリニューアルしていく予定です。
(あたたかい目でみまもってやって下さい。)
Object Browserの製品紹介のページにリンクがはってあります。
購入予定の方、興味のある方は是非チェックしてみて下さい。
よろしくお願いいたします。
後迫@SIです。
みなさまにお知らせがあります。
Ver.8のリリースに先駆け「Ver.8情報のページ」をつくりました。
今は、リリース前の情報ということで動作環境と新機能しかない
とてつもなく寂しいページですがどんどんリニューアルしていく予定です。
(あたたかい目でみまもってやって下さい。)
Object Browserの製品紹介のページにリンクがはってあります。
購入予定の方、興味のある方は是非チェックしてみて下さい。
よろしくお願いいたします。
返信を投稿
OB
NTJ会長
OBERの出力するSQLの設定についてお尋ねします。
OBERでフォワードエンジニアリング機能を使用すると、
各テーブル項目が全て、ダブルコーテーションで囲まれた構造になります。
業務の都合上、ダブルコーテーションで囲まないように設定することは出来ないのでしょか?
テーブル名に関しては「名前を引用符で囲む」の設定で切り替えが出来るようですが・・・
OBERでフォワードエンジニアリング機能を使用すると、
各テーブル項目が全て、ダブルコーテーションで囲まれた構造になります。
業務の都合上、ダブルコーテーションで囲まないように設定することは出来ないのでしょか?
テーブル名に関しては「名前を引用符で囲む」の設定で切り替えが出来るようですが・・・
返信を投稿
OBER
後迫@SI
こんばんは
後迫@SIと申します。
以下の手順で設定を変更していただけますでしょうか。
①メニューの「ツール」から「オプション」を選択
②右下にある「現在のモデルを設定変更」ボタンを押す
③「データベース」タブにある「名前を引用符で囲む」のチェックをはずす
④「OK」ボタンを押す
①~④の手順を実行していただければ、
テーブル項目が引用符で囲まれなくなると思います。
どうぞよろしくお願いたします。
>OBERの出力するSQLの設定についてお尋ねします。
>
>OBERでフォワードエンジニアリング機能を使用すると、
>各テーブル項目が全て、ダブルコーテーションで囲まれた構造になります。
>業務の都合上、ダブルコーテーションで囲まないように設定することは出来ないのでし>ょか?
>
>テーブル名に関しては「名前を引用符で囲む」の設定で切り替えが出来るようです
>が・・・
後迫@SIと申します。
以下の手順で設定を変更していただけますでしょうか。
①メニューの「ツール」から「オプション」を選択
②右下にある「現在のモデルを設定変更」ボタンを押す
③「データベース」タブにある「名前を引用符で囲む」のチェックをはずす
④「OK」ボタンを押す
①~④の手順を実行していただければ、
テーブル項目が引用符で囲まれなくなると思います。
どうぞよろしくお願いたします。
>OBERの出力するSQLの設定についてお尋ねします。
>
>OBERでフォワードエンジニアリング機能を使用すると、
>各テーブル項目が全て、ダブルコーテーションで囲まれた構造になります。
>業務の都合上、ダブルコーテーションで囲まないように設定することは出来ないのでし>ょか?
>
>テーブル名に関しては「名前を引用符で囲む」の設定で切り替えが出来るようです
>が・・・
返信を投稿
OBER
NTJ会長
[後迫@SI]
>こんばんは
>後迫@SIと申します。
お手数をおかけします・・・
>以下の手順で設定を変更していただけますでしょうか。
>①メニューの「ツール」から「オプション」を選択
>②右下にある「現在のモデルを設定変更」ボタンを押す
>③「データベース」タブにある「名前を引用符で囲む」のチェックをはずす
>④「OK」ボタンを押す
その手順は、既に試してみました・・・
結果として、「名前を引用符で囲む」のチェックの有無で変化したのは、
「テーブル項目」ではなく、「テーブル名」だけでした・・・
なにか設定に誤りがあるのでしょうか?
>こんばんは
>後迫@SIと申します。
お手数をおかけします・・・
>以下の手順で設定を変更していただけますでしょうか。
>①メニューの「ツール」から「オプション」を選択
>②右下にある「現在のモデルを設定変更」ボタンを押す
>③「データベース」タブにある「名前を引用符で囲む」のチェックをはずす
>④「OK」ボタンを押す
その手順は、既に試してみました・・・
結果として、「名前を引用符で囲む」のチェックの有無で変化したのは、
「テーブル項目」ではなく、「テーブル名」だけでした・・・
なにか設定に誤りがあるのでしょうか?
返信を投稿
OBER
後迫@SI
こんばんは後迫@SIです。
返信が遅れてしまい申し訳ございません。
テーブル項目が小文字(または小文字混り)になっていないでしょうか?
テーブル項目が小文字になっている場合は引用符で囲んでしまいますので、
その場合は、大文字に変更していただく必要があります。
ツールメニューのオプションを開いていただき、
操作タブにある「英字の扱い」(物理名の方)を大文字にしていただければ、
小文字で入力はできなくなります。
どうぞよろしくお願いいたします。
返信が遅れてしまい申し訳ございません。
テーブル項目が小文字(または小文字混り)になっていないでしょうか?
テーブル項目が小文字になっている場合は引用符で囲んでしまいますので、
その場合は、大文字に変更していただく必要があります。
ツールメニューのオプションを開いていただき、
操作タブにある「英字の扱い」(物理名の方)を大文字にしていただければ、
小文字で入力はできなくなります。
どうぞよろしくお願いいたします。
返信を投稿
OBER
NTJ会長
了解しました。
フィールド名に小文字を使用している場合には、ダブルコーテションが外せないということですね?
規約上、大小文字混じりのフィールド名付与をする必要がありますので、
OBERのフォワードは、今回は使用不能ということで了解いたしました。
フィールド名に小文字を使用している場合には、ダブルコーテションが外せないということですね?
規約上、大小文字混じりのフィールド名付与をする必要がありますので、
OBERのフォワードは、今回は使用不能ということで了解いたしました。
返信を投稿
OBER
初音玲
[NTJ会長]
>規約上、大小文字混じりのフィールド名付与をする必要がありますので、
>OBERのフォワードは、今回は使用不能ということで了解いたしました。
ダブルクォートで囲わないとOracle上で、すべて大文字扱いになってしまうと
思うのですが(OBERではなくOracleの仕様として)、違いますでしょうか?
ER図上は大小文字交じりでOracle上は気にしないという事であれば、良いので
しょうが、そうするとリバースしてきたときに、すべて大文字になってしまう
と思います。
>規約上、大小文字混じりのフィールド名付与をする必要がありますので、
>OBERのフォワードは、今回は使用不能ということで了解いたしました。
ダブルクォートで囲わないとOracle上で、すべて大文字扱いになってしまうと
思うのですが(OBERではなくOracleの仕様として)、違いますでしょうか?
ER図上は大小文字交じりでOracle上は気にしないという事であれば、良いので
しょうが、そうするとリバースしてきたときに、すべて大文字になってしまう
と思います。
返信を投稿
OBER
NTJ会長
>ダブルクォートで囲わないとOracle上で、すべて大文字扱いになってしまうと
>思うのですが(OBERではなくOracleの仕様として)、違いますでしょうか?
その通りです。
「生成されるER図を、設計書として使用する都合上」、
ER図上でのみ、大文字小文字を使い分けたいのであって、
生成されるSQL及び、生成されるDBテーブル上では、全て大文字で構いません。
(というか、元々、そういう仕様ですので。)
>ER図上は大小文字交じりでOracle上は気にしないという事であれば、良いので
>しょうが、そうするとリバースしてきたときに、すべて大文字になってしまう
>と思います。
元々、「設計書」としてER図を簡易に生成できるツールとして使用したかったので、
リバース時に全て大文字になる事自体、問題は無いんです。
・・・と、いうか、完成物のシステムは、多分相当な苦労をしないと、
OBERでは正しくリバースされないと思われますので。
また、OBERのフォワードの機能も「製品」としては使用しません。
使うのは、生成されるSQLだけですね。(^^;
ご心配は有り難いのですが、元々「一方通行」を前提としての開発ツールとして使ってますので、ご指摘頂いた事項は、全て承知しております。
>思うのですが(OBERではなくOracleの仕様として)、違いますでしょうか?
その通りです。
「生成されるER図を、設計書として使用する都合上」、
ER図上でのみ、大文字小文字を使い分けたいのであって、
生成されるSQL及び、生成されるDBテーブル上では、全て大文字で構いません。
(というか、元々、そういう仕様ですので。)
>ER図上は大小文字交じりでOracle上は気にしないという事であれば、良いので
>しょうが、そうするとリバースしてきたときに、すべて大文字になってしまう
>と思います。
元々、「設計書」としてER図を簡易に生成できるツールとして使用したかったので、
リバース時に全て大文字になる事自体、問題は無いんです。
・・・と、いうか、完成物のシステムは、多分相当な苦労をしないと、
OBERでは正しくリバースされないと思われますので。
また、OBERのフォワードの機能も「製品」としては使用しません。
使うのは、生成されるSQLだけですね。(^^;
ご心配は有り難いのですが、元々「一方通行」を前提としての開発ツールとして使ってますので、ご指摘頂いた事項は、全て承知しております。
返信を投稿
OBER
さぼ
ストアドプロシージャの出力引数に以下の様な、ユーザ指定型のレコードセットを格納する方法を調べています。ユーザ指定と言うのは例えばカーソル(テーブルを等結合する為)や任意のデータ型(配列)です。
Oracle8iの「アプリケーション開発者ガイド基礎編」(9-9ページ)より
CREATE PROCEDURE Get_emp_rec (
Emp_number IN Emp_tab.Empno%TYPE,
Emp_ret OUT Emp_tab%ROWTYPE
) AS
BEGIN
SELECT Empno, Ename, Job, Mgr, Hiredate, Sal, Comm, Deptno
INTO Emp_ret
FROM Emp_tab
WHERE Empno = Emp_number;
END;
/
出力引数の「Emp_tab」をユーザ指定型にできないでしょうか?
・ASとBEGINの間にカーソル宣言して「Emp_tab」の代わりにカーソル名を指定したら
コンパイルエラーになってしまいました。
Oracle8iの「アプリケーション開発者ガイド基礎編」(9-9ページ)より
CREATE PROCEDURE Get_emp_rec (
Emp_number IN Emp_tab.Empno%TYPE,
Emp_ret OUT Emp_tab%ROWTYPE
) AS
BEGIN
SELECT Empno, Ename, Job, Mgr, Hiredate, Sal, Comm, Deptno
INTO Emp_ret
FROM Emp_tab
WHERE Empno = Emp_number;
END;
/
出力引数の「Emp_tab」をユーザ指定型にできないでしょうか?
・ASとBEGINの間にカーソル宣言して「Emp_tab」の代わりにカーソル名を指定したら
コンパイルエラーになってしまいました。
返信を投稿
OB
はじめ
パッケージにカーソル(配列)を宣言し、
出力引数にそのレコード型を指定する方法があります。
CREATE PACKAGE PACKAGE1
AS
CURSOR Emp_cur(Emp_number IN Emp_tab.Empno%TYPE) IS
BEGIN
SELECT Empno, Ename, Job, Mgr, Hiredate, Sal, Comm, Deptno
FROM Emp_tab
WHERE Empno = Emp_number;
END;
END PACKAGE1;
/
CREATE PROCEDURE Get_emp_rec(
Emp_rec OUT PACKAGE1.Emp_cur%ROWTYPE
) AS
BEGIN
OPEN PACKAGE1.Emp_cur;
FETCH PACKAGE1.Emp_cur INTO Emp_rec;
CLOSE PACKAGE1.Emp_cur;
END;
/
こんな感じで。
出力引数にそのレコード型を指定する方法があります。
CREATE PACKAGE PACKAGE1
AS
CURSOR Emp_cur(Emp_number IN Emp_tab.Empno%TYPE) IS
BEGIN
SELECT Empno, Ename, Job, Mgr, Hiredate, Sal, Comm, Deptno
FROM Emp_tab
WHERE Empno = Emp_number;
END;
END PACKAGE1;
/
CREATE PROCEDURE Get_emp_rec(
Emp_rec OUT PACKAGE1.Emp_cur%ROWTYPE
) AS
BEGIN
OPEN PACKAGE1.Emp_cur;
FETCH PACKAGE1.Emp_cur INTO Emp_rec;
CLOSE PACKAGE1.Emp_cur;
END;
/
こんな感じで。
返信を投稿
OB
さぼ
ASPからoo4oを使いストアドプロシージャを呼び出して、呼び元でカーソルを使いたいのですが
方法が判らず悩んでます。どなたか判る方がいれば教えてください。
単純に、ASPからSQLを実行すればすむ事ですが、処理をブラックボックス化したいので
ストアドプロシージャを使おうと思っています。
方法が判らず悩んでます。どなたか判る方がいれば教えてください。
単純に、ASPからSQLを実行すればすむ事ですが、処理をブラックボックス化したいので
ストアドプロシージャを使おうと思っています。
返信を投稿
OB
ORAえもん
以下のアドレスにoo4oでストアドプロシージャの呼び出し方が載っていましたよ~。
(参考にならなかったらゴメンなさい)
http://homepage2.nifty.com/inform/vbdb/oo4o_paramsp.htm
(参考にならなかったらゴメンなさい)
http://homepage2.nifty.com/inform/vbdb/oo4o_paramsp.htm
返信を投稿
OB
さぼ
返信ありがとうございます。
紹介していただいたページを確認いたしました。
自分なりにも調べてみたのですが、ストアドプロシージャを使って
呼び元がカーソルを使うのは不可能なのではないか、と言う結論になりました。
もし、カーソルのような処理をしたいのなら、oo4oのオブジェクトを使う方法しかないようです。
紹介していただいたページを確認いたしました。
自分なりにも調べてみたのですが、ストアドプロシージャを使って
呼び元がカーソルを使うのは不可能なのではないか、と言う結論になりました。
もし、カーソルのような処理をしたいのなら、oo4oのオブジェクトを使う方法しかないようです。
返信を投稿
OB
うっち~
またまたご質問いたします。
タイトルにも書きました通り、テーブルの作成時にプライマリー制約等の制約をかける方法はありますでしょうか。NULL制約はかけれると思いますが、プライマリーキー制約のかけ方がわかりません。
今は、「constraint」から新規にオブジェクトを作成しております。
以上、ご回答よろしくお願いします。
タイトルにも書きました通り、テーブルの作成時にプライマリー制約等の制約をかける方法はありますでしょうか。NULL制約はかけれると思いますが、プライマリーキー制約のかけ方がわかりません。
今は、「constraint」から新規にオブジェクトを作成しております。
以上、ご回答よろしくお願いします。
返信を投稿
OB
後迫@SI
こんばんは
後迫@SIです。
誠に申し訳ございませんが、
テーブル定義からの作成時に同時に主キー制約を掛けることはできません。
要望として承り今後のバージョンアップの際に対応を検討させていただきます。
よろしくお願いいたします。
>またまたご質問いたします。
>
>タイトルにも書きました通り、テーブルの作成時にプライマリー制約等の制約をかける>方法はありますでしょうか。NULL制約はかけれると思いますが、プライマリーキー制約>のかけ方がわかりません。
>
>今は、「constraint」から新規にオブジェクトを作成しております。
>
>以上、ご回答よろしくお願いします。
後迫@SIです。
誠に申し訳ございませんが、
テーブル定義からの作成時に同時に主キー制約を掛けることはできません。
要望として承り今後のバージョンアップの際に対応を検討させていただきます。
よろしくお願いいたします。
>またまたご質問いたします。
>
>タイトルにも書きました通り、テーブルの作成時にプライマリー制約等の制約をかける>方法はありますでしょうか。NULL制約はかけれると思いますが、プライマリーキー制約>のかけ方がわかりません。
>
>今は、「constraint」から新規にオブジェクトを作成しております。
>
>以上、ご回答よろしくお願いします。
返信を投稿
OB
うっち~
Object Browser で一度作成したテーブルの名前を変更したいのですが、GUIで変更する方法はないのでしょうか。
今は、わからないので、
1.テーブルを削除してつくりなおし。
2.SQLコマンドによりALTER TABLE 文を発行。
のいづれかをしています。
GUIでできれば簡単で良いのですが・・・。
ご回答よろしくお願いします。
今は、わからないので、
1.テーブルを削除してつくりなおし。
2.SQLコマンドによりALTER TABLE 文を発行。
のいづれかをしています。
GUIでできれば簡単で良いのですが・・・。
ご回答よろしくお願いします。
返信を投稿
OB
takka
オブジェクトリスト上で対象のテーブルを選択し、
マウスでワンクリックすると名称が変更できるようですよ。
Windows のエクスプローラのファイル名変更のような感覚です。
マウスでワンクリックすると名称が変更できるようですよ。
Windows のエクスプローラのファイル名変更のような感覚です。
返信を投稿
OB
うっち~
[takka]
>オブジェクトリスト上で対象のテーブルを選択し、
>マウスでワンクリックすると名称が変更できるようですよ。
>Windows のエクスプローラのファイル名変更のような感覚です。
うぉっ!できました~~!
有難うございます。
・・・こんなに簡単にできるんですね・・・。早く質問すればよかった。
>オブジェクトリスト上で対象のテーブルを選択し、
>マウスでワンクリックすると名称が変更できるようですよ。
>Windows のエクスプローラのファイル名変更のような感覚です。
うぉっ!できました~~!
有難うございます。
・・・こんなに簡単にできるんですね・・・。早く質問すればよかった。
返信を投稿
OB
まだまだ初心者
まだまだ初心者の私が投稿するのは失礼とは思いましたがよろしくお願いします。
以下のテーブル定義の場合、
プライマリキーのインデックスと
インデックスとしてのインデックス定義とでは違いがあるのでしょうか。
例えば、“A_NO”には‘01,02,03,04,11,12,23,...’と数字が設定されます。
データすべてを抽出する場合に“WHERE”句に“ A_NO > '00' ”を条件つけをして
インデックス検索にしました。
いろいろな情報からこれで“A_NO”内の昇順に抽出されるもの考えていました。
実際に内容は物理的にはバラバラに登録をされています。
社内の端末からいろいろ検索をしても意図する内容で検索はされます。
が、ユーザの環境ではその都度バラバラに抽出されているようなのです。
今回の開発プロジェクト内にはDBに詳しい方がいまして問い合わせたら、
“保証はされない。”旨の返事でした。
文献やNETによる情報と食い違いました。
本当のところはどうなんでしょうか?
プライマリキーのインデックスだけはこの限りではないのでしょうか?
するとインデックスではないように受けとめてしまいます。
よろしかったらおしえてください。
/*===== テーブル定義 =====*/
CREATE TABLE GTBL_M04 (
A_NO CHAR(2) NOT NULL /* A番号 */
,A_NAME VARCHAR2(20) NOT NULL /* A名称 */
,A_RYAKU VARCHAR2(10) NOT NULL /* A略称 */
,A_KBN CHAR(1) NOT NULL /* A区分 */
,A_KASHO CHAR(7) NOT NULL /* A箇所 */
)
PCTFREE 50 PCTUSED 40 INITRANS 1 MAXTRANS 255
STORAGE (
INITIAL 8.00K NEXT 8.00K MINEXTENTS 1 MAXEXTENTS UNLIMITED
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1
) TABLESPACE USERS_S
/
/*= プライマリインデックス定義 =*/
ALTER TABLE GTBL_M04 ADD CONSTRAINT pk_GTBL_M04 PRIMARY KEY (
A_NO /* A番号 */
) USING INDEX
PCTFREE 5 INITRANS 2 MAXTRANS 255
STORAGE (
INITIAL 8.00K NEXT 8.00K MINEXTENTS 1 MAXEXTENTS UNLIMITED
PCTINCREASE 0 FREELISTS 1
) TABLESPACE INDX
/
以下のテーブル定義の場合、
プライマリキーのインデックスと
インデックスとしてのインデックス定義とでは違いがあるのでしょうか。
例えば、“A_NO”には‘01,02,03,04,11,12,23,...’と数字が設定されます。
データすべてを抽出する場合に“WHERE”句に“ A_NO > '00' ”を条件つけをして
インデックス検索にしました。
いろいろな情報からこれで“A_NO”内の昇順に抽出されるもの考えていました。
実際に内容は物理的にはバラバラに登録をされています。
社内の端末からいろいろ検索をしても意図する内容で検索はされます。
が、ユーザの環境ではその都度バラバラに抽出されているようなのです。
今回の開発プロジェクト内にはDBに詳しい方がいまして問い合わせたら、
“保証はされない。”旨の返事でした。
文献やNETによる情報と食い違いました。
本当のところはどうなんでしょうか?
プライマリキーのインデックスだけはこの限りではないのでしょうか?
するとインデックスではないように受けとめてしまいます。
よろしかったらおしえてください。
/*===== テーブル定義 =====*/
CREATE TABLE GTBL_M04 (
A_NO CHAR(2) NOT NULL /* A番号 */
,A_NAME VARCHAR2(20) NOT NULL /* A名称 */
,A_RYAKU VARCHAR2(10) NOT NULL /* A略称 */
,A_KBN CHAR(1) NOT NULL /* A区分 */
,A_KASHO CHAR(7) NOT NULL /* A箇所 */
)
PCTFREE 50 PCTUSED 40 INITRANS 1 MAXTRANS 255
STORAGE (
INITIAL 8.00K NEXT 8.00K MINEXTENTS 1 MAXEXTENTS UNLIMITED
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1
) TABLESPACE USERS_S
/
/*= プライマリインデックス定義 =*/
ALTER TABLE GTBL_M04 ADD CONSTRAINT pk_GTBL_M04 PRIMARY KEY (
A_NO /* A番号 */
) USING INDEX
PCTFREE 5 INITRANS 2 MAXTRANS 255
STORAGE (
INITIAL 8.00K NEXT 8.00K MINEXTENTS 1 MAXEXTENTS UNLIMITED
PCTINCREASE 0 FREELISTS 1
) TABLESPACE INDX
/
返信を投稿
その他
SEGA
SEGA です。
インデックスはあくまでも検索やテーブル連携用です。
検索結果のデータの並び順とは無関係ですし、
物理的なデータの並び順とも無関係です。
データを特定項目の順序に取り出したければ、
“ORDER BY”句を使って下さい。
インデックスはあくまでも検索やテーブル連携用です。
検索結果のデータの並び順とは無関係ですし、
物理的なデータの並び順とも無関係です。
データを特定項目の順序に取り出したければ、
“ORDER BY”句を使って下さい。
返信を投稿
その他
まだまだ初心者
SEGAさん御教授ありがとうございます。
これに甘えてもう少しお願いします。
ORDER BY が書かれていましたが、
ユーザ先のマシンでは3万件のデータをプライマリキーで行った場合に
メモリー不足でアプリケーションがABENDしたため、
いろいろ調べ“インデックスは、デフォルトは昇順でキー値順に読み込み可能”の言葉を信じて
前メッセージの処置をとりました。(処置は別のデータベースに対して)
データの絞込み条件は無し、
毎日100件~1000件のデータ更新(削除、更新、追加)がオンライン、バッチと行われ
物理的には当然順不同です。
DISTINCTも同様で、管理メーカーからは使用禁止句になっている状況です。
でもユーザからはレスポンスは早くの要求が・・・。
(DISTINCTもメモリー不足でした。)
内部ソートや、ADO.NETのフィルタなども結局便利ではあるがオンラインアプリケーションには向かない便利機能でした。(とにかく時間がかかりすぎ)
ユーザに今の現状をすべて説明して、所要時間的に一番の内部ソートを許してもらっている状況というかそれしかないのです。
データベースの環境は管理メーカーが担当で私どもでには一切情報は教えてもらえません。
以上が私どものプロジェクトの状況でした。
これが得策なのでしょうか??
疑問です。
これに甘えてもう少しお願いします。
ORDER BY が書かれていましたが、
ユーザ先のマシンでは3万件のデータをプライマリキーで行った場合に
メモリー不足でアプリケーションがABENDしたため、
いろいろ調べ“インデックスは、デフォルトは昇順でキー値順に読み込み可能”の言葉を信じて
前メッセージの処置をとりました。(処置は別のデータベースに対して)
データの絞込み条件は無し、
毎日100件~1000件のデータ更新(削除、更新、追加)がオンライン、バッチと行われ
物理的には当然順不同です。
DISTINCTも同様で、管理メーカーからは使用禁止句になっている状況です。
でもユーザからはレスポンスは早くの要求が・・・。
(DISTINCTもメモリー不足でした。)
内部ソートや、ADO.NETのフィルタなども結局便利ではあるがオンラインアプリケーションには向かない便利機能でした。(とにかく時間がかかりすぎ)
ユーザに今の現状をすべて説明して、所要時間的に一番の内部ソートを許してもらっている状況というかそれしかないのです。
データベースの環境は管理メーカーが担当で私どもでには一切情報は教えてもらえません。
以上が私どものプロジェクトの状況でした。
これが得策なのでしょうか??
疑問です。
返信を投稿
その他
初音玲
[まだまだ初心者]
>ORDER BY が書かれていましたが、
>ユーザ先のマシンでは3万件のデータをプライマリキーで行った場合に
>メモリー不足でアプリケーションがABENDしたため、
>いろいろ調べ“インデックスは、デフォルトは昇順でキー値順に読み込み可能”の言葉を
>信じて前メッセージの処置をとりました。(処置は別のデータベースに対して)
確かにINDEXは昇順にならんでいるように見えますが、絞込み条件がない
のであれば、通常、全表検索されるでしょうから、表データの物理順になっ
てしまいます。やはり、確実なのは、ORDER BYです。
なお、INDEXを使っているか全表なのかは、OBを使って実行計画を表示す
ると一目瞭然です。
>データの絞込み条件は無し、
結局のところ、データの絞込みなしでソートした結果が欲しいというのは
どのような処理なのでしょうか。オンラインアプリケーションという事で
すが、3万件のデータを一覧表示するような感じでしょうか。
>DISTINCTも同様で、管理メーカーからは使用禁止句になっている状況です。
管理メーカーとしては、どんなにスキルが低い人間が使ってもレスポンス
の劣化が心配されない機能しか使わせたくない場合が多いようですね。
でも、それは本当にお客様の事を考えた「管理」とは言えませんね。
限られた資源で最大限の能力を維持するというのが本当の管理ですからね。
まずは、データ絞込みは本当に不要なのか、次にORDER BYの作業領域をDB
側で確保する事が本当に出来ないか、最後にクライアント側に持ってきて
からソートする方式の時間でお客様に納得いただけるか、などを検討して
みる必要があると思います。
#どちらかというとOB掲示板ではなく、データベース掲示板ネタですね。
>データベースの環境は管理メーカーが担当で私どもでには一切情報は教えてもらえません。
動的パフォーマンス表だとかSELECT文で検索しちゃえば設定情報などは、
すべて取得できます。もちろん、OBだと画面クリックしていくだけで表示
されます(ただし、上記表に対するSELECT権限が外されていると無理で
すが)。
>ORDER BY が書かれていましたが、
>ユーザ先のマシンでは3万件のデータをプライマリキーで行った場合に
>メモリー不足でアプリケーションがABENDしたため、
>いろいろ調べ“インデックスは、デフォルトは昇順でキー値順に読み込み可能”の言葉を
>信じて前メッセージの処置をとりました。(処置は別のデータベースに対して)
確かにINDEXは昇順にならんでいるように見えますが、絞込み条件がない
のであれば、通常、全表検索されるでしょうから、表データの物理順になっ
てしまいます。やはり、確実なのは、ORDER BYです。
なお、INDEXを使っているか全表なのかは、OBを使って実行計画を表示す
ると一目瞭然です。
>データの絞込み条件は無し、
結局のところ、データの絞込みなしでソートした結果が欲しいというのは
どのような処理なのでしょうか。オンラインアプリケーションという事で
すが、3万件のデータを一覧表示するような感じでしょうか。
>DISTINCTも同様で、管理メーカーからは使用禁止句になっている状況です。
管理メーカーとしては、どんなにスキルが低い人間が使ってもレスポンス
の劣化が心配されない機能しか使わせたくない場合が多いようですね。
でも、それは本当にお客様の事を考えた「管理」とは言えませんね。
限られた資源で最大限の能力を維持するというのが本当の管理ですからね。
まずは、データ絞込みは本当に不要なのか、次にORDER BYの作業領域をDB
側で確保する事が本当に出来ないか、最後にクライアント側に持ってきて
からソートする方式の時間でお客様に納得いただけるか、などを検討して
みる必要があると思います。
#どちらかというとOB掲示板ではなく、データベース掲示板ネタですね。
>データベースの環境は管理メーカーが担当で私どもでには一切情報は教えてもらえません。
動的パフォーマンス表だとかSELECT文で検索しちゃえば設定情報などは、
すべて取得できます。もちろん、OBだと画面クリックしていくだけで表示
されます(ただし、上記表に対するSELECT権限が外されていると無理で
すが)。
返信を投稿
その他
ころちゃん
DBは、Oracleなのかな?と思って書いてますが・・
>例えば、“A_NO”には‘01,02,03,04,11,12,23,...’と数字が設定されます。
>データすべてを抽出する場合に“WHERE”句に“ A_NO > '00' ”を条件つけをして
>インデックス検索にしました。
WHERE句に、プライマリキー項目を指定したからといって、インデックスを使った検索を
行うとは限りません。Oracleのオプティマイザが検索方法を判断します。
Oracleが、全表検索した方が早いと判断した場合は、インデックスがあっても無くても
全表検索します。
どうしても、インデックスを使って欲しい場合、オプティマイザヒントを使って、
インデックスの利用を強要することも可能です。(詳しくは、マニュアル参照)
何となくですが、今回のケースだと..
SELECT /*+ INDEX_ASC(GTBL_M04 pk_GTBL_M04) */
A_NO
FROM GTBL_M04
WHERE A_NO > '00';
で問い合わせれば、欲しい結果が取れそうな気がします。
!注意!今までより、検索時間自体は長くなる可能性がありますので、ご注意ください。
>例えば、“A_NO”には‘01,02,03,04,11,12,23,...’と数字が設定されます。
>データすべてを抽出する場合に“WHERE”句に“ A_NO > '00' ”を条件つけをして
>インデックス検索にしました。
WHERE句に、プライマリキー項目を指定したからといって、インデックスを使った検索を
行うとは限りません。Oracleのオプティマイザが検索方法を判断します。
Oracleが、全表検索した方が早いと判断した場合は、インデックスがあっても無くても
全表検索します。
どうしても、インデックスを使って欲しい場合、オプティマイザヒントを使って、
インデックスの利用を強要することも可能です。(詳しくは、マニュアル参照)
何となくですが、今回のケースだと..
SELECT /*+ INDEX_ASC(GTBL_M04 pk_GTBL_M04) */
A_NO
FROM GTBL_M04
WHERE A_NO > '00';
で問い合わせれば、欲しい結果が取れそうな気がします。
!注意!今までより、検索時間自体は長くなる可能性がありますので、ご注意ください。
返信を投稿
その他