ぴっぴ さん 2015年 06月 04日 09時 55分 36秒

ODP.NETをインストールしたのち、OSQLEDITを実行した際、SQL実行結果が文字化けするようになってしまったのですが、どこかで設定変更する箇所はあるのでしょうか。

Oracle純正のSQLDeveloperでは、同一インスタンスに対して正常に結果を参照できることは、確認済みです。

とし さん 2015年 05月 22日 22時 28分 59秒

>おがわ様
>|でマッチしない側の部分文字列は#fになります。
了解しました。今後はそれを加味してコーディングしようと思います。

実は自分も、あの後Web調査を続けて、
Perl5の正規表現エンジンを手本にしたと言われるECMAScript仕様書に
該当する記述↓を見付けました。
 『|によりスキップされた捕捉括弧は、文字列の代わりにundefined値をとる』
同じくPerl5互換であるSchemeの正規表現エンジンも、
この仕様を遵守しての結果だったんだなぁと、思いました。

このたびは、細々した質問にお答えくださり有難うございました。
OEdit、今後とも大切に使わせていただきます。

ぱおん さん 2015年 05月 21日 23時 12分 19秒

ごめんなさい
マニュアルをよくよんでいませんでした。
できました。
これからおせわになります。

ぱおん さん 2015年 05月 21日 22時 46分 34秒

追記
↓はoeditについてです

ぱおん さん 2015年 05月 21日 22時 41分 08秒

乗り換えを検討しています
自動で拡張子判断によるシンタックスハイライトが有効になっていますが
全て無効にできますか?

おがわ さん 2015年 05月 19日 05時 52分 33秒

>とし さん
ご質問の件、現在の動作が正しい動作です。
|でマッチしない側の部分文字列は#fになります。

とし さん 2015年 05月 16日 01時 50分 23秒

少し訂正です。
先程の投稿の、↓という一文は誤りでした。
『OEdit 6.0.5.8のrxmatch-substring関数は、OEditのGUIと同じく""(空文字列)を返しました。』

確かに、大方は""(空文字列)を返すのですが、何かの拍子に違う文字列を返したり、
たまにOEditが固まったり/落ちたり/以降のマクロ実行に影響を及ぼしたりと、
かなり不安定な様子でした。
対照的に、OEdit 7.5.3.9の挙動は終始安定したものでした。

以上、度重なる投稿の不手際、ここにお詫び申し上げます。

とし さん 2015年 05月 14日 22時 52分 46秒

久し振りの投稿で勝手が分からず、2重投稿になってしまいました。
申し訳ありませんです。

とし さん 2015年 05月 14日 22時 47分 00秒

>おがわ様
OEdit 7.5.3.9にて、修正確認致しました。
いつも迅速に対応して下さり、本当に助かります。
ただ、ちょっと細かい事なのですが、確認させて下さい。

『doc\macro_ref.txt』の説明では、
 (rxmatch-substring <regmatch> <i>)
 マッチした文字列を返します。
 iが省略されるか0の場合、一致した文字列全体を返します。
 iに正の整数が与えられた場合は、i番目の部分文字列を返します。
とある(=必ず文字列が返る)のですが、

サブマッチを用いた正規表現パターンの場合は、
そうならない(#fが返る)場合がある事に気付きました。
具体的には、選言『|』により一部サブマッチが用無しとなる場合です。
(検証コード@参照)
この(#fが返り得る)挙動が、仕様なのか否か、宜しくお願いします。

ちなみに、rxmatch-substring関数の一般的な返り値について、
Web検索してみたのですが、厳密な情報は見付けられませんでした。
同じような事を、FirefoxのJavaScriptと、OEditのGUI置換で試した所、
それぞれ、undefined(JavaScript)、""(空文字列)(OEditのGUI)が返りました。
(検証コードA、B参照)
また、OEdit6.0.5.8のrxmatch-substring関数は、
OEditのGUIと同じく""(空文字列)を返しました。

■検証コード@■
●OEdit 7.5.3.5〜7.5.3.9にて、検証しました。
●OEdit 6.0.5.8では、""(空文字列)が返りました。
(define m (rxmatch #/\b(\d{1,3})\b|\b([0-9A-F]{2})\b/i "fe"))
(write (rxmatch-substring m 1)) ;=>#f

(define m (rxmatch #/\b(\d{1,3})\b|\b([0-9A-F]{2})\b/i "254"))
(write (rxmatch-substring m 2)) ;=>#f

■検証コードA■
●Firefox 37.0.2にて、検証しました。
var m = "fe".match(/\b(\d{1,3})\b|\b([0-9A-F]{2})\b/i);
console.log(m[1]); //=>undefined

var m = "254".match(/\b(\d{1,3})\b|\b([0-9A-F]{2})\b/i);
console.log(m[2]); //=>undefined

■検証B■
●OEdit 6.0.5.8/7.5.3.5〜7.5.3.9にて、検証しました。
OEditのGUIから、↓条件にて、テキスト中の『fe』箇所を正規表現置換。
 検索文字列…\b(\d{1,3})\b|\b([0-9A-F]{2})\b
 置換後の文字列…$1
 大文字・小文字を区別する…×
 →【結果】『fe』が『』(空文字列)に置換された。

OEditのGUIから、↓条件にて、テキスト中の『254』箇所を正規表現置換。
 検索文字列…\b(\d{1,3})\b|\b([0-9A-F]{2})\b
 置換後の文字列…$2
 大文字・小文字を区別する…×
 →【結果】『254』が『』(空文字列)に置換された。

とし さん 2015年 05月 14日 22時 46分 49秒

>おがわ様
OEdit 7.5.3.9にて、修正確認致しました。
いつも迅速に対応して下さり、本当に助かります。
ただ、ちょっと細かい事なのですが、確認させて下さい。

『doc\macro_ref.txt』の説明では、
 (rxmatch-substring <regmatch> <i>)
 マッチした文字列を返します。
 iが省略されるか0の場合、一致した文字列全体を返します。
 iに正の整数が与えられた場合は、i番目の部分文字列を返します。
とある(=必ず文字列が返る)のですが、

サブマッチを用いた正規表現パターンの場合は、
そうならない(#fが返る)場合がある事に気付きました。
具体的には、選言『|』により一部サブマッチが用無しとなる場合です。
(検証コード@参照)
この(#fが返り得る)挙動が、仕様なのか否か、宜しくお願いします。

ちなみに、rxmatch-substring関数の一般的な返り値について、
Web検索してみたのですが、厳密な情報は見付けられませんでした。
同じような事を、FirefoxのJavaScriptと、OEditのGUI置換で試した所、
それぞれ、undefined(JavaScript)、""(空文字列)(OEditのGUI)が返りました。
(検証コードA、B参照)
また、OEdit6.0.5.8のrxmatch-substring関数は、
OEditのGUIと同じく""(空文字列)を返しました。

■検証コード@■
●OEdit 7.5.3.5〜7.5.3.9にて、検証しました。
●OEdit 6.0.5.8では、""(空文字列)が返りました。
(define m (rxmatch #/\b(\d{1,3})\b|\b([0-9A-F]{2})\b/i "fe"))
(write (rxmatch-substring m 1)) ;=>#f

(define m (rxmatch #/\b(\d{1,3})\b|\b([0-9A-F]{2})\b/i "254"))
(write (rxmatch-substring m 2)) ;=>#f

■検証コードA■
●Firefox 37.0.2にて、検証しました。
var m = "fe".match(/\b(\d{1,3})\b|\b([0-9A-F]{2})\b/i);
console.log(m[1]); //=>undefined

var m = "254".match(/\b(\d{1,3})\b|\b([0-9A-F]{2})\b/i);
console.log(m[2]); //=>undefined

■検証B■
●OEdit 6.0.5.8/7.5.3.5〜7.5.3.9にて、検証しました。
OEditのGUIから、↓条件にて、テキスト中の『fe』箇所を正規表現置換。
 検索文字列…\b(\d{1,3})\b|\b([0-9A-F]{2})\b
 置換後の文字列…$1
 大文字・小文字を区別する…×
 →【結果】『fe』が『』(空文字列)に置換された。

OEditのGUIから、↓条件にて、テキスト中の『254』箇所を正規表現置換。
 検索文字列…\b(\d{1,3})\b|\b([0-9A-F]{2})\b
 置換後の文字列…$2
 大文字・小文字を区別する…×
 →【結果】『254』が『』(空文字列)に置換された。

おがわ さん 2015年 05月 07日 22時 26分 35秒

>とし さん
ご報告いただきありがとうございます。
oedit/otbedit最新版で修正しました。

>B.Bさん
ご要望いただきありがとうございます。
文字コードの対応について技術的に可能かどうか検討させていただきます。

B.B さん 2015年 05月 05日 21時 57分 47秒

非常に使い勝手のいいTAB-Editorのotbeditを使わせて貰って有難う御座います

要望なのですが普段海外のMODのテキストでロシア語と中国語を参照する事が多く他のアプリで
文字コード変換をしてからこちらを使用しているのですが、Windows-1251とGB2312を対応していただけるとありがたいです

勝手な要望ですが可能でしたら宜しくお願いします

とし さん 2015年 05月 01日 22時 41分 56秒

OEdit4.8.2.1辺りから、ずっと愛用してます。
OSを2000→XP→7に移してからも、変わらず安定動作してくれていつも助かってます。
このような良質なテキストエディタを提供&メンテを続けて下さり、
本当にありがとうございます。

今回は1つ、Schemeの不具合(?)報告をさせて下さい。
またお時間のある時で構いませんので、修正して頂けたらありがたいです。

■環境■
OEdit 7.5.3.8+Windows 7x64 pro SP1

■症状■
・Schemeのrxmatch-substring関数について、
 <regmatch>オブジェクトから、ゼロ巾の文字列(空文字)を正しく取り出せない。
 具体的には、""(空文字)を返して欲しい局面で、#fが返る。
・rxmatch関数呼び出しの段階で既に、ゼロ巾文字列にマッチしてない可能性は、
 検証コード@により否定される。
・rxmatch関数が生成する<regmatch>オブジェクトに問題がある(壊れてる)可能性も、
 検証コードBにより、消極的に否定される。
・詰まる所、やはり『rxmatch-substring関数のゼロ巾文字列取り出しに問題がある』
 可能性が一番有力。
・7.5.3.5〜7.5.3.8にて、この症状を確認しました。
 6.0.5.8では、正常動作しました。

■検証コード■
@●マッチ自体はしてる。
(write (rxmatch #/^/ "ABCDE")) ;=>#<regmatch>
(write (rxmatch #/\b/ "ABC DE")) ;=>#<regmatch>
(write (rxmatch #/(?=bar)/ "foobar")) ;=>#<regmatch>

A▲けど、正しく取り出せない。(正しくは""が返るべき)
(write (rxmatch-substring (rxmatch #/^/ "ABCDE"))) ;=>#f
(write (rxmatch-substring (rxmatch #/\b/ "ABC DE"))) ;=>#f
(write (rxmatch-substring (rxmatch #/(?=bar)/ "foobar"))) ;=>#f

B▲rxmatch関数を介在させなくても、やはり正しく取り出せない。
(write (regexp-replace-all #/\b/ "ABC DE" (lambda (m)
(define s (rxmatch-substring m))
(if (eqv? s #f) "f" (if (and (string? s) (string=? s "")) "|" "x"))
))) ;=>"fABCf fDEf"◆正解は"|ABC| |DE|"

C●ゼロ巾でないマッチ文字列なら、ちゃんと取り出せる。
(write (rxmatch-substring (rxmatch #/^[ \t]*/ "\t\tABCDE"))) ;=>"\t\t"

おがわ さん 2015年 04月 26日 09時 17分 04秒

>LBH さん
エラーの件、ツール→オプションメニューで、以下の設定を試してみてください。
・機能タブの「DB LINK経由の検索でORA-3113エラーを回避する」をチェック
・設定(2)タブの「1度にFetchするレコード数」を少なくする

LBH さん 2015年 04月 22日 16時 59分 51秒

おがわ様

CLOB型のデータがあるレコードを大量SELECTすると、下記エラーになります。
ORA-03118 2タスク・コルーチンが無効状態です。

Osqledit ver:9.6.0.5
Oracle ver:11.2.0

具体的に言うと

1-3行目SELECT OK
2-4行目SELECT OK
1-4行目SELECT NG
全件SELECTも NG

該当テーブルにCLOB項目が4つ設けており、4000BYTE以上の文字列の場合がある
文字列の内容は英数字と/ * + ( ) . などの符号のみ

以上、ご確認をよろしくお願い致します。



ANSHUです さん 2015年 04月 13日 13時 16分 57秒

早速の回答ありがとうございました。
ver.3で実行しましたら、エラーが無くなりました。
助かりました。
なお、osqleditと同様な使い方ですので、悩まず使えて助かります。

おがわ さん 2015年 04月 11日 21時 52分 25秒

>『萩の月』 さん
情報いただき、ありがとうございます。
キー入力を再現するタイプのキーボードマクロでは、このような動作に
なってしまうと思います。
今は動作しませんがoedit/otbeditも、このタイプのマクロなので、
同じ現象になっていたと思います。

>ANSHUです さん
psqledit ver.4からUnicodeに対応した影響で、Unicodeに変換できない文字は
このようなエラーになってしまうと思います。
psqleditのver.3を試してみてください。

ANSHUです さん 2015年 04月 10日 16時 41分 02秒

PSQLEDITにてSQL実行で以下のエラーが表示されます。

ERROR: character 0xcfed of encoding "EUC_JP" has no equivalent in "UNICODE"

環境は サーバ:Linux PostgeSQL / 使用PC:Windows7 です。

なお、サーバの環境の変更はしないで、PC側の対応で解決できないでしょうか。

よろしくお願いします。

『萩の月』 さん 2015年 04月 09日 03時 20分 36秒

またお邪魔しました。
前回、こんな事を書かせて頂きました。

> Kakasy さんの書いた、サクラエディタのキーボードマクロ導入の件、もし実現したら嬉しく思います。

実はサクラエディタのキーボードマクロに、嫌な仕様を見つけました。
以下の例の(7)で、OEditは"DEF"を検索してくれますが、
サクラエディタは"ABC"を検索します。

1) 文字列"ABC"をクリップボードにコピー
2) KBDマクロ記録開始
3) 検索窓をOpenし、文字列ペースト
4) 検索
5) KBDマクロ記録完了
6) 文字列"DEF"をクリップボードにコピー
7) KBDマクロ実行

予想はしていましたが…本当にそうだったのでガッカリ。
頑張って(恐らく凄い実装量で)サクラエディタに近づけても、これではね。
と、思った次第です。

以上、ご報告まで。

おがわ さん 2015年 04月 08日 00時 57分 15秒

>Takeさん
ショートカットキーについて要望いただき、ありがとうございます。
今後のバージョンアップで検討していきたいと思います。

Take さん 2015年 04月 06日 11時 57分 10秒

いつも大変お世話になっております。
ショットカットキー割り当てについて要望がございます。

・ショートカットキー割り当てで、方向キーやPageUp、PageDownを組み合わせた設定が、
 SQL検索結果表がアクティブな場合に機能しません。
 例えば「Alt+PageUp」、「Alt+Right」などでタブ切り替えを行いたいのですが、
 可能でしょうか。

・ショットカットキーでSQLエディタ、SQL実行結果、SQL検索結果表をそれぞれ指定して
 アクティブにする設定は可能ですが、SQL実行結果 or SQL検索結果表の現在表示されて
 いる方をアクティブにするような設定はできませんでしょうか。
 現在表示されている状態でウィンドウの上下のアクティブ切り替えができればと思って
 います。

もし可能でしたら、よろしくお願い致します。

おがわ さん 2015年 03月 29日 23時 21分 44秒

>ひろ さん
osqleditをご利用いただき、ありがとうございます。
お問い合わせいただいた件ですが、1つのosqleditで、複数のSQLを並列
実行することは出来ないです。

>ちょびっとさん
ご報告いただき、ありがとうございます。
現象について、こちらでも再現しました。
次のバージョンで修正を検討したいと思います。

ちょびっと さん 2015年 03月 26日 11時 36分 16秒

おがわ様、いつもosqleditを利用させていただいて、大変助かっております。

早速ですが、不具合の報告になります。

osqledit(9.6.0.5)にて、DB接続していない、もしくは、接続しているようで、実は切れている場合、エディターにあるSQLを選択して、実行計画(選択範囲)機能を実行すると、osqleditが固まり、しばらくすると、落ちてしまいます。
通常の実行計画機能は問題ありません。

たまに、うっかりやってしまいますと、落ちた直前に書いていたSQLがすべて消えてしまいます、ログにも残らないため、もし対応して頂ければ、大変ありがたいです。

以上、ご確認をよろしくお願い致します。

ひろ さん 2015年 03月 25日 17時 47分 31秒

おがわ様、osqleditを利用させて頂き大変助かっております。

早速ですが、コマンドラインから、複数のSQLを並列して実行することは難しいでしょうか。
同一タイミングでの実行でないと都合が悪く、現在は複数のosqleditを起動して実行しております。

何か良い方法等ありましたら教えてください。

おがわ さん 2015年 03月 23日 22時 59分 51秒

>ぶびおさん
ご要望いただき、ありがとうございます。
select文エラー時の操作性について、検討したいと思います。

>やはさん
ご要望いただき、ありがとうございます。
MySQLについてですが、私自身がMySQLを使う機会が無いため、
現時点では計画はありません。



やは さん 2015年 03月 23日 17時 47分 16秒

おがわ様、いつもosqledit使わせてもらって大変助かっています。

さっそくではありますが、
MySQL版のエディタを作る予定とかありませんか?
osqleditでも使える機能がMySQL版であったらいいのになぁと思い、
質問させていただきました。

検索したら2003年頃、同様の質問をしていた方がいて
作る予定はないとのことではあったのですが、
だいぶ前の話なので改めて質問させていただきました。

ご回答のほど、よろしくお願いいたします。

ぶびお さん 2015年 03月 20日 10時 50分 03秒

おがわ様、早速のご回答ありがとうございます。

>ツール->オプションメニューの機能タブで、Auto CommitをOFFにしてください。
おっしゃる通り、Auto CommitをOFFにしたら、期待通りとなりました。
しかし、いちいちCommitされてしまうのでは、非常に使いずらさを感じます。

以前に、osqleditを使用したことがあるのですが、このような動作をしていなかったの
で、何か間違っているのでは、と思ってしまいましたが、以下のページを読んで、納得
致しました。

第5回 PostgreSQLとOracle Databaseそれぞれの特徴 | Think IT(シンクイット)

そこで、要望なのですが、SELECT文を間違ってしまった場合等に、rollbackコマンドを
簡単に発行できるように、psqleditのGUI上に、rollbackボタンを搭載することを、ご
検討いただけば幸いです。

おがわ さん 2015年 03月 20日 00時 20分 13秒

>ぶびお さん
ツール->オプションメニューの機能タブで、Auto CommitをOFFにしてください。
Auto Commitが有効な場合、自動的にトランザクションを開始していますので、
SQLエラーの後でrollbackを実行する必要があります。
Auto CommitをOFFにすると、psqlと同様の動作になると思います。
ただし、Auto Commitなので、insert, update, deleteなどのSQLがすぐに
commitされてしまいますので注意してください。

ぶびお さん 2015年 03月 18日 11時 18分 04秒

psqledit ver4.0.0.2を利用させて頂いてます。

環境: PostgeSQL9.3.4(Windows7 SP1)

質問というか、設定不足なのか分かりませんが、select文の文法等を間違えると、次回の
select文を発行できません。

-- ここから、psqleditで実行
select * from xx; ※xxテーブルは存在しない。
ERROR: リレーション"xx"は存在しません
LINE 1: select * from xx

こうなった後に、もう一度同じSQLを実行すると、以下のエラーとなってしまいます。
ERROR: 現在のトランザクションがアボートしました。トランザクションブロックが終わるまでコマンドは無視されます

select文だけなので、トランザクションは関係無いと思っておりますが、どうなのでしょうか?
こうなると、rollbackを実行しないと、以降の操作ができません。
お手数をおかけしますが、ご回答よろしくお願い致します。


※参考までに、SQL Shell(psql)から実行すると、

-- ここから、SQL Shell(psql)で実行
srvlet=> select * from xx;
ERROR: リレーション"xx"は存在しません
行 1: select * from xx;
^
srvlet=> select * from xx;
ERROR: リレーション"xx"は存在しません
行 1: select * from xx;
^
となり、想定通りの結果となります。

ian さん 2015年 03月 04日 22時 58分 49秒

返信ありがとうございます。
なるほど動作の速さは何より大切です。
理由が判明しただけでもすっきりしました。

おがわ さん 2015年 03月 04日 22時 35分 35秒

>NN08 さん
ご質問の件、OCIで接続しています。

>ian さん
ご要望いただきありがとうございます。
単語の区切り文字や演算子の文字など、複数の文字を候補として設定する
項目については、少しでも動作が速くなるように半角文字に限定しています。
テキストの記載については改善を検討したいと思います。



ian さん 2015年 03月 04日 13時 06分 58秒

otbeditをいつも便利に使っております。

先程、プログラミング言語「なでしこ」用の編集モードを作成しようとしましたが、
断念しました。
編集モードをカスタマイズする際には、各設定項目に全角文字は設定できません、
と付属テキストに書いてあったからです。

ただ、「行コメントの開始文字列」にはなぜか全角文字が使えるので、
「単語の区切り文字」や「演算子の文字」などにも全角文字を使えるように
することはできるのではないかと、素人考えを抱きました。

もし可能であれば全角文字をすべての項目で使えるようにしてほしいと思います。
でなければ行コメントのみ全角文字を使える旨をテキストに明記してほしいと思います。

NN08 さん 2015年 03月 03日 11時 33分 37秒

おがわ様

OSQLEDITのORACLE接続方式を教えて頂けますか?

PRO*C
OCI
ADO.NET

などがありますが どれを利用され開発されているのでしょうか?

お忙しいところすみませんが よろしくお願いします

おがわ さん 2015年 02月 11日 10時 13分 05秒

>ユーザーさん
ありがとうございます。参考にさせていただきます。
また、osqledit ver.9以降ではUnicodeに対応しています。
こちらの利用も検討いただければと思います。

ユーザ さん 2015年 02月 10日 12時 00分 50秒

oSqleditの検索結果で日本語が文字化けする件について
参考までに

■環境
Windows 2008 R2 Standard
Oracle Data Access Components fro Ocacle Client 12.1.0.1.0

●SqlPLus→文字化けせず
●Visual Studio Community 2013+Oracle.DataAccess →文字化けせず
●oSqledit5.7.0.0 →文字化けする★



システム環境変数にを新規追加
変数名=「NLS_LANG」変数値=「JAPANESE_JAPAN.JA16SJISTILDE」
で直りました。

おがわ さん 2015年 02月 05日 21時 04分 03秒

>fuka さん
ご要望いただき、ありがとうございます。
すぐに実現することは難しそうですが、検討させていただきます。

boolean さん 2015年 02月 05日 16時 06分 17秒

>psqledit 4.0.1.0で修正しました。

操作結果の行数表示の文字化け修正ありがとうございます。

returnning * とかで逃げて運用してましたが、悩み解消です。

文字コードの問題も無くなって大変便利になりました。

fuka さん 2015年 02月 03日 15時 33分 32秒

こんにちは、いつもotbeditを愛用させていただいております。
機能追加の要望をさせてください。

【要望】
 ・テキストの階層管理機能
 ・階層管理のネスティング対応

【具体的な例】
 ■例1
 sub sample{
   foreach(arr){
      #***文書の内容***#
   }
 }

 ■例2
 #sample
   ##section
      #***文書の内容***#
   section##
 sample#

【収納表示の例】
 ■例1
 sub sample{...}
  ↓ 1階層展開
 sub sample{
   foreach(arr){...}
 }

 ■例2
 #sample...sample#
  ↓ 1階層展開
 #sample
   ##section...section##
 sample#

テキストエディターとしての機能とおもむきが異なる面もあるかも知れませんが、
よければご検討いただけば幸いです。

おがわ さん 2015年 02月 02日 22時 55分 39秒

>KANさん
ご要望いただき、ありがとうございます。
検討させていただきたいと思います。


KAN さん 2015年 01月 29日 13時 52分 10秒

osqledit

TNS接続の場合、oracle clientが必要ですので、それをインストールするのが面倒なんで、
直接接続の機能を追加したら如何ですか?

おがわ さん 2015年 01月 28日 20時 18分 34秒

>Oratorさん
報告いただき、ありがとうございます。
改善可能かどうか調査してみます。

Orator さん 2015年 01月 23日 18時 41分 23秒

OSqlEdit で:

WITH A AS (SELECT 'X' AS X FROM DUAL)
SELECT * FROM A INNER JOIN DUAL B
ON (B.DUMMY = A.

と書いた場合、最後の「.」を打ったところで
列「X」が入力ヒントに現れたのですが、

WITH A AS (SELECT 'X' AS X FROM DUAL)
SELECT * FROM A Y INNER JOIN DUAL B
ON (B.DUMMY = Y.

とした場合は、入力ヒントが働かないようです。

おがわ さん 2014年 12月 29日 12時 03分 54秒

> MurasakiCube さん
ご要望ありがとうございます。
将来のバージョンアップで、検討させていただきます。

MurasakiCube さん 2014年 12月 25日 23時 26分 14秒

追伸
ソフト名を忘れていました。otbedit です。

MurasakiCube さん 2014年 12月 25日 23時 18分 56秒

すばらしい出來のエディタ、たゞ、私にとっての致命的欠点があります。
「前回終了時の復元」ができないことです。
これはいいと思って終了、再起動したらがっかりしました。
今後、是非とも実現していただければ、と切にお願いします。

おがわ さん 2014年 12月 22日 22時 23分 31秒

>Tさん
ご報告いただき、ありがとうございます。
原因について調査してみます。

>ばんぶうさん
ご連絡ありがとうございます。
テーブル定義の取得について、データディクショナリの検索権限が不足している
かもしれません。osqleditの新しいバージョンでは、以下の権限が必要になっています。
他スキーマのテーブル定義を取得する場合、DBA_SEGMENTSのSELECT権限が必要に
なります。
自分のスキーマのテーブル定義を取得する場合は、USER_SEGMENTSのSELECT権限が
必要になります。

North Face Outlet さん 2014年 12月 18日 22時 43分 37秒

moreover, organization also stated there goal of outcomes in life opportunities coupled with daily monetary service of surplus us dollars that investors.
[url=https://www.newsletteronline.com.au/blog/]North Face Outlet[/url]

ばんぶう さん 2014年 12月 18日 22時 00分 31秒

2014/11/15に投稿しました件について、
遅くなりましたが、追加でご連絡いたします。

ORA:11g - 11.2.0.1.0 - 64bit
OS:LinuxとWinSV2012 両方で確認
オブジェクトはテーブル定義です。
sqleditは、少し古いですが、9.2.2.0のときは問題なかったです。

T さん 2014年 12月 17日 11時 07分 16秒

こんにちは osqledit 使い始めました。
起動のたびに、ウィンドウサイズが縦に少しのびてしまうのをなんとかしてほしいです。
2マシンで試しました。再現は100%です。

Windows 7 32 bit
osqledit を起動
最大化ではない
タスクバーは下、常に表示
ウィンドウサイズの縦(高さ)を、0〜タスクバーまでとする。
(ただし、高さをさらに大きく、下辺をタスクバーよりさらに下にしても同症状)
これで終了すると、次回起動時に高さがのびてしまいます。

高さがタスクバーよりわずかでも上だと、上記は発生しません。

BB さん 2014年 12月 15日 11時 44分 07秒

>おがわさん
直りました。ありがとうございます!

Return