★★★Access2000VBA・Excel2000VBA独学～「QueryTableオブジェクト」～～「VBAプログラム」からも、「MicrosoftQueryの画面」からも操作が可能となる、そのための「VBAからのSQLの書き方」や「前提条件」など（概要説明のみ）～
※まだ書きかけです。すみません。
※間違ってたらすみません。
※メモ書きなので、自分でも意味不明な箇所も多いです。ごめんなさい。
目次
★ はじめに
★ 実際に行うこと。
▼ (A)各ドライブのルートやデスクトップに置いたExcelファイルは読みにいかない。
▼ (B)自ファイルを読みにいかない。特にxlsmやxlsx。
▼ (C)VBA側のSQLに、MicrosoftQueryの画面での「SQLの方言」を使う。
SQL文の作成について
★ 補足（なぜ今回の記事のようなことが必要か？）
※Shift＋TABキー、もしくは、Homeキー、Homeキー＋TAB数回、を押すと、目次付近に戻れます。
※2007以降？で、「テーブル機能」のテーブルの中に自動的に埋め込まれる「QueryTableオブジェクト（＝MicrosoftQueryの表）」も同じです。（2007以降で、MicrosoftQueryの画面から手動で作成した表のSQL内容を、VBAプログラムで書き換えるケースも、本記事と同じ理屈が適用できます。）
★ はじめに
手動ではなくて、「VBAプログラム」から SQL命令を使って任意のシート上に出来上がった「表」（＝QueryTableオブジェクト：下図）は、さらにVBAプログラムによってSQL内容を書き換えることでその表示内容を刻々と・どんどんと・色々に・自動的に・変化させることができます。（＝集計、リストアップ の結果を自動的に変えていくことができます。）
そしてこの表は、「本来は」それを右クリックして「クエリの編集」を押すと、「MicrosoftQueryの画面」を呼び出して・・・、つまりGUIにて、色んなデータ操作ができるようになっています。（下図）
↓ ↓ ↓ ↓ ↓ ほんとならこうなるはず・・・
ところが、冒頭にも書きましたように（手動ではなく）「VBAプログラム」から自動でこの表を作ってしまった場合は、現実には、例えば以下のようなエラーが出て、「MicrosoftQueryの画面」からはデータ操作が行えないことが多いです。（下図）
というわけで、ここでは、２つ上の図のように、「MicrosoftQueryの画面」からもデータの内容修正や各種操作が可能となる、「VBAからのSQLの書き方」や「前提条件」などを、ご紹介したいと思います。
つまり、「VBAプログラム」からでも、「MicrosoftQueryの画面」からでも、どちらからでも、データ修正や各種操作（＝SQLの内容変更＝各種の集計やリストアップ等々）ができるようにします。
そのための、「VBAからのSQLの書き方」や「前提条件」です。
現在のところ僕自身の中だけでわかっていることは、以降に書いた(A)～(C)のことです。
(C)は(01)～(04)まである上にかなり長いのですみませんが、でもこの(A)～(C)を守ると、
・「MicrosoftQueryの画面」からも
・「VBAプログラム」からも、
操作が可能な「クエリの表」が作成できます。（シート上に）
なお、余談ですが、パソコンの再インストールのことや他のマシンでも使えるようにすることを考えると、「DドライブやCドライブのルートに作ったフォルダ」の中に置いたExcelファイルのデータを読みに行くのが、のちのちトラブルが少ないです。
つまり、デスクトップやマイドキュメントに配置したExcelファイルは読みにいかないほうが無難です。
（特に長期にわたって扱うファイルの場合は。）
読みに行くExcelファイルのフォルダは「固定」したフォルダに置くことをおススメします。
では、以降、実際に行うことの項目と、その詳細です。
▼ (A)各ドライブのルートやデスクトップに置いたExcelファイルは読みにいかない。
MicrosoftQueryの画面は出ますが、正常に操作できないことがあるので。
「DドライブやCドライブのルートに作ったフォルダ」の中に置いたExcelファイルのデータを読みに行くのが、のちのちトラブルが少ないです。
例えば、Win2000＋Excel2000（xls）では、OSのインストール直後の状態ではドライブのルートやデスクトップに置いたExcelファイルも正常にMicrosoftQueryの画面で修正ができますが、（WindowsUpdateによるセキュリティ強化等々により）それができなくなることがあります。
「DドライブやCドライブのルートに作ったフォルダ」の中に置いたExcelファイルであればそれがありません。
あと、マイドキュメントもやめておきます。
▼ (B)自ファイルを読みにいかない。特にxlsmやxlsx。
Windows2000＋xls拡張子のファイルならOKかもしれませんが、サポートの切れていないバージョンが比較的新しいExcel（xlsmやxlsx）の場合は、ダメっぽいです。
表の作成自体はできるのですが、
そのあとに、表示内容を変更したくなったときに、
MicrosoftQueryの画面を開こうとすると、「ファイルを認識できません」的なエラーに
なってしまうためです。（いったん表を全消ししてから作り直すしか方法がありません。）
「DドライブやCドライブに作ったフォルダ」の中に置いたExcelファイルでも、
自ファイルの内容を読み行った場合は、修正しようとすると、そうなってしまうので、
基本、自ファイルは読みにいかないようにします。
（あくまでも、「MicrosoftQueryの画面を使いたい場合だけ」です。）
※もちろん、SQLについてとても詳しい方は、「VBAだけでいい」
「 MicrosoftQueryの画面なんていらない」となると思いますので、
その際はもちろん、自ファイルを読みに行っても大丈夫です。
ちゃんと、SQL文の内容通りの表を、シート上に表示することができます。
そのSQL内容でのパラメータクエリの条件値の入力を、
「指定したシートの指定したセルにする」ということも可能です。
それもVBAプログラムで指定できます。
（Parameterオブジェクトなどを使います。）
▼ (C)VBA側のSQLに、MicrosoftQueryの画面での「SQLの方言」を使う。
「MicrosoftQueryの画面も使える」「SQLの方言の条件」は、今の時点で分かっているのは、以下のとおりです。
(01)SQL文の最後尾に「;」（セミコロン）をつけない。
(02)テーブル名は角カッコではなく「`」バッククォートで囲む。
（同名の列が複数存在してテーブル名が必要なときも。
もちろん、テーブル名に付加する「$」はそのままです。）
(03)テーブル名の省略はできるところではできる。
（ほぼ、本当のルール＝一般的なルールと同じと思われます。）
(04)リレーションは、JOINではなく、FROMとWHEREで。
※：SQLに詳しい方にとってはバカみたいな話かもしれませんが、
「MicrosoftQueryの画面のほう」で自動的に生成されたSQL文を、
VBAの中でも「まんま」で使うと、基本的には大丈夫なようです。
「自動的に生成され」るSQL文とは、VBAプログラムにSQLを書く前に、
先に「MicrosoftQueryの画面のほう」にて調べた、
『 手動（ドラッグやクリック等中心）でクエリを作成した時に自動生成されるSQL文 』
のことです。
MicrosoftQueryの画面の「表示」→「SQL」メニューにて、もしくは
「SQL」ボタンの押下にて、自動生成されたSQL文を表示することができます。
実はMicrosoftQueryは、その画面を開いているあいだは、
『 一般的なルールでSQLを書いても、勝手に「方言」に変換されてしまう』、
ということがけっこうあります。(Accessも同じ）
でも、なのでそれを逆手にとって、その変換後のSQLをVBAプログラムの中で使うと、
『VBAプログラムからも、MicrosoftQueryの画面両方からも、両方から扱える「表」が作れる・・・』、ということになります。
（テーブル名は省略できるところは、エラーさえ出なければ省略してもOKです。）
繰り返しになりますが、SQLに詳しい方にとってはバカみたいな話かもしれません。
でも、僕のようなSQL初心者には、「何が違うんだろ？なんで同じ結果が出るんだろ？」と
調べることも勉強になりますので、「意味がないこと」では決して無いと思います。
つまり、MicrosoftQueryの画面を「SQL自動生成器」として使う・・・という意味です。（これはAccessの「クエリ」機能でもまったく同じことができます。）
もちろん、その「まんま」のSQL文を使わずに、一般的なSQL文を使ったとしても、
表はちゃんとそのSQL内容にそって正常に表示されます。
「MicrosoftQueryの画面からの編集作業」だけができなくなる・・・、
というだけなので、特に心配はいりません。
SQLに詳しい人は、MicrosoftQueryの画面のことなど考えずに、普通のSQL文を
使えばOKかと思います。
（ExcelやAccessの場合、使えない命令も少しあるようですが、大抵のことはできます。）
**************************************************************
SQL文の作成について
「MicrosoftQueryの方言」のルールでのSQL文を書くと、
VBAからSQL文を書いた場合でも、MicrosoftQueryの画面が、
基本・必ず使えるようになるようです。
一般的なSQL文を使うとMicrosoftQueryの画面が
エラーになって使えないことがあります。
特に最後尾に「;」（セミコロン）をつけた場合がダメでした。
正式なSQL文のルールを受け付けないなんて、
MicrosoftQueryはおかしいといえばおかしいのですが・・・。
ただ、SQLのなんとなくの勉強には必ずなります。
そして その「なんとなく」レベルであっても、（上級者向けの
パソコン教室などが教えてくれるような）「一般的なVBA」や
「関数多用」での集計やリストアップよりも、
できることが遥かに多いし、柔軟で強力です。
特に、データ追加や書き換えはともかく、「複雑な条件での集計・リストアップ」では。
「条件以外のもの」も比較的早く処理できる仕組みがあらかじめ、あります。
また、ループのプログラムは書かなくていいし、条件がいつもあっても、
多くは SQL 1発 で対応できます。
ワークシート関数のようにネスト的（入れ子構造的）なこともできますし。
（「副問い合わせ」という機能です。
『 「多段的な」かつ「しかも各段が複数の条件付き」の集計やリストアップを
ループを一切使わずに 1発で終わらす・・・』、
という機能です。 また、
閉じたExcelファイルへの、「閉じたままの」データ追加や書き換えもできますが、
例えば ”共有閲覧ファイル” に対してそれを本当にやっていいかは別議論となります。
自分だけが使うなら、もちろん、基本的には、追加や書き換えもOKだと思います。
LANネットワーク越しの、ファイルサーバへのファイルに対しても、ExcelやOffice、
OS、その他各種のセキュリティ設定にひっかかりさえしなければ、
エラーも出ずにそれが可能だと思います。）
「Access」や「SQLServer」が無くても、その雰囲気（仕組みなど）やSQL文の書き方の大筋の勉強ができてしまいますし。
もちろん、コストも2～10倍は安く抑えられます。
（プログラム作成人件費抑制やスピードアップなどによるコストダウンが可能です）
ちなみに、「方言・できないこと」というのは、「AccessのSQL」にもあります。
なお、方言には 「 "SELECT * ・・・ " 」と、
全列の表示に「*」（アスタリスク）も一応、使えます。
ある程度の、テーブル名の省略も可能かもしれません。
SELECT句では、同名の列名が無い限り、テーブル名を
省略できるっぽいです。
FROM句もテーブル名のダブりの省略はできるっぽいです。
WHERE句も列名が一意の場合は、省略できるっぽいです。
ただし、最後に「;」（セミコロン）をつけると、
結果の表は出てきますが、MicrosoftQueryの画面を開こうとすると、
「COUNTフィールドが正しくありません」という、
よくわからないエラーになります。
テーブル名を「`」バッククォートで囲むのではなく、
角カッコ（[ ]）で囲んだ時もこのエラーになるようです。
なお、IN句など他の句での省略や、そもそもそれらの句の
「本当のルール」がOKなのか？などは、チェックしていません。
ちなみに、JOINでのリレーションだとMicrosoftQueryの画面は
エラーで出せませんでした。
FROMとWHEREでのリレーションはOKでした。
バカみたいな話ですが、
「MicrosoftQueryの画面のほう」で自動的に生成されたSQL文を、
VBAの中でも「まんま」で使うと、基本的には大丈夫なようです。
※「自動的に生成され」るSQL文とは、先に「MicrosoftQueryの画面のほう」で
手動（ドラッグやクリック等中心）でクエリを作成した時に自動生成されるSQL文です。
MicrosoftQueryの画面の「表示」→「SQL」メニューにて、もしくは
「SQL」ボタンの押下にて、自動生成されたSQL文を表示することができます。
『 一般的なルールでSQLを書いても、自動的に「方言」に変換されてしまう』、
ということがけっこうあります。
なので逆に、その変換後のSQLをVBAプログラムの中で使うと、
VBAプログラムからも、MicrosoftQueryの画面両方から扱える「表」が作れる、
ということになります。
ただ、繰り返しになりますが、それに「;」（セミコロン）を
最後尾につけるとダメでした。
「ガワ」のウィンドウは出せますが、肝心の「中身の子ウィンドウ」が
が出せなくなります。
（もしかしたら、エラーダイアログをOKボタンで消したあとに、単独のMicrosoftQueryのガワの画面から再度、表を作成することもできるかもしれませんが、前回の状態は消えてしまっていて、とてもやりづらいので、ここではそこまでやりません。）
まとめると、
「MicrosoftQueryの画面も使える」「SQLの方言の条件」は、
今の時点で分かっているのは、以下のとおりです。
(01)最後尾に「;」（セミコロン）をつけない。
(02)テーブル名は角カッコではなく「`」バッククォートで囲む。
（同名の列が複数存在してテーブル名が必要なときも。）
(03)テーブル名の省略はできるところではできる。
（ほぼ、本当のルールと同じと思われます。）
(04)リレーションは、JOINではなく、FROMとWHEREで。
★★※：ただし「;」（セミコロン）をつけてもJOINでリーレーションしても、
MicrosoftQueryの画面が使えなくなるだけで、
クエリの結果は正しく表示されます。
SQLに精通していて、
「MicrosoftQueryの画面なんか要らない」、という方は、
むしろ、「;」をつけた正しい書き方を使えば、
OKかと思います。
**************************************************************
※2007以降？だと思いますが、手動でMicrosoftQueryの画面にて結果の表を作成すると、「テーブル」機能の「テーブル」の中に勝手にMicrosoftQueryの結果（QueryTableオブジェクト）が自動生成されます。
なので、イミディエイトウィンドウから「QueryTableオブジェクト」を参照するには
「? Sheets("MsQRY吸込").ListObjects(1).QueryTable」
と書くと、参照できます。
また、前述のルールもそれには適用されます。（MicrosoftQueryの画面が出せるSQL文を生成したい際には。）
Excelで「SQL」を扱う場合、
▼「シート上に表われる ”QueryTableオブジェクト”」というものを操作する方法、と、
▼「DAO」や「ADO」と呼ばれる機能を使って、「VBAプログラムの中だけで」操作する方法
の２つの方法があります。
そして、前者の場合、その”QueryTableオブジェクト”の操作には、これまた、
・「MicrosoftQueryの画面」からSQLにて操作する方法と、
・「VBAプログラム」からSQLにて操作する方法、
の２つがあります。
いずれも「SQL」を使います。
（「MicrosoftQueryの画面」ではSQLを知らなくても、操作できるようにはなっていますが）
ただ、「そもそも」のお話ですが、QueryTableオブジェクトを使って、何らかの表のデータを読んだり変形・操作・集計・リストアップ等々をしたいときは、「MicrosoftQueryの画面」を使わなくても全然大丈夫です。
基本、「VBAからだけの」SQLによって、十分にデータ操作ができます。
特に、「SQLに詳しい方」にとっては、「MicrosoftQueryの画面」は全く必要ありません。
が、次のような場合は、MicrosoftQueryの画面を使いたいときがあります。（というか多分、多いと思います。）
(A)：初心者の頃にSQLの組み立てが分からない場合。
（僕はこれです。MicrosoftQueryの画面はドラッグやクリック、あるいは簡単な入力で、「自動的にSQL文を生成してくれる」ので便利です。）
(B)：プログラマやSEじゃない、営業や経理の方などがSQLを使ってデータの操作をしたい場合。（僕はこれもです。）
一般的な職場では上記の(A)（B)のようなケースが多いので、基本的には「MicrosoftQueryの画面」が必要になると思われます。そしてかなり便利に重宝して使えると思います。
でも、「VBAでもSQLを操作したい」、という要望もあるかと思います。
なので、そんなときのために、「MicrosoftQueryの画面」と「VBAプログラム」の両方から、「エラーを出さずに操作が可能となる」、「SQLの書き方やその事前準備」は、必要なことであると言えます。
