SQLフォーマッターFor WEB
・SQL整形ツールです。初版は2006年。長くメンテしてきたもんです。
[広告]
カンマ整形: | |||
AND/OR/ON整形: | |||
インデント: | |||
JOIN形式: | |||
予約語: | |||
出力先: |
[広告]
おまけ:
変換フォーマット: | Java | Perl | |
改行コード: | なし | \n | \r\n |
今まで通りSQLの整形にお役立てください。
バージョンアップした際は本ページでお知らせしたいと思います。
2021/3/21追記
・==が1トークンになるよう修正
・[table]![column]が崩れないよう修正
・cross join が崩れないよう修正
2019/7/1追記
・カンマ整形前の場合にorder byはgroup byで桁ぞろえが有効にならないバグを修正
・カンマ整形前の場合に、limit 1, 10が limit 1 , 10となるバグを修正
2018/8/28追記
・ie11でlocalStorageが動作しなかったバグを修正
2018/8/27追記
・localStorageに整形書式を保存するよう対応
2018/8/4追記
・カンマ整形が前の場合、「桁ぞろえ」オプションを追加
コア部分に手を入れたため、おかしな動作をした場合はお知らせください。
2018/5/14追記
・UNIONはブロック内のベースインデントに強制的に戻すよう対応
・#で括られた文字列が日時っぽかったら整形しないよう対応
2018/3/31追記
・コメントのインデント位置を次のトークンを参照するよう修正
・"["と"]"に囲まれたトークンを整形しないよう対応
・クリップボードにコピーするcopyボタンを追加
2018/1/4追記
・distinctの整形を改善
・select intoの整形を改善
・limit後のselect foo, barの","で改行されない不具合を修正
・バッククォート内に不要な半角空白が含まれる不具合を修正
2017/8/30追記
・SQLを1行に戻す機能を追加
2017/6/14追記
・連結キーワードに「::」,「@>」,「<@」を追加
2017/6/5追記
・整形結果の出力先が選べるように対応
2017/3/20追記
・insert文に暫定対処
・create文に暫定対処
・alter文に暫定対処
2017/3/10追記
・MS-Accessのクエリを考慮し、[xxx - xxx]を[xxx-xxx]となるよう修正
・select for updateのクエリが崩れないよう修正
2017/3/5追記
・":xxx"のバインド変数が":" と"xxx"で別れる不具合を修正
コア部分に手をいれたため変な動作をしたら教えてください
2017/2/27追記
・":="を1つのキーワードとなるように修正
2017/1/31追記
・"("からはじまるクエリが整形できない問題を修正
2017/1/21追記
・整形後ctrl+cが効かない問題を修正
2017/1/9追記
・色付きクエリはaceエディタに出力するよう変更
2016/11/7追記
・limit付きSQLがうまく整形できない問題を修正
2016/10/14追記
海外版をリリース
日本語版はこのページとして、バグ修正や要望を取り入れながら、海外版も合わせて育てていこうと思います
2016/10/8追記
・色付きのSQLが欲しくなったので簡易版を配置
2016/9/13追記
次の修正を行いました。
・WITHIN GROUPを崩れないよう対応
・その他一部のキーワード追加
2016/9/3追記
次の修正を行いました。
・INNER省略型のJOINキーワードに対応
何か変な動作をしましたら教えてください。
2016/5/5追記
次の修正を行いました
・予約語の一部追加
・カンマ整形を「前」とすると、in(1 ,2)となっていたものをin(1, 2)となるように修正
コア部分に手を入れましたので、変な動作をしましたら教えてください
2015/2/28追記
予約語の大文字、小文字化に対応しました。
紛らわしい予約語は一部除外していますが、うまく変換されないものがあればお知らせください。
便利なサービスの提供ありがとうございます。
1点お願いがあるのですが、サイトのfaviconを設定していただくことは可能でしょうか。
というのも、自分がブックマークバーに登録する際、スペース節約のためにブックマークに名前を設定せず、faviconのみ表示させるような使い方をしているため、faviconが設定されていると見分けがつきやすくなるためです。
わがままなお願いですが、是非ご検討のほどよろしくお願いいたします。
faviconを設定してみました。
移転前だとfaviconもままならなかったので、移転してよかったですー
早速の対応ありがとうございます!
いつも利用してます。 とても助かってます。
変換前
–コメント1
SELECT * FROM A
–コメント2
UNION
SELECT * FROM B
変換後
–コメント1
SELECT
*
FROM
A
–コメント2
UNION
SELECT
*
FROM
B
この際のコメント2のインデントは無しにできないでしょうか。
コメントだけの行は整形無しでも良いかと。
>sapさん
要望ありがとうございます。
たしかにこの例だと、unionの前なのでコメント2のインデントは無いほうが見やすいですね。
コメントは直後のトークンのインデントと同じにするように検討したいと思います。
>sapさん
コメント位置を修正してみました。お試しください。
うまくいかない場合は、キャッシュの可能性があるため、再読み込みをしてお試しくださいm(_ _)m
便利なツールをありがとうございます。
MS-Access / SQL Server を使用しているのですが、[](角括弧)は文字列リテラルとして扱ってもらえれば(整形対象から外してもらえれば)ありがたいです。
>denchi さん
コメントありがとうございます。
Accessの[](角括弧)内はカラム名に特殊文字などを使っているときに利用するんですね。Accessは不勉強でしりませんでした。
たしかにそれであれば、文字列リテラルとして扱うほうが問題なさそうなので、修正を検討いたします。
返信ありがとうございます。
検討よろしくお願いします。
余談ですけど、Access SQLの角括弧は、カラム名やテーブル名だけではなくて、たとえば
SELECT * FROM [Excel 12.0 Xml;database=D:\Book1.xlsx].[Sheet1$]
なんて書くとExcelのシートをテーブルとして開けたり、
SELECT * FROM table1 IN “” [ODBC;Driver={SQL Server};SERVER=servername;Database=dbname;]
みたいな感じでODBCデータソースを開けたりするのです。
さすがAccessといったところですね。
勉強不足でした。自由度がたかい。。。
情報ありがとうございます。
修正まで今しばらくお待ちくださいませ。
ありがとうございます。修正お待ちしています。
様々なSQLの方言に対応するのは大変でしょう(スミマセン)。
また余談で、これは特に対応していただく必要はないと思いますが、
SQL Serverではカラム名やテーブル名に
角括弧やピリオドなども使えてしまい、その場合、
角括弧の中の閉じ角括弧は2つ重ねてエスケープします。
(開き角括弧はそのまま記載します)
SELECT * FROM [[table]].[1]]]
これは”[table].[1]”という名前のテーブルを使った例です。
実際にそんな名前を使う人はいないと思いますが。
あと前回返信するべきところを新規のコメントにしてしまってすみません。
>denchiさん
コメントありがとうございます。
>SELECT * FROM [[table]].[1]]]
これはすごい^^;
こういった名前形式が流行っていったら(フレームワークとかで?)検討ですかねぇ。
>denchi さん
角括弧の対応を行ってみました。お試しください。
うまくいかない場合は、キャッシュの可能性があるため、再読み込みをしてお試しくださいm(_ _)m
対応どうもありがとうございます。
いい感じに整形できているようで、いろいろ捗りそうです。
今後もSQLフォーマッターにはお世話になります。
便利に使わせてもらっています。
お願いがあるのです。
整形済みSQLを表示する場所の右端の方に
クリップボードにコピーの機能を付けられませんか?
よくブログなどでハイライトされたソースコードの横にうっすらとある機能のことです。
イメージ
http://xn--hhro09bn9j8uh.com/blog/post-1670/
ぜひご検討をよろしくお願いいたします。
>もちもちさん
要望ありがとうございます。
なるほど、クリップボードですね。
検討しますのでしばらくお待ちください。
>もちもち さん
クリップボードへコピーするcopyボタンをつけてみました。お試しください。
うまくいかない場合は、キャッシュの可能性があるため、再読み込みをしてお試しくださいm(_ _)m
失礼します。
いつも利用させていただいております!
ありがとうございます!!
失礼しました。
いつも利用していただいてありがとうございます。
これからもよろしくお願いしますー!
お世話になっております。
JOINの後にUNIONがあるとちょっとおかしいみたいです。
SELECT * FROM t1 INNER JOIN t2 ON t1.f1 = t2.f1 UNION SELECT * FROM t3;
— ↓WHEREがあれば正常。
SELECT * FROM t1 INNER JOIN t2 ON t1.f1 = t2.f1 WHERE 1=1 UNION SELECT * FROM t3;
— ↓JOINがなければ正常。
SELECT * FROM t1 UNION SELECT * FROM t3;
>denchiさん
報告ありがとうございます。
確かにUNIONのインデントが変ですね。。
調査してみます。
>denchiさん
UNIONの整形見直しましたので、ご確認ください。
うまくいかない場合は、キャッシュの可能性があるため、再読み込みをしてお試しくださいm(_ _)m
失礼、メッセージ見落としていました。
UNION大丈夫そうです。ありがとうございます。
続けて要望すみません。
Access SQLなんですが、日付/時刻のリテラルの書式がありまして、「#」で囲むのです。
SELECT * FROM t WHERE dtm1 #01/01/2017#;
といった具合です。
ついては、「#」で囲まれた部分も整形対象外にしていただけたらありがたいです。
優先度は低めです。
>denchiさん
要望ありがとうございます。
Accessは#で括るんですね。。
他のRDBとの兼ね合いを調査しつつ検討してみます。
そうですね、他のRDBで「#」を別な意味で使っていたら悪影響が出そうですね。
軽くお願いしてしまってすみません。
ところで、前回の私のコメントのSQL文がおかしいですね。
確か「<=」とか「>」というのを(半角で)入れたと思いますので、
それがHTMLタグと判定されて削除されちゃった感じでしょうか……。
「#04/19/2018#」とか「#04/19/2018 15:00:00#」とか、
そういう書き方があります、というのを示したSQL文でした。
>denchiさん
コメントありがとうございます。
SQLの件、了解です。
整形ツールの向上にもなりますので、要望は気楽に上げて貰うほうが実は助かってます^^
そう言っていただけるとありがたいです。
では、えー、さらに優先順位の低い話で、
もし直ったらうれしいなあ程度のことなんですが、
符号の(つもりの)マイナスが数字から離れてしまうのが
ちょっとだけ気になっています。
「UPDATE t SET a = -1」みたいなのですね。
また、試しに「SELECT -1 * -2 – -3 – 4, -5」とか入れてみたら
途中の「- -」が「–」で独立した行になってしまい、なんかおかしいですね。
普通こんな(意地悪な)感じの式は書かないと思いますが。
>denchiさん
コメントありがとうございます。そして回答が遅くなり申し訳ないです。。
なるほど、たしかに「a = -1」と入力した場合は、想定外ですね。
管理人がカラム価にマイナスを入れる案件を携わったことがないのが原因ですかね^^;
でもこれはあり得そうなので、修正を検討します。
もう一つの「- -」は意図してませんでした。
こういった演算子は、プログラムではよくありますが、SQLでもあるんですかね?
であれば対応せねば。。ヽ(゚Д゚)ノ
検討ありがとうございます。
すぐにご回答いただかなくても全く問題ありませんのでお気になさらず。
ところで、また書き込んだテキストがちょっと変化しているかな?
件のSELECT文はぜんぶ半角のマイナスで入れたつもりだったんですが、
式の中の演算子に相当する部分がなぜかenダッシュ(U+2013)になっていますね。
> 途中の「- -」が「–」で独立した行になってしまい
ここも、後ろのかぎかっこの中はマイナス2文字です。
マイナス2文字をコメント欄に書くと変換されちゃうのでしょうか。
あああ、今見ると4/11の私の書き込みのマイナス2文字(コメント行)も
emダッシュ(U+2014)に変わってますね。
<>もそうですが、SQL文をここのコメントに貼り付けるのはちょっと厳しいですね……。
要は、マイナスがスペースを挟んで2つ続いたときに、
間のスペースが削除されて、でもコメントとして解釈されているわけでもなくて
独立した行になってしまうなー、おかしいなー、という話です。
自分が普通に書くならマイナスマイナスはプラスにしちゃいますので
こういう文になることは多分ないです。かけるマイナスならたまにありますが。
件の文は、符号のマイナスが出現するパターンとして、
SELECT直後、演算子の後、コンマの後、あたりかなー、
といったことを考えて書いてみたもので、
そしたらたまたま「- -」の整形が妙だったので
一応ご報告しておこうかな、といったようなわけです。
符号については離れてもそれほど見づらいわけではないので、
優先順位は低いということで……。
一応、思いついたほかのパターンを書いておきます。
SELECT -f1, -.1, -(-0.2) FROM t WHERE f2 > -.3
このマイナスはぜんぶ符号ですね。
>denchiさん
詳細なコメントありがとうございます。
そしてコメントの自動変換でご不便かけます^^;
これはサイトの仕様ですかね。。
マイナス記号は細々と対応していこうと思います!
返信のネストも4段までなんですかね~。
自分のコメントがどう表示されるのかすぐにはわかりませんし、
なんとも厳しい仕様ですね……。
今後もよろしくお願いします。
>denchiさん
#で囲まれたトークンが日時の場合、整形対象外にしましたので、ご確認ください。
ただし現状では日時を正確にパースしてないので、いまいちの場合はコメントくださいm(_ _)m
なるほど、日付っぽかったらですか。
個人的には「#MM/dd/yyyy#」か「#MM/dd/yyyy hh:mm:nn#」しか使わないため問題なさそうです。
どうもありがとうございます。
一応、情報として、判定に失敗しそうなものを挙げておくと、
・年月日の区切りには「/」だけではなく、「-」や「 」(スペース)も使える
・月の表記には数字だけではなく「Jan」や「January」なども使える
・時刻は末尾に「AM」「PM」をつけることができる
といったあたりでしょうか。資料が見当たらず、網羅しているかどうかは自信がないですが……。
例)
SELECT TOP 1 #2018-05-15 10:15:20#, #Jan 18 2018 10:15 AM#, #18-January-2018 10:15AM#, #10AM# FROM T
まともに判定するのは大変そうですね。
>denchi さん
コメントありがとうございます。
#は他のRDSでも使うので、とりあえずの対応です^^;
こちらも正確な資料が見つからなかったので、コメント頂けて幸いです。
それにしてもAccessの日時型は自由度が広い。。
日付っぽさを拡張して
#[0-9a-zA-Z\-\/: ]+#
の正規表現で判定にするかも^^;
正規表現だけで正確に判定するのは大変そうですが、とは言え、
そんなに広げてしまって大丈夫でしょうか。
Accessユーザーとしては広くても全く困らないのですが、
全然日付っぽくなくてもマッチしちゃいますよね。
(整形しないだけだから結果的にそんなに問題ないのかな?)
他のRDBではどう使われているんでしょ。
追加で、AM/PMはA/Pでも行けました。#1A#で午前1時とか。
おまけに、アルファベットの月表記を使うと
年月日の順番は問わないみたいです。ひええ。
>denchi さん
コメントありがとうございます。
他のRDSだとシャープを単独で使うのはあるみたいですが、
#で括る仕様は、なかなか出てこないですねぇ。
Accessの日付パースはとてもシンドソウなので、何とかお手軽に逃げたいですねぇ
「#[0-9a-zA-Z\-\/: ]+#」だと、
select #hoge from #foo
とかだと破綻するので、
「#を括る」というオプションのほうがいいかもしれませんねぇ。
うーん、悩ましい。
私もちょいちょい検索してみましたが、
OracleやSQL Serverでは「#」はそのまま表名/列名に使える記号らしいですね。
(アンダースコアと同様のイメージ)
それと、MySQLでは「#」以降行末までがコメントになるんだとか。
(こっちはハイフンx2と同様)
これ、MySQLが強力すぎて、Access抜きにしても破綻しますねえ……。
オプションで対応するとしたら
「#: 通常の文字とみなす / 行末までコメントとする / 括った文字列を整形しない」
みたいな感じでしょうか……。
でも、MySQLの#コメントには対応しないということであれば、
「#と#の間の文字列が **偶然** 日付っぽくなる可能性を無視する」のはアリかもしれませんねー。
拙いですしまだちょっと緩いかもですけど、とりあえず
/# *((\d{1,4}|Jan(uary)?|Feb(ruary)?|Mar(ch)?|Apr(il)?|May|June?|July?|Aug(ust)?|Sep(tember)?|Oct(ober)?|(Nov|Dec)(ember)?)(([\-/]| +)(\d{1,4}|Jan(uary)?|Feb(ruary)?|Mar(ch)?|Apr(il)?|May|June?|July?|Aug(ust)?|Sep(tember)?|Oct(ober)?|(Nov|Dec)(ember)?)){1,2}( +\d{1,2}(( *(AM|PM|A|P))|((:\d{1,2}){1,2}( *(AM|PM|A|P))?)))?|(\d{1,2}(( *(AM|PM|A|P))|((:\d{1,2}){1,2}( *(AM|PM|A|P))?)))) *#/i
という感じならどうでしょうか。
(ちゃんと表示されるかな?)
>denchi さん
コメントありがとうございます。
MySQLは行コメントかー。
やっぱりオプション選択を検討ですかね^^;
そして素敵な正規表現ありがとうございます!
参考にさせていただきますー
はい、ご参考ということで……(ちゃんと表示されているようです)。
それで、「偶然」はあり得なさそうだなーと思いつつ考えたのですが、
SELECT MAY#05-APR#04 FROM T
というのを思いつきました。
(’MAY#05′ と ‘APR#04’ がフィールド名で、引き算)
まあ、あり得ないわけではない、ということですかね?
どうもですー
もの凄いカラム名ですね^^;
こういったものは、専用のRDMSでのパースとなりそうですねー。うーん、悩ましい。
RDMSの方言にも困ったものです。。
というか、現状でSELECT MAY#05-APR#04 FROM Tは正しく整形できているようですので、
・MySQLの人には「#」ではなく標準的なハイフンx2を使ってもらう。
・Accessの人には日付リテラルのハイフン区切りと月名表記を諦めてもらう。
というのが最もお手軽な対応でしょうねー。
ちなみに上記SQLはAccessではカラム名を[]で括らないとエラーが出ます。
また、現バージョンでの「偶然」も考えてみたんですが
SELECT COLUMN#05/10 #ALIAS FROM T
とか……(’COLUMN#05′ 割る 10 を ‘#ALIAS’ という別名で返す)。
あり得ないわけではないですねえ?
なお「#05/10 #」はAccessの日付リテラルとして正しいので、日付っぽさ判定を厳しくするというアプローチでは解決しません。
でもぶっちゃけ、そんな「偶然」まで対応する必要はないんじゃないかとは思いますー。
さすがはdenchiさんですねー^^
参考にさせていただきます。
SQL整形ツールを探している中で同僚から教えてもらってたどり着きました。素晴らしいツールです!
早速ブログでも紹介させていただきました。
http://onefact.jp/wp/2018/07/29/sqlcoding/
>ミラニスタさん
ブログでの紹介ありがとうございます。
DBMSに詳しい方に使っていただいて感謝感激です!
今後ともよろしくお願いいたします。
私からも1点要望させていただいてよいでしょうか?(優先度は高くなくて結構です。)
私は「前カンマ派」なのですが、以下のように最初のカラムを空白一文字分下げていただけると左が揃った感じできれいだと思います。(単なる個人的な意見ですが。)
例:
select
D.DEPARTMENT_NAME
,E.FIRST_NAME
わかりにくかったですね。。。
select
△D.DEPARTMENT_NAME
,E.FIRST_NAME
の意味です。
>ミラニスタさん
要望ありがとうございます。
確かに半角スペースがあったほうが見やすいですね。
修正までしばらくお待ちください。
>ミラニスタ様
前カンマ機能で「桁ぞろえ」を選べるようにしました。
「桁ぞろえ」チェックをONにしますと、ご要望の動作になるかと思います。
うまく動作しない場合はキャッシュの可能性があるため、F5などで再描画してお試しくださいm_ _m
早速の機能追加ありがとうございます。
正しく動作しています!
まさに要望通りの整形です!!
はじめまして。
非常に便利なのでいつも利用させていただいております。
SELECT * FROM TABLE_A WHERE B_COLUMN < @P_COLUMN_B
上記のようなスクリプトを変換すると、@が不等号と連続するように変換され、@と変数名の間にスペースが入ります。
不等号ではなく等号の場合はそのような挙動にはなりません。
これは仕様でしょうか?
ご返信、気長にお待ちしております。
>かりやさん
ご連絡ありがとうございます。
これは。。。
“< @"を範囲演算子として解釈してしまってますね。 範囲演算子についてはこちら。 https://www.postgresql.jp/document/9.2/html/functions-range.html#RANGE-OPERATORS-TABLE
うーん。どうにかならないか検討してみます。
>かりやさん
お待たせしました。 修正できたかと思います。
うまく動作しない場合はキャッシュの可能性があるため、F5などで再描画してお試しくださいm_ _m
>管理人さま
早速ご対応いただき、誠にありがとうございます。
想定通りの挙動をしてくれるようになりました。
範囲演算子なんてものがあったんですね。
勉強になりました。
重ねてお礼申し上げます。
かなり初期の頃から使わせてもらっていて非常に感謝しております。
1つ要望なのですが、ページを開くたびに整形の設定を選ぶのが少し手間なので、ラジオボタンの状態をLocalStorageに保存して復元するようにしていただけたらとても嬉しいです。
>匿名さん
コメントありがとうございます。
あー、たしかに。
その昔はcookieで制御してたのですが、今見てみるとダメですね。
時間を確保しだいLocalStorage対応しますね。
しばらくお待ちください。
>匿名さん
LocalStorageに保存するようにしました。
お試しください。
うまく動作しない場合はキャッシュの可能性があるため、F5などで再描画してお試しくださいm_ _m
いつもお世話になっております。
LocalStorage保存対応後に整形を実行しようとしたところ、ウンともスンともいいません。
F5を押しても変わりませんでした。
いつもお世話になっております。
LocalStorage保存対応後に整形を実行しようとしたところ、ウンともスンともいいません。
F5を押しても変わりませんでした。
いつもお世話になっております。
上の匿名様ご要望のLocalStorage保存対応後にIE11より整形を実行しようとしたところ、
ウンともスンともいいません。
(試したのはinsert文と select 1 from dual)
F5を押しても変わりませんでした。
キャッシュ以外に原因はありますでしょうか。
>皆様へ
失礼しました。
Chromeでしか確認してませんでした。。
一時的にLocalStrageを無効にしました。
これで整形は利用可能なはずです。
IEだと動かないですね…。
申し訳ないです。
近日中にlocalstorageのIE対応を行います。
現在はlocalstorageは利用しなくなってますので、IEでも今までどおりの整形は行えます。
うまく動かない場合は、キャッシュをクリアしてください。
>皆様
IE11でローカルストレージが動作するよう修正しました。
ie11,chrome,firefox,safariで動作確認済みです。
うまく動作しない場合は、キャッシュクリアをお試しください。
毎度使わせていただいています
ひとつ要望なのですが
元のSQL入力するTEXTAREAの縦を小さくしていただけるといいなぁと
見たいのは整形後のSQLなので
>がうさん
要望ありがとうございます。
お使いのブラウザは何でしょうか?
ChromeやFirefoxならTextAreaは右下をドラッグすれば大きさは変更できますね。
あーでもIEやEdgeは、変えられませんよね。。
うーん、ブラウザに依存しないでTextAreaの大きさを変更できるように改造するか検討したいと思います。
カンマ整形:前(桁ぞろえ)
の場合に、ORDER BY で揃っていません
>sapさん
返信おくれました。そしてご指摘ありがとうございます。
確かにorder byで桁ぞろえができてませんね。。。
対応までしばらくお待ちください。
>sapさん
長らくお待たせしました。
ORDER BYの場合でも桁ぞろえが有効になるよう修正しました。
うまく動作しない場合はキャッシュの可能性があるため、F5などで再描画してお試しくださいm_ _m
コメント整形はできませんでしょうか。
–顧客担当者
SELECT
CE.EMPLY_ID,
–従業員ID
CE.EMPLY_NM
–従業員名
FROM
MST_EMPLY CE
–従業員マスタ
このように1行ごとにコメントを付けた場合に、すべて改行されてしまいます。
イメージとしては、
–顧客担当者
SELECT
CE.EMPLY_ID, –従業員ID
CE.EMPLY_NM –従業員名
FROM
MST_EMPLY CE –従業員マスタ
コメント単独行はブロックのインデント、
SQLとセットのコメントは、スペース揃えできればと・・・。
何文字目でコメントを揃えるかは数値入力可能にして、80文字くらいから揃えられるとと思うのですが・・・。
(A5M2のように)
>匿名さん
要望ありがとうございます。
コメント整形弱いですよね^^;
現在のコメント整形は、コメントが前にあるものとして整形しています。
これだと、後ろ(横)にコメントがある場合はうまく整形できないので、この場合でも見やすい整形になるよう検討してみます。
いつも利用させていただいてます。
仕事の中でSQLログが1行ででるのでとても助かっています。
一点要望なのですが、
予約語を大文字変換するような機能があるといいなあと思います。
コメントとの差別化やDBの違いなどでめんどくさそうですが、、、
コメントありがとうございます。
予約語の大文字・小文字変換は用意してますよー
おそらく「変換なし」になっているかと思うので、「大文字」に切り替えてご利用ください。
管理人様
いつも利用しています。
ずっとCやJavaなどのプログラミングをしていましたが、最近SQLを触るようになりました。
SQLの経験と知識が浅いので的はずれな希望かもしれませんが、
以下のようにインデント取ることは可能でしょうか?
例
SELECT
従業員ID,
従業員名,
部署
FROM
従業員マスタ
LEFT JOIN
部署マスタ
ON (
従業員マスタ.部署 = 部署マスタ.部署コード
)
;
ON
(
….
)
でなく
ON (
…
)
みたいな感じのインデントです。
SQL界隈ではどちらのインデントが正しい(多い)
のかわからないので恐縮ですが…
コメントありがとうございます。
なるほど丸括弧のインデントですね。
丸括弧事態をあまり使わないので(orくらい?)あまり考えてなかったです^^;
検討してみます。気長にお待ちください。
最近時間が取れないので。。
いつも利用させていただいております。
1点質問があります。
集計関数のSUMがインデントされないのは仕様でしょうか?
コメントありがとうございます。
インデントされないですか?
こちらでは確認できなかったので、サンプルのSQLを書いてもらえると助かりますー
カンマ整形の前(桁ぞろえ)ですが、
GROUP BY や ORDER BYで指示している列がSELECTしている列のように、桁が揃いませんが、改善可能でしょうか?
SELECT
COLA
,COLB
,COUNT(*)
FROM
TBLA
GROUP BY
COLA
,COLB
ORDER BY
COLA
,COLB
コメントありがとうございます。
これはバグですね。。連絡ありがとうございます。
時間が取れ次第修正したいと思います。。
気長に待っていただけると。。
GROUP BYやORDER BYで桁ぞろえ対応してみました。
ご確認ください。
うまく動作しない場合はキャッシュの可能性があるため、F5などで再描画してお試しくださいm_ _m
GROUP BYやORDER BYで桁ぞろえ、確認いたしました。ありがとうございました。
WHERE句内のサブクエリのインデントが演算子によって異なっていました。
どちらが正しいのかわかりませんが、どちらかに合わせた方がいいと思いました。
「設定」
カンマ整形:前(桁ぞろえ:有)
AND/OR/ON整形:前
インデント:スペース4
JOIN形式:パターンA
予約語:大文字
出力先:色付きエディタ
「パターン1」
——————————-
WHERE
kind <= ALL
(
SELECT
kind
FROM
T_jisya
)
——————————-
「パターン2」
——————————-
WHERE
kind <= ANY(
SELECT
kind
FROM
T_jisya
)
——————————-
WHERE
kind IN(
SELECT
kind
FROM
T_jisya
)
——————————-
WHERE
kind NOT IN(
SELECT
kind
FROM
T_jisya
)
詳細なコメントありがとうございます。
本当ですね^^;
どこかのタイミングで修正したいと思います。
設定が「カンマ整形:前(桁ぞろえ:有)」の時、桁ぞろえになっていないパターン、スペースが余分に増えたパターンがありました。
「設定」
カンマ整形:前(桁ぞろえ:有)
AND/OR/ON整形:前
インデント:スペース4
JOIN形式:パターンA
予約語:大文字
出力先:色付きエディタ
【例1】
————————————————————–
05行目・・・テーブルが複数あるにもかかわらず、桁ぞろえになっていなかった。
09行目・・・テーブルが1つしかないにもかかわらず、スペースが余分に増えていた。
10行目・・・テーブルが複数あるにもかかわらず、桁ぞろえになっていなかった。
————————————————————–
[行数:SQL文]
01:SELECT
02: b.id
03: ,b.kingaku
04:FROM
05: (
06: SELECT
07: AVG(kingaku) AS heikin
08: FROM
09: T_jisya
10: ) a
11: ,T_jisya b
12:WHERE
13: a.heikin < b.kingaku
14:;
————————————————————–
【例2】
————————————————————–
12行目・・・テーブルが1つしかないにもかかわらず、スペースが余分に増えていた。
26行目・・・テーブルが1つしかないにもかかわらず、スペースが余分に増えていた。
下記の条件に当てはまった時、インデント対象外がインデントされていました。
・SQL文が複数ある時
・次のSQL文のSELECT句にインデントがある時
・最後のSQL文以外
————————————————————–
[行数:SQL文]
01:SELECT
02: id
03: ,kingaku
04:FROM
05: T_tokuisaki
06:WHERE
07: kind <= ALL
08: (
09: SELECT
10: kind
11: FROM
12: T_jisya
13: )
14:;
15:SELECT
16: id
17: ,kingaku
18:FROM
19: T_tokuisaki
20:WHERE
21: kind <= ALL
22: (
23: SELECT
24: kind
25: FROM
26: T_jisya
27: )
28:;
29:SELECT
30: id
31: ,kingaku
32:FROM
33: T_tokuisaki
34:WHERE
35: kind <= ALL
36: (
37: SELECT
38: kind
39: FROM
40: T_jisya
41: )
42:;
————————————————————–
こちらも詳細なコメントありがとうございます。
合わせて修正したいと思います。
連続作業を行う用に上部貼り付け部分にクリアボタンを作っていただけると大変うれしいです。
返信遅れました。要望ありがとうございます。
クリアボタンですね。対応検討します。
いつも使わせていただいています。
ありがとうございます。
要望なのですが、もしよければ、
JOIN形式パターンBのとき、ON句の前にもう一回インデントがほしいです。
好みの問題かとも思いますので、本当にもしよろしければ……。
table_a
INNER JOIN table_b
○○ON table_a.id = table_b.table_a_id
要望ありがとうございます。
対応検討させていただきます。
ただ今はなかなか時間が取れないので、先になるかもしれないです。
申し訳ないです。。
MS-ACCESSだと、
TABLE_A.COLUMNを
[TABLE_A]![COLUMN]と表現することがありまして、
この際、
[TABLE_A]![COLUMN]
->
[TABLE_A] ! [COLUMN]
のように半角空白入りに変換されるとエラーになってしまうので、可能なら空白を入れない変換があるとありがたいと思いました。
コメントありがとうございます。
MS-ACCESSだとそんな構文があるんですね。
要望承りました。
更新まで気長にお待ちください。
めちゃめちゃ使わせていただいております!
ON句だけ整形すると、全角スペースになるのなんとかなるとありがたいです!
返信遅くなり申し訳ありません。
全角スペースになるでしょうか?
こちらで再現できなかったので、SQL文を教えてもらえると助かります
AND/OR/ON整形を「前」で設定した場合もインデントをつけていただけるとありがたいです。
個人的にはwhereとandが同じ位置だと若干読みづらいので…
返信遅くなり申し訳ありません。
ご要望ありがとうございます。
検討させていただきます。
自力インデントが面倒かつ苦手なのででいつも愛用させて頂いています。
比較の時に使う「==」が「= =」(イコールの間に半角スペース)と変換され、SQLite3.24環境ではエラーとなります。
イコールが二つ連続した時はスペースを入れないようにして頂けますと嬉しいです。
返信遅くなり申し訳ありません。
「==」なんて記号があるんですね。
Oracle上がりの管理人は知りませんでした。。
こちら検討させていただきます。
いつも愛用させて頂いております。
CROSS JOINのみ、
FROM
TABLE AS t CROSS
JOIN
pivot AS p
という改行がされます。
他のINNER JOINなどと同じように
FROM
TABLE AS t
CROSS JOIN
pivot AS p
で改行に変更をお願いします。
返信遅くなり申し訳ありません。
ご要望ありがとうございます。
検討させていただきます。
お世話になっております。
==を整形すると = =と間に空白が入ってしまい、SQLiteでエラーとなってしまうのを何とかして頂けると嬉しいです……。
返信遅くなり申し訳ありません。
「==」の件、スペースが入らないよう検討させていただきます。
いつも便利に使わせて頂いてます。
–のコメント行の次の行がAND句の場合インデントが
ずれるようです。
お手数ですが、確認して頂けますか?
ご要望ありがとうございます。
コメントはイマイチですよね。。
検討させていただきます。
便利なツールをありがとうございます。
このようなSQLの場合、
select * from AAA inner join BBB on AAA.X = BBB.X
union
select * from CCC inner join DDD on CCC.X = DDD.X
unionの前後でインデントの仕方が異なってしまうようです。
ご対応いただけるとうれしいです。
>ksさん
コメントありがとうございます。
これはバグですね。。
修正検討します。
いつも便利で利用させて頂いております。
一点不具合のような挙動がありましたので、ご確認お願いします。
SELECT * FROM test WHERE name = ””
のようなシングルクォーテーションをエスケープしたSQLを変換しますと、
SELECT * FROM test WHERE name = ” ”
のようにシングルクォーテーションの間に空白が入ってしまいます。
優先度は低くて大丈夫なのですが、できれば対応していただけると助かります。
コメントありがとうございます。
シングルクォーテーションのエスケープの考慮不足のようです。
修正検討させていただきます。
気長にお待ちください。。
愛用させて頂いています。
Oracleの
ORDER BY
hoge
,fuga
/
COMMENT ON TABLE “table1” IS ‘使用用途’
/
というのを変換すると、
ORDER BY
hoge
,fuga / COMMENT
ON TABLE “table1” IS ‘使用用途’ /
となってしまいます。
お手数ですが、
/ COMMENT ON TABLE
の辺りの修正を要望します。
コメントありがとうございます。
返信遅れましてすいません。
こちら検討させていただきます。
非常に便利なツールをありがとうございます!
様々な成型ツールを利用させていただきましたがこちらが一番でした!
一点だけ何とかならないかなと思っていることなのですが、改行の有無を指定できると非常に助かります。
例えば、俗人的?な書き方かもしれませんが、
私の場合はFROMの後やGROUP BYとORDERBYの後は改行無して書いた方がスッキリして見やすいです。
例:
FROM ○テーブル名○
GROUP BY 1,2,3,4,5
お手すきの際で構いませんのでご検討いただけますと幸いです。
愛用させて頂いています。
一点不具合のような挙動がありましたので、ご確認お願いします。
サブクエリ内にHAVINGが存在し、ANDやORなどの改行対象の項目が存在する場合、
andのインデント位置がサブクエリ閉じ括弧のインデント位置と同じとなるようです。
SELECT * FROM(SELECT A,SUM(A),count(A) FROM AAA GROUP BY B HAVING SUM(A) > 0 AND count(A) > 1) HOGE
CASE文について
改行するか一行に納めるか選択できるようにするのは難しいでしょうか?
CASE文を複数回連続で書いた際、可読性が低いので、、、
いつも愛用させていただいています。
CASE文のAND/ORを前で整形する場合、WHENと同じインデント位置にする方が見易いと思いますがいかがでしょうか。
SELECT
CASE
WHEN FIELDA = ‘*’
AND FIELDB = ‘*’ THEN ‘X’
ELSE ‘Y’
END
FROM
DUMMY
ご検討いただけると幸いです。
文字列内でシングルクォーテーションを利用したいとき、
”あいうえお” → ” あいうえお”
”” → ” ”
の様にスペースが入ってしまう部分を修正もしくは空白を入れないよう選択したいです。
また、and/or/onに関してなのですが
select
a,
b
from
z
where
a = 0
and
b = 1
;
のようにwhere句と位置を揃え、条件文は改行しwhere下と同様のインデントを付けた形を選択できると嬉しいです。
いつも愛用させていただいております、難しいかもしれませんがご検討いただければ幸いです。
毎日仕事で便利に使わせてもらっています。
ここ数年お世話になっているので、ちゃんとお礼を言っておこうと思いました。
いつもありがとうございます。