AccessでUPDATEの更新値でサブクエリを使えない DMaxを使えばエラーにはならない [Accessクエリ]
えーと本日はAccessでのサブクエリの話題である。
先日、Accessで他のテーブルにある値で更新かけたいんだけど、と言った質問を受けた。
何も考えずに、サブクエリ使えば良いのでは?
と答えたのだが、サブクエリを使うと「更新可能なクエリであることが必要です」のエラーになるというではないか。
えーそうなの?と思いSQLポケットリファレンス を見てみると...
UPDATE命令のサブクエリを使って更新のところをみると...
の注意書きが...
自分で書いておいて忘れていた。
じゃあ、結合して参照すれば?
と手のひら返しで答えたのではあるが、AccessってUPDATEでFROM句書けたっけか?
AccessではUPDATEにFROM句は書けないが、INNER JOINできる。
みたいに書けば良いらしい。ふーん。SQLポケリには書いてないなぁ。しまった。
でも単純に結合したテーブルの列を参照して更新するわけにはいかないようで、この作戦も失敗。
どうも結合すると複数行のデータが出てきてしまい、サブクエリでMAXを使わないといけないらしい。
どうしたものかとネットを検索しているとDMaxなら使えるような記事を発見。
そうか、DMaxなら使えるのか。前に記事を書いたかも。
DSumやらDMaxは、定義域集合関数っていう関数でサブクエリみたいな集合関数である。Access独自の関数である。詳しくは上の関連記事を参照して欲しい。
以下のクエリはAccessではエラーになるが
以下のクエリなら実行可能。
結論としては
AccessでUPDATEでサブクエリは使えないが、定義域集合関数なら使えるっていうこと。
本日は以上
関連記事
AccessクエリとSQLの関係 デザインビューとSQLビュー
AccessクエリとSQLの関係 フィールド
AccessクエリとSQLの関係 フィールドに式を書く
AccessクエリとSQLの関係 並び替え
AccessクエリとSQLの関係 抽出条件
AccessクエリとSQLの関係 抽出条件(または)
AccessクエリとSQLの関係 抽出条件(INとLIKE)
AccessクエリとSQLの関係 抽出条件(表示のチェックボックス)
サイト内を検索
先日、Accessで他のテーブルにある値で更新かけたいんだけど、と言った質問を受けた。
何も考えずに、サブクエリ使えば良いのでは?
と答えたのだが、サブクエリを使うと「更新可能なクエリであることが必要です」のエラーになるというではないか。
えーそうなの?と思いSQLポケットリファレンス を見てみると...
UPDATE命令のサブクエリを使って更新のところをみると...
UPDATE foo SET a = (SELECT MAX(b) FROM bar) WHERE c = 1
*上記の例はAccessでは実行できません。
*上記の例はAccessでは実行できません。
の注意書きが...
自分で書いておいて忘れていた。
じゃあ、結合して参照すれば?
と手のひら返しで答えたのではあるが、AccessってUPDATEでFROM句書けたっけか?
AccessではUPDATEにFROM句は書けないが、INNER JOINできる。
UPDATE foo INNER JOIN bar ON foo.a = bar.a SET foo.a = bar.b WHERE c = 1
みたいに書けば良いらしい。ふーん。SQLポケリには書いてないなぁ。しまった。
でも単純に結合したテーブルの列を参照して更新するわけにはいかないようで、この作戦も失敗。
どうも結合すると複数行のデータが出てきてしまい、サブクエリでMAXを使わないといけないらしい。
どうしたものかとネットを検索しているとDMaxなら使えるような記事を発見。
そうか、DMaxなら使えるのか。前に記事を書いたかも。
DSumやらDMaxは、定義域集合関数っていう関数でサブクエリみたいな集合関数である。Access独自の関数である。詳しくは上の関連記事を参照して欲しい。
以下のクエリはAccessではエラーになるが
UPDATE foo SET a = (SELECT MAX(b) FROM bar) WHERE c = 1
以下のクエリなら実行可能。
UPDATE foo SET a = DMAX("b", "bar") WHERE c = 1
結論としては
AccessでUPDATEでサブクエリは使えないが、定義域集合関数なら使えるっていうこと。
本日は以上
Access クエリ 徹底活用ガイド ~仕事の現場で即使える
- 作者: 朝井 淳
- 出版社/メーカー: 技術評論社
- 発売日: 2018/05/25
- メディア: 大型本
関連記事
AccessクエリとSQLの関係 デザインビューとSQLビュー
AccessクエリとSQLの関係 フィールド
AccessクエリとSQLの関係 フィールドに式を書く
AccessクエリとSQLの関係 並び替え
AccessクエリとSQLの関係 抽出条件
AccessクエリとSQLの関係 抽出条件(または)
AccessクエリとSQLの関係 抽出条件(INとLIKE)
AccessクエリとSQLの関係 抽出条件(表示のチェックボックス)
サイト内を検索
Access クエリ 徹底活用ガイド ~仕事の現場で即使える 出版 [Accessクエリ]
みなさんこんにちは。
本日は、本の宣伝記事です。
本ブログにもAccessの記事がちらほらと出るようになったのは、この本を書いていたからなのです。
骨折入院する前には書き上がっていたのではあるが、校正作業が始まろうかという頃に入院となってしまった。
入院記事はこちらを参照
えらい大変なことになってしまった 転倒 左大腿骨転子部骨折 入院
退院後、なんとか校正を終え、無事に出版の運びとなった。
技術評論社の方々には、大変面倒をかけてしまったと思います。
この場を借りて、お礼を申し上げます。
ありがとうございます。
サイト内を検索
本日は、本の宣伝記事です。
本ブログにもAccessの記事がちらほらと出るようになったのは、この本を書いていたからなのです。
Access クエリ 徹底活用ガイド ~仕事の現場で即使える
- 作者: 朝井 淳
- 出版社/メーカー: 技術評論社
- 発売日: 2018/05/25
- メディア: 大型本
骨折入院する前には書き上がっていたのではあるが、校正作業が始まろうかという頃に入院となってしまった。
入院記事はこちらを参照
えらい大変なことになってしまった 転倒 左大腿骨転子部骨折 入院
退院後、なんとか校正を終え、無事に出版の運びとなった。
技術評論社の方々には、大変面倒をかけてしまったと思います。
この場を借りて、お礼を申し上げます。
ありがとうございます。
サイト内を検索
AccessクエリとSQLの関係 サブクエリとDSum DMax [Accessクエリ]
本日は、MS Accessの話題である。
Oracleなどには、SUM() OVERっていう関数がある。分析関数なので、使い方が集計関数とちょっと違う。
みたいにして使う。
分析関数についてはこちら
MS Accessでは分析関数は使えない、と思っていたのではあるが、DSumなる関数を発見。これって分析関数なんじゃない?ということでちょっと調べている。
DSum(フィールド名, テーブル名, 条件式)
と書いてある。どの引数も文字列で渡す。DSumなので、合計値が戻るらしい。
ふーん、なんとなくわかった。
サブクエリで書くところを、DSum関数でわかりやすくしただけかも?
SUM() OVERとは文法も違うし、機能もちょっと違う感じか。
DSumの最後の引数、条件式は省略可能とのこと。
DSum(フィールド名, テーブル名)
そうか。これならなんとなく「SELECT SUM(フィールド名) FROM テーブル名」で得られるものと同じ感じがする。
ちょっとやってみるか。
サブクエリを使って検索をしたい場合のよくあるシチュエーションに、ある条件の最大値となっているレコードはどれか、といったものがある。サブクエリでMax集計関数を使うのだな、ということが推測される。
ここで、住所録テーブルに登場してもらおう。
住所録テーブルから最年長者のデータを取得するのには、
な感じである。
このクエリでもちゃんと最年長のデータを取得できる。
サブクエリの代わりにDMaxが使えるはずである。サブクエリの部分をDMaxに置き換えてみよう。
これで実行してみると...
おっ、できた。DMax関数の引数は、文字列形式となることに注意。普通の集計関数のようにフィールド名を書いてはいけない。文字列で渡さないとダメなのである。
こんな風に書くと、ちゃんと結果が戻ってこない。
男性の最年長者と女性の最年長者の2レコードが欲しくなったとする。
サブクエリで書いた場合は、以下のようになる。
サブクエリと上位のクエリで同じ住所録テーブルを使うので、別名を切るところがポイント。
DMaxでも条件式が書けるので、同じことをやってみよう。
やった。これもできた。
実際は、以下のようにSQLビューでクエリを作成している。
条件式を文字列で組み立てる必要があるので、なんかやっかい。
サブクエリで書いてもDMaxで書いても大差ない気がする。
分析関数のDENSE_RANKを使えば、順位が計算できる。DENSE_RANKが使えない場合は、サブクエリを書けばよい。
年収が高い順に順位をつけてみた。NULLデータが含まれるので、Nzで年収がNULLなら0として扱う。
ORDER BYを書くのが面倒だったので、データシートビューの並べ替え機能で、順位を並び替えしている。
同点の場合に順位が飛ぶので、正確にはDENSE_RANKではなくRANKの代用となる。
しくみとしては、単純。サブクエリとなっているので難解のように見えるが、基本は、より高い年収となっているレコードの数をCountで数えているだけ。最上位のデータは上位にレコードがないので、0になる。0位というのもおかしいので、+1して最上位は1位としている。
サブクエリで、Countを使用しているのなら、DCountに変更できるはずである。
やってみよう。
できた。
まぁ、どっちでも好きな方を使えばいいかも、ですな。
DSumとSUM OVERの話もやりたかったが、本日は、ここまで。
関連記事
AccessクエリとSQLの関係 デザインビューとSQLビュー
AccessクエリとSQLの関係 フィールド
AccessクエリとSQLの関係 フィールドに式を書く
AccessクエリとSQLの関係 並び替え
AccessクエリとSQLの関係 抽出条件
AccessクエリとSQLの関係 抽出条件(または)
AccessクエリとSQLの関係 抽出条件(INとLIKE)
AccessクエリとSQLの関係 抽出条件(表示のチェックボックス)
AccessでUPDATEの更新値でサブクエリを使えない DMaxを使えばエラーにはならない
サイト内を検索
Oracleなどには、SUM() OVERっていう関数がある。分析関数なので、使い方が集計関数とちょっと違う。
SUM(a) OVER (PARTITION BY xxx)
みたいにして使う。
分析関数についてはこちら
MS Accessでは分析関数は使えない、と思っていたのではあるが、DSumなる関数を発見。これって分析関数なんじゃない?ということでちょっと調べている。
DSum(フィールド名, テーブル名, 条件式)
と書いてある。どの引数も文字列で渡す。DSumなので、合計値が戻るらしい。
ふーん、なんとなくわかった。
サブクエリで書くところを、DSum関数でわかりやすくしただけかも?
SUM() OVERとは文法も違うし、機能もちょっと違う感じか。
DSumの最後の引数、条件式は省略可能とのこと。
DSum(フィールド名, テーブル名)
そうか。これならなんとなく「SELECT SUM(フィールド名) FROM テーブル名」で得られるものと同じ感じがする。
ちょっとやってみるか。
サブクエリを使って検索をしたい場合のよくあるシチュエーションに、ある条件の最大値となっているレコードはどれか、といったものがある。サブクエリでMax集計関数を使うのだな、ということが推測される。
ここで、住所録テーブルに登場してもらおう。
住所録テーブルから最年長者のデータを取得するのには、
SELECT * FROM 住所録 WHERE 年齢 = (SELECT MAX(年齢) FROM 住所録)
な感じである。
このクエリでもちゃんと最年長のデータを取得できる。
サブクエリの代わりにDMaxが使えるはずである。サブクエリの部分をDMaxに置き換えてみよう。
SELECT * FROM 住所録 WHERE 年齢 = DMax("年齢", "住所録")
これで実行してみると...
おっ、できた。DMax関数の引数は、文字列形式となることに注意。普通の集計関数のようにフィールド名を書いてはいけない。文字列で渡さないとダメなのである。
SELECT * FROM 住所録 WHERE 年齢 = DMax(年齢, 住所録)
こんな風に書くと、ちゃんと結果が戻ってこない。
男女別に最大値で検索したい
男性の最年長者と女性の最年長者の2レコードが欲しくなったとする。
サブクエリで書いた場合は、以下のようになる。
SELECT * FROM 住所録 AS T WHERE T.年齢 = (SELECT MAX(年齢) FROM 住所録 WHERE T.性別 = 性別)
サブクエリと上位のクエリで同じ住所録テーブルを使うので、別名を切るところがポイント。
DMaxでも条件式が書けるので、同じことをやってみよう。
SELECT * FROM 住所録 AS T WHERE T.年齢 = DMax("年齢", "住所録", "性別='" & T.性別 & "'")
やった。これもできた。
実際は、以下のようにSQLビューでクエリを作成している。
条件式を文字列で組み立てる必要があるので、なんかやっかい。
サブクエリで書いてもDMaxで書いても大差ない気がする。
DCountで順位の計算
分析関数のDENSE_RANKを使えば、順位が計算できる。DENSE_RANKが使えない場合は、サブクエリを書けばよい。
SELECT T.氏名, T.性別, T.年収, (SELECT COUNT(*)+1 FROM 住所録 WHERE Nz(年収,0) > Nz(T.年収,0)) AS 順位 FROM 住所録 AS T
年収が高い順に順位をつけてみた。NULLデータが含まれるので、Nzで年収がNULLなら0として扱う。
ORDER BYを書くのが面倒だったので、データシートビューの並べ替え機能で、順位を並び替えしている。
同点の場合に順位が飛ぶので、正確にはDENSE_RANKではなくRANKの代用となる。
しくみとしては、単純。サブクエリとなっているので難解のように見えるが、基本は、より高い年収となっているレコードの数をCountで数えているだけ。最上位のデータは上位にレコードがないので、0になる。0位というのもおかしいので、+1して最上位は1位としている。
サブクエリで、Countを使用しているのなら、DCountに変更できるはずである。
やってみよう。
SELECT T.氏名, T.性別, T.年収, DCount("氏名", "住所録", "Nz(年収,0) > " & Nz(T.年収,0)) + 1 AS 順位 FROM 住所録 AS T
できた。
まぁ、どっちでも好きな方を使えばいいかも、ですな。
オレ的には、サブクエリだなぁ...汎用性もありそうだし。DMaxやDCountはAccessでないと使用できない。OracleやSQL Serverには存在しない。
DSumとSUM OVERの話もやりたかったが、本日は、ここまで。
Access クエリ 徹底活用ガイド ~仕事の現場で即使える
- 作者: 朝井 淳
- 出版社/メーカー: 技術評論社
- 発売日: 2018/05/25
- メディア: 大型本
関連記事
AccessクエリとSQLの関係 デザインビューとSQLビュー
AccessクエリとSQLの関係 フィールド
AccessクエリとSQLの関係 フィールドに式を書く
AccessクエリとSQLの関係 並び替え
AccessクエリとSQLの関係 抽出条件
AccessクエリとSQLの関係 抽出条件(または)
AccessクエリとSQLの関係 抽出条件(INとLIKE)
AccessクエリとSQLの関係 抽出条件(表示のチェックボックス)
AccessでUPDATEの更新値でサブクエリを使えない DMaxを使えばエラーにはならない
サイト内を検索
AccessクエリとSQLの関係 Accessグループ化 集計クエリ [Accessクエリ]
さて、本日は、MS Accessの話題である。
例によって、クエリのデザインビューとSQLビューの対比の記事である。
Accessでのテーブルの結合方法についてやってみたかったのだが、その前にグループ化をやっていなかった。ちょっとやってみよう。
グループ化
そもそも、グループ化とはなんぞや。というところから始めるとする。
「SQLはじめの一歩」を始め、いろいろとグループ化の概念を説明してきたわけではあるが、言葉で説明するのが結構難しかったりする。図を書いてイメージしたらすんなり理解できるものであるように思える。
あーんでも図作るの面倒だし。
ということで、文章で説明していくことにする。
グループ化というのは、グループに分ける作業のことを言う。誰がグループに分ける作業をやっていくれるかというと、それはデータベースシステムの方である。ユーザは、SQL命令とかでグループ化してね、とシステムに命令するわけである。
何を単位に選別されるかというと、データベースではレコード単位で選別されることになる。
このレコードはグループA、こっちはグループBという風にAccessが命令に従って分類してくれる。
どういう感じでグループ分けしたいのかはクエリの命令で設定できる。
よくやるのは、一つの列を指定するだけ、というもの。
とある列を指定すると、その列の値が同じものを集めてグループ分けされるようになる。
グループ分けをしたら、何ができるようになるのかというと、グループ単位で合計や平均を計算したりすることが可能になるのである。多くは、合計計算とか個数計算かな。俗に言う「集計」ができるようになるのである。
グループする条件がない、という場合もある。そうすると、分類する必要がないので、全体が一つのグループになる。
クエリのデザインビューでグループ化をやってみよう。まずは、適当なテーブルを作成する。SQLポケリの集計関数にある住所録テーブルを例にすることにしよう。
クエリのウインドウって文字が小さいですよね。
最近のディスプレイは高解像度なのは良いが、文字が小さ過ぎる。
そんな関係で、フォントサイズを12ポイントに設定している。
ファイル -> オプション -> オブジェクト デザイナ
のクエリ デザインのフォントで変更可能。
集計クエリ
さて、話が脱線気味になってしまった。本題である、グループ化をやってみよう。
グループ化をするには、クエリを「集計クエリ」にすれば良い。
住所録テーブルからSELECTするクエリを作成し、集計ボタンをクリックする。
集計クエリボタンをクリックすると、デザインビューに「集計」の入力欄が増える。
この入力欄にグループ化したい列をズバリ「グループ化」に指定していく。
グループ化したい列のところを「グループ化」にすればよいのだが、住所録テーブルの何でグループ化すべきか。
順当なところで、「性別」でグループ化してみよう。
以下のように設定してみた。
フィールドに結果として欲しい列を指定するわけであるが、集計クエリになっていると、自動的にグループ化が選択される。
この状態で、実行させてみた。ついでにSQLビューがどうなったかも載せておく。
実行結果をみてわかる通り、性別にはふたつのグループがある。「男」と「女」の2グループである。
SQLビューをみると、SELECT命令の後に「GROUP BY」が付いていることがわかる。
集計クエリ = GROUP BY
ということである。
個数の集計
性別にふたつのグループがあることがわかっても「だから何?」な感じである。
集計クエリは、集計関数とともに使用しないと、あまり意味がない。
ここでは、最も基本的な集計関数である「COUNT」を使ってグループの個数を計算してみることにする。
性別には、男と女のグループがあり、それぞれ3個のレコードが存在することがわかった。
ちなみに、デザインビューでの「カウント」は、SQLビューにすると「Count」になる。
本日は、ここまで。
関連記事
AccessクエリとSQLの関係 デザインビューとSQLビュー
AccessクエリとSQLの関係 フィールド
AccessクエリとSQLの関係 フィールドに式を書く
AccessクエリとSQLの関係 並び替え
AccessクエリとSQLの関係 抽出条件
AccessクエリとSQLの関係 抽出条件(または)
AccessクエリとSQLの関係 抽出条件(INとLIKE)
AccessクエリとSQLの関係 抽出条件(表示のチェックボックス)
サイト内を検索
例によって、クエリのデザインビューとSQLビューの対比の記事である。
Accessでのテーブルの結合方法についてやってみたかったのだが、その前にグループ化をやっていなかった。ちょっとやってみよう。
グループ化
そもそも、グループ化とはなんぞや。というところから始めるとする。
「SQLはじめの一歩」を始め、いろいろとグループ化の概念を説明してきたわけではあるが、言葉で説明するのが結構難しかったりする。図を書いてイメージしたらすんなり理解できるものであるように思える。
[データベースの気持ちがわかる]SQLはじめの一歩 (WEB+DB PRESS plus)
- 作者: 朝井 淳
- 出版社/メーカー: 技術評論社
- 発売日: 2015/03/03
- メディア: 単行本(ソフトカバー)
あーんでも図作るの面倒だし。
ということで、文章で説明していくことにする。
グループ化というのは、グループに分ける作業のことを言う。誰がグループに分ける作業をやっていくれるかというと、それはデータベースシステムの方である。ユーザは、SQL命令とかでグループ化してね、とシステムに命令するわけである。
何を単位に選別されるかというと、データベースではレコード単位で選別されることになる。
このレコードはグループA、こっちはグループBという風にAccessが命令に従って分類してくれる。
どういう感じでグループ分けしたいのかはクエリの命令で設定できる。
よくやるのは、一つの列を指定するだけ、というもの。
とある列を指定すると、その列の値が同じものを集めてグループ分けされるようになる。
グループ分けをしたら、何ができるようになるのかというと、グループ単位で合計や平均を計算したりすることが可能になるのである。多くは、合計計算とか個数計算かな。俗に言う「集計」ができるようになるのである。
グループする条件がない、という場合もある。そうすると、分類する必要がないので、全体が一つのグループになる。
クエリのデザインビューでグループ化をやってみよう。まずは、適当なテーブルを作成する。SQLポケリの集計関数にある住所録テーブルを例にすることにしよう。
クエリのウインドウって文字が小さいですよね。
最近のディスプレイは高解像度なのは良いが、文字が小さ過ぎる。
そんな関係で、フォントサイズを12ポイントに設定している。
ファイル -> オプション -> オブジェクト デザイナ
のクエリ デザインのフォントで変更可能。
集計クエリ
さて、話が脱線気味になってしまった。本題である、グループ化をやってみよう。
グループ化をするには、クエリを「集計クエリ」にすれば良い。
住所録テーブルからSELECTするクエリを作成し、集計ボタンをクリックする。
集計クエリボタンをクリックすると、デザインビューに「集計」の入力欄が増える。
この入力欄にグループ化したい列をズバリ「グループ化」に指定していく。
グループ化したい列のところを「グループ化」にすればよいのだが、住所録テーブルの何でグループ化すべきか。
順当なところで、「性別」でグループ化してみよう。
以下のように設定してみた。
フィールドに結果として欲しい列を指定するわけであるが、集計クエリになっていると、自動的にグループ化が選択される。
この状態で、実行させてみた。ついでにSQLビューがどうなったかも載せておく。
実行結果をみてわかる通り、性別にはふたつのグループがある。「男」と「女」の2グループである。
SQLビューをみると、SELECT命令の後に「GROUP BY」が付いていることがわかる。
集計クエリ = GROUP BY
ということである。
個数の集計
性別にふたつのグループがあることがわかっても「だから何?」な感じである。
集計クエリは、集計関数とともに使用しないと、あまり意味がない。
ここでは、最も基本的な集計関数である「COUNT」を使ってグループの個数を計算してみることにする。
性別には、男と女のグループがあり、それぞれ3個のレコードが存在することがわかった。
ちなみに、デザインビューでの「カウント」は、SQLビューにすると「Count」になる。
本日は、ここまで。
関連記事
AccessクエリとSQLの関係 デザインビューとSQLビュー
AccessクエリとSQLの関係 フィールド
AccessクエリとSQLの関係 フィールドに式を書く
AccessクエリとSQLの関係 並び替え
AccessクエリとSQLの関係 抽出条件
AccessクエリとSQLの関係 抽出条件(または)
AccessクエリとSQLの関係 抽出条件(INとLIKE)
AccessクエリとSQLの関係 抽出条件(表示のチェックボックス)
サイト内を検索
AccessクエリとSQLの関係 抽出条件(表示のチェックボックス) [Accessクエリ]
表示のチェック
今回は、Access抽出条件の残りである、表示のチェックボックスの解説をしたい。
このチェックボックスにチェックを入れておくと、SELECT句に含まれるようになる。SELECT句に含まれる式のみが、実行結果として表示される。
なので、チェックが入っていない式は、実行結果に表示されない。
このような、SELECT句に含まれず、実行結果に表示されない式に、なにか意味があるかという素朴な疑問が持ち上がる。
不要なものは削除してしまえばよいだけでは?と思ってしまうのであるが、このチェックボックスがあることでけっこう柔軟にクエリが書けてしまうのである。
抽出条件だけ書きたい場合
結果としては、欲しくないが、抽出条件だけは付けたい、という場合は以下のようにできる。
そう、欲しいのは商品名だけなのだが、検索は商品コードでやりたい、という場合。
まぁ、この場合は商品コードにチェックが入っていても余計な商品コードも表示されてしまうだけなので、別にどっちでも大差ないと思うが...
商品マスタテーブルは「MS Access ルックアップフィールド」で作成したもの。
並び替えの条件を複数書きたい場合
並び替えの条件を複数書きたいとする。注文テーブルのレコードを商品の順で、注文日が新しいもの順にソートしたいとする。並び替えの条件は、商品が昇順で、注文日が降順になるのだが、最初に商品で並び替えて、次に注文日で並び替えることができない。
並び替えの順序は、デザインビューで表示されている順になるからである。
そこで、非表示の列を作ってやる、ということをする。
これで、期待通りに並び替えできた。
まぁ、これも「商品」「注文日」の順になるように入れ替えればいいだけかも知れないが...
今回はここまで。
詳しくは、SQLポケリを参照して欲しいのだ。
関連記事
AccessクエリとSQLの関係 デザインビューとSQLビュー
AccessクエリとSQLの関係 フィールド
AccessクエリとSQLの関係 フィールドに式を書く
AccessクエリとSQLの関係 並び替え
AccessクエリとSQLの関係 抽出条件
AccessクエリとSQLの関係 抽出条件(または)
AccessクエリとSQLの関係 抽出条件(INとLIKE)
AccessクエリとSQLの関係 抽出条件(表示のチェックボックス)
サイト内を検索
今回は、Access抽出条件の残りである、表示のチェックボックスの解説をしたい。
このチェックボックスにチェックを入れておくと、SELECT句に含まれるようになる。SELECT句に含まれる式のみが、実行結果として表示される。
なので、チェックが入っていない式は、実行結果に表示されない。
このような、SELECT句に含まれず、実行結果に表示されない式に、なにか意味があるかという素朴な疑問が持ち上がる。
不要なものは削除してしまえばよいだけでは?と思ってしまうのであるが、このチェックボックスがあることでけっこう柔軟にクエリが書けてしまうのである。
抽出条件だけ書きたい場合
結果としては、欲しくないが、抽出条件だけは付けたい、という場合は以下のようにできる。
そう、欲しいのは商品名だけなのだが、検索は商品コードでやりたい、という場合。
まぁ、この場合は商品コードにチェックが入っていても余計な商品コードも表示されてしまうだけなので、別にどっちでも大差ないと思うが...
商品マスタテーブルは「MS Access ルックアップフィールド」で作成したもの。
並び替えの条件を複数書きたい場合
並び替えの条件を複数書きたいとする。注文テーブルのレコードを商品の順で、注文日が新しいもの順にソートしたいとする。並び替えの条件は、商品が昇順で、注文日が降順になるのだが、最初に商品で並び替えて、次に注文日で並び替えることができない。
並び替えの順序は、デザインビューで表示されている順になるからである。
そこで、非表示の列を作ってやる、ということをする。
これで、期待通りに並び替えできた。
まぁ、これも「商品」「注文日」の順になるように入れ替えればいいだけかも知れないが...
今回はここまで。
詳しくは、SQLポケリを参照して欲しいのだ。
Access クエリ 徹底活用ガイド ~仕事の現場で即使える
- 作者: 朝井 淳
- 出版社/メーカー: 技術評論社
- 発売日: 2018/05/25
- メディア: 大型本
関連記事
AccessクエリとSQLの関係 デザインビューとSQLビュー
AccessクエリとSQLの関係 フィールド
AccessクエリとSQLの関係 フィールドに式を書く
AccessクエリとSQLの関係 並び替え
AccessクエリとSQLの関係 抽出条件
AccessクエリとSQLの関係 抽出条件(または)
AccessクエリとSQLの関係 抽出条件(INとLIKE)
AccessクエリとSQLの関係 抽出条件(表示のチェックボックス)
サイト内を検索
AccessクエリとSQLの関係 抽出条件(INとLIKE) [Accessクエリ]
さて、Accessクエリの続きである。
今回は、前回に続いて、またもや抽出条件である。
ORやANDを抽出条件に書いてみたわけであるが、IN(イン)を紹介していなかったので、ここで解説するのである。
IN 入っているか?
さて、抽出条件とその下の「または」の入力欄には、抽出条件の式を書くことができた。デフォルトで9個の条件を記入することができる。
抽出条件の欄に、Orで連結することでも同じ効果となる条件式になるので、「1 Or 2 Or 3 Or 4」とか書いていけば、長さの制限に引っかかるまでいくらでも条件を追加することができる。
INを使うとこのような条件式を簡潔に記述できる。
IN (1,2,3,4)
とすればOKなのだ。
SQLビューにしても、そのままIN (1,2,3,4)となるだけなので、SQL命令の画面キャプチャは省略。一応、全体を載せておく。
ここまでのまとめ
IN
複数の値のうち、どれかと一致すればOKなとき、IN演算子を使うと便利。
INの括弧の中には、サブクエリーを書くことができるのだがこれは、少々高度な話になってくるので、また後日ということにする。
LIKE あいまい検索 パターンマッチング
ついでながら、部分一致で検索したい場合の抽出条件の書き方についても、解説しておく。
パターンマッチングで、あいまい検索をしたい場合は、「LIKE」を使えばよい。
LIKE '*A*'
とすればa列の値の中にAが含まれているレコードが抽出される。
*の部分は、なんでもOKな、いわゆるワイルドカードである。
SQL標準では、%が相当するメタ文字になるが、Accessでは、*を使った方がよい。
というか、%が使える状況が限定的。
メタ文字の?を使用することで、1文字のワイルドカードになる。
さらには、[A-F] のようにすれば、Aから順にFまでの 「A B C D E F」のいずれか1文字といったワイルドカードにできる。
SQLでのLIKEは、正規表現とは異なったパターン指定となる。Accessにおいては正規表現的な要素があるが、微妙に異なる。また、SQLiteのREGEXPのような正規表現でのパターン検索用の演算子は存在しない。
正規表現自体は、「Microsoft VBScript Regular Expression 5.5」を参照設定すれば、RegExpオブジェクトが利用可能になる。RegExpオブジェクトを使って正規表現を処理するような、自前のVBA関数を作ってやれば、クエリから正規表現によるマッチング検索をできなくもない。
ここまでのまとめ
LIKE
パターンマッチングによるあいまい検索。
今回はここまで。
サイト内を検索
今回は、前回に続いて、またもや抽出条件である。
ORやANDを抽出条件に書いてみたわけであるが、IN(イン)を紹介していなかったので、ここで解説するのである。
IN 入っているか?
さて、抽出条件とその下の「または」の入力欄には、抽出条件の式を書くことができた。デフォルトで9個の条件を記入することができる。
抽出条件の欄に、Orで連結することでも同じ効果となる条件式になるので、「1 Or 2 Or 3 Or 4」とか書いていけば、長さの制限に引っかかるまでいくらでも条件を追加することができる。
INを使うとこのような条件式を簡潔に記述できる。
IN (1,2,3,4)
とすればOKなのだ。
SQLビューにしても、そのままIN (1,2,3,4)となるだけなので、SQL命令の画面キャプチャは省略。一応、全体を載せておく。
SELECT foo.a, foo.b FROM foo WHERE (((foo.b) In (1,2,3,4)));
ここまでのまとめ
IN
複数の値のうち、どれかと一致すればOKなとき、IN演算子を使うと便利。
INの括弧の中には、サブクエリーを書くことができるのだがこれは、少々高度な話になってくるので、また後日ということにする。
LIKE あいまい検索 パターンマッチング
ついでながら、部分一致で検索したい場合の抽出条件の書き方についても、解説しておく。
パターンマッチングで、あいまい検索をしたい場合は、「LIKE」を使えばよい。
LIKE '*A*'
とすればa列の値の中にAが含まれているレコードが抽出される。
*の部分は、なんでもOKな、いわゆるワイルドカードである。
SQL標準では、%が相当するメタ文字になるが、Accessでは、*を使った方がよい。
というか、%が使える状況が限定的。
メタ文字の?を使用することで、1文字のワイルドカードになる。
さらには、[A-F] のようにすれば、Aから順にFまでの 「A B C D E F」のいずれか1文字といったワイルドカードにできる。
SELECT foo.a, foo.b FROM foo WHERE (((foo.a) Like '*A*')));
SQLでのLIKEは、正規表現とは異なったパターン指定となる。Accessにおいては正規表現的な要素があるが、微妙に異なる。また、SQLiteのREGEXPのような正規表現でのパターン検索用の演算子は存在しない。
正規表現自体は、「Microsoft VBScript Regular Expression 5.5」を参照設定すれば、RegExpオブジェクトが利用可能になる。RegExpオブジェクトを使って正規表現を処理するような、自前のVBA関数を作ってやれば、クエリから正規表現によるマッチング検索をできなくもない。
ここまでのまとめ
LIKE
パターンマッチングによるあいまい検索。
今回はここまで。
詳しくは、SQLポケリのIN演算子、LIKE演算子のところを参照して欲しいのだ。
Access クエリ 徹底活用ガイド ~仕事の現場で即使える
- 作者: 朝井 淳
- 出版社/メーカー: 技術評論社
- 発売日: 2018/05/25
- メディア: 大型本
関連記事
データベースにおける正規表現【REGEXP】
AccessクエリとSQLの関係 デザインビューとSQLビュー
AccessクエリとSQLの関係 フィールド
AccessクエリとSQLの関係 フィールドに式を書く
AccessクエリとSQLの関係 並び替え
AccessクエリとSQLの関係 抽出条件
AccessクエリとSQLの関係 抽出条件(または)
AccessクエリとSQLの関係 抽出条件(INとLIKE)
AccessクエリとSQLの関係 抽出条件(表示のチェックボックス)
データベースにおける正規表現【REGEXP】
AccessクエリとSQLの関係 デザインビューとSQLビュー
AccessクエリとSQLの関係 フィールド
AccessクエリとSQLの関係 フィールドに式を書く
AccessクエリとSQLの関係 並び替え
AccessクエリとSQLの関係 抽出条件
AccessクエリとSQLの関係 抽出条件(または)
AccessクエリとSQLの関係 抽出条件(INとLIKE)
AccessクエリとSQLの関係 抽出条件(表示のチェックボックス)
サイト内を検索
AccessクエリとSQLの関係 抽出条件(または) [Accessクエリ]
さて、Accessクエリの続きである。
今回は、前回に続いて、抽出条件である。
抽出条件のひとつ下に、「または」っていうのがある。以下、見出しに何も書かれていない入力欄が存在するが、こいつらの効果を調べるのである。
抽出条件または
さて、抽出条件の入力欄には、抽出条件の式を書くことができた。そのひとつ下にある「または」の部分にも抽出条件を書き込むことができる。
どちらかの抽出条件に合致するレコードが抽出されることになる。
以下のように、2と3を入力すると
b列が2であるレコード「または」b列が3であるレコードが抽出される。
簡単にいえば、条件式を複数書くことができるわけです。
で、それらの条件式のうちどれかに合致すれば抽出対象となるわけです。
SQLとの対比 OR
では、これをSQLビューで表示させてみよう。
これまた、括弧が多いので、取り除いてみると
WHERE foo.b = 2 OR foo.b = 3
となる。
foo.b = 2 が「b列が2であるレコード」という条件。
foo.b = 3 が「b列が3であるレコード」という条件。
これらのふたつの条件式が、OR(オア)でつながれている。
このORは、左右の条件式のうち、どちらか一方の条件が成り立っていれば、全体として真を戻す演算子。両方の条件が成り立っている場合でも真になる。唯一、偽となるのは、両方の条件が成り立っていない場合のみとなる。
ORは英語であるが、日本語に訳すと「または」である。
ここまでのまとめ
OR
「または」に入力すると、ORで連結された条件式となる。
抽出条件にORを書く
またはの入力欄に条件式を書いたが、これをOrを使って、抽出条件のところにまとめて書いてもよい。
実行結果やSQLは「または」に3を書いた場合と同じになるので、省略。
この方法なら、Or以外の論理演算子で条件を連結することも可能になる。
論理演算子には、以下のものが存在する(代表的なもののみ)。
論理演算子
OR または
AND かつ
IN いずれか
ORについては、これまで見てきた通りであるが、AND(アンド)については少々説明が必要かも。
ANDもORと同様に、ふたつの条件式を連結するものである。ORが片方の条件式が成り立っていればよかったのに対して、ANDでは、両方の条件式が成り立っていなければ、全体で真にならない。
なので、「2 Or 3」をそのまま「2 And 3」としてもうまくいかないであろう。
どうしてかといえば、b列の値が2であり、かつ、同時にb列の値が3であるレコードなんて存在しないからである。
しかしながら、文法としては正しいので、Accessは律儀にそういったレコードを検索する。探しても存在しないはずなんだけどね。
ではANDの意味がないじゃない、と思われるかも知れない。
まぁ、ひとつの列の抽出条件に等価である条件同士でAND書いても「意味ない」です。
複数の列に抽出条件を書く
a列のところにも抽出条件を書いてみよう。
これで、SQLビューにしてみると
ほほう。「a列が"二"」という条件と「b列が2」という条件のふたつがANDで連結されている。
これなら意味がある。どちらの条件も満たしているレコードが抽出されるのである。
ここまでのまとめ
AND
デザインビューの各列に抽出条件を書くと、ANDで連結された条件式となる。
範囲指定の抽出条件
ひとつの列で抽出条件にANDを書いてもあまり意味がない、といったが、範囲指定で条件を書くときにはAndを使って書くことが多い。ANDを使って意味がないのは等しいかどうかの条件式を連結する場合である。
例えば、b列の値が、1~3の範囲にある、といった条件式なら以下のように書くことができる。
>=1 And <=3
または
Between 1 And 3
今回はここまで。
詳しくは、SQLポケリのWHERE句や論理演算子のところを参照して欲しいのだ。
サイト内を検索
今回は、前回に続いて、抽出条件である。
抽出条件のひとつ下に、「または」っていうのがある。以下、見出しに何も書かれていない入力欄が存在するが、こいつらの効果を調べるのである。
抽出条件または
さて、抽出条件の入力欄には、抽出条件の式を書くことができた。そのひとつ下にある「または」の部分にも抽出条件を書き込むことができる。
どちらかの抽出条件に合致するレコードが抽出されることになる。
以下のように、2と3を入力すると
b列が2であるレコード「または」b列が3であるレコードが抽出される。
簡単にいえば、条件式を複数書くことができるわけです。
で、それらの条件式のうちどれかに合致すれば抽出対象となるわけです。
SQLとの対比 OR
では、これをSQLビューで表示させてみよう。
これまた、括弧が多いので、取り除いてみると
WHERE foo.b = 2 OR foo.b = 3
となる。
foo.b = 2 が「b列が2であるレコード」という条件。
foo.b = 3 が「b列が3であるレコード」という条件。
これらのふたつの条件式が、OR(オア)でつながれている。
このORは、左右の条件式のうち、どちらか一方の条件が成り立っていれば、全体として真を戻す演算子。両方の条件が成り立っている場合でも真になる。唯一、偽となるのは、両方の条件が成り立っていない場合のみとなる。
ORは英語であるが、日本語に訳すと「または」である。
ここまでのまとめ
OR
「または」に入力すると、ORで連結された条件式となる。
抽出条件にORを書く
またはの入力欄に条件式を書いたが、これをOrを使って、抽出条件のところにまとめて書いてもよい。
実行結果やSQLは「または」に3を書いた場合と同じになるので、省略。
この方法なら、Or以外の論理演算子で条件を連結することも可能になる。
論理演算子には、以下のものが存在する(代表的なもののみ)。
論理演算子
OR または
AND かつ
IN いずれか
ORについては、これまで見てきた通りであるが、AND(アンド)については少々説明が必要かも。
ANDもORと同様に、ふたつの条件式を連結するものである。ORが片方の条件式が成り立っていればよかったのに対して、ANDでは、両方の条件式が成り立っていなければ、全体で真にならない。
なので、「2 Or 3」をそのまま「2 And 3」としてもうまくいかないであろう。
どうしてかといえば、b列の値が2であり、かつ、同時にb列の値が3であるレコードなんて存在しないからである。
しかしながら、文法としては正しいので、Accessは律儀にそういったレコードを検索する。探しても存在しないはずなんだけどね。
ではANDの意味がないじゃない、と思われるかも知れない。
まぁ、ひとつの列の抽出条件に等価である条件同士でAND書いても「意味ない」です。
複数の列に抽出条件を書く
a列のところにも抽出条件を書いてみよう。
これで、SQLビューにしてみると
ほほう。「a列が"二"」という条件と「b列が2」という条件のふたつがANDで連結されている。
これなら意味がある。どちらの条件も満たしているレコードが抽出されるのである。
ここまでのまとめ
AND
デザインビューの各列に抽出条件を書くと、ANDで連結された条件式となる。
範囲指定の抽出条件
ひとつの列で抽出条件にANDを書いてもあまり意味がない、といったが、範囲指定で条件を書くときにはAndを使って書くことが多い。ANDを使って意味がないのは等しいかどうかの条件式を連結する場合である。
例えば、b列の値が、1~3の範囲にある、といった条件式なら以下のように書くことができる。
>=1 And <=3
または
Between 1 And 3
今回はここまで。
詳しくは、SQLポケリのWHERE句や論理演算子のところを参照して欲しいのだ。
関連記事
AccessクエリとSQLの関係 デザインビューとSQLビュー
AccessクエリとSQLの関係 フィールド
AccessクエリとSQLの関係 フィールドに式を書く
AccessクエリとSQLの関係 並び替え
AccessクエリとSQLの関係 抽出条件
AccessクエリとSQLの関係 抽出条件(または)
AccessクエリとSQLの関係 抽出条件(INとLIKE)
AccessクエリとSQLの関係 抽出条件(表示のチェックボックス)
AccessクエリとSQLの関係 デザインビューとSQLビュー
AccessクエリとSQLの関係 フィールド
AccessクエリとSQLの関係 フィールドに式を書く
AccessクエリとSQLの関係 並び替え
AccessクエリとSQLの関係 抽出条件
AccessクエリとSQLの関係 抽出条件(または)
AccessクエリとSQLの関係 抽出条件(INとLIKE)
AccessクエリとSQLの関係 抽出条件(表示のチェックボックス)
Access クエリ 徹底活用ガイド ~仕事の現場で即使える
- 作者: 朝井 淳
- 出版社/メーカー: 技術評論社
- 発売日: 2018/05/25
- メディア: 大型本
サイト内を検索
AccessクエリとSQLの関係 抽出条件 [Accessクエリ]
さて、Accessクエリの続きである。
前回は、並び替えをやった、今回は、ひとつ飛ばして、抽出条件をやってみる。
多分、クエリで一番お世話になる機能である。
抽出条件
さて、抽出条件の入力欄では、ドロップダウンは表示されない。これは、なんでも入力できることを意味する。抽出条件という言葉の意味通り、抽出するための条件を書き込む欄になる。
まずは、簡単な抽出からやってみることにする。
単純一致
抽出という処理は、レコードを抽出する作業になる。抽出条件は、抽出したいレコードの条件。
抽出条件に単に値を入力すると、その値と一致するレコードが抽出される。
難しくはない。
fooテーブルの全レコードが以下のように存在していたとする。
b列の抽出条件に2を書き込んでクエリを実行すると
b列が2であるレコードだけが抽出された。
2を1に変更すれば、1であるレコードが抽出されるはず。
SQLとの対比 WHERE
では、これをSQLビューで表示させてみよう。
やたら括弧が付いて読みにくいが、WHERE(ホエア)が追加になっていることがわかる。括弧を取り除いてみると、以下のようになっている。
WHERE foo.b = 2
SELECT命令のWHERE句では、レコードを抽出するための条件式を書くところなのである。テーブルfooのb列が2と一致するレコードだけを抽出してきなさい、という命令になっている。
「foo.b = 2」は、式である。foo.bがテーブルfooのb列であることを意味している。2はそのまま数値の2。=が演算子で「等しい」かどうかを計算してくれるもの。デザインビューの入力欄には=は入力していないが、計算方法を入力しなかった場合、デフォルトで=が演算子として採用される。
ここまでのまとめ
WHERE
抽出条件を指定するとSELECT命令に追加される
foo.b = 2
WHEREに続けて、レコードの抽出条件式を指定する
=
等しいかどうかを計算する演算子
比較演算
単純にb列の値が2と一致するレコードだけを抽出できた。演算子を指定することで、計算方法を変更することができる。比較演算子を使うことで、指定した値よりも大きいものだけ、といった抽出が可能になる。比較演算子には以下のものがある。
= 等しい
> 大きい
< 小さい
>= 以上
<= 以下
<> 等しくない
このブログは、HTMLで書いているので、記号を全角文字で書いている。実際のクエリには半角で演算子を書かないと演算子とはみなされないので注意!
b列が2以上であるレコードを抽出してみよう。
ちゃんとできました。
今回はここまで。
詳しくは、SQLポケリのWHERE句や比較演算子のところを参照して欲しいのだ。
サイト内を検索
前回は、並び替えをやった、今回は、ひとつ飛ばして、抽出条件をやってみる。
多分、クエリで一番お世話になる機能である。
抽出条件
さて、抽出条件の入力欄では、ドロップダウンは表示されない。これは、なんでも入力できることを意味する。抽出条件という言葉の意味通り、抽出するための条件を書き込む欄になる。
まずは、簡単な抽出からやってみることにする。
単純一致
抽出という処理は、レコードを抽出する作業になる。抽出条件は、抽出したいレコードの条件。
抽出条件に単に値を入力すると、その値と一致するレコードが抽出される。
難しくはない。
fooテーブルの全レコードが以下のように存在していたとする。
b列の抽出条件に2を書き込んでクエリを実行すると
b列が2であるレコードだけが抽出された。
2を1に変更すれば、1であるレコードが抽出されるはず。
SQLとの対比 WHERE
では、これをSQLビューで表示させてみよう。
やたら括弧が付いて読みにくいが、WHERE(ホエア)が追加になっていることがわかる。括弧を取り除いてみると、以下のようになっている。
WHERE foo.b = 2
SELECT命令のWHERE句では、レコードを抽出するための条件式を書くところなのである。テーブルfooのb列が2と一致するレコードだけを抽出してきなさい、という命令になっている。
「foo.b = 2」は、式である。foo.bがテーブルfooのb列であることを意味している。2はそのまま数値の2。=が演算子で「等しい」かどうかを計算してくれるもの。デザインビューの入力欄には=は入力していないが、計算方法を入力しなかった場合、デフォルトで=が演算子として採用される。
ここまでのまとめ
WHERE
抽出条件を指定するとSELECT命令に追加される
foo.b = 2
WHEREに続けて、レコードの抽出条件式を指定する
=
等しいかどうかを計算する演算子
比較演算
単純にb列の値が2と一致するレコードだけを抽出できた。演算子を指定することで、計算方法を変更することができる。比較演算子を使うことで、指定した値よりも大きいものだけ、といった抽出が可能になる。比較演算子には以下のものがある。
= 等しい
> 大きい
< 小さい
>= 以上
<= 以下
<> 等しくない
このブログは、HTMLで書いているので、記号を全角文字で書いている。実際のクエリには半角で演算子を書かないと演算子とはみなされないので注意!
b列が2以上であるレコードを抽出してみよう。
ちゃんとできました。
今回はここまで。
詳しくは、SQLポケリのWHERE句や比較演算子のところを参照して欲しいのだ。
関連記事
AccessクエリとSQLの関係 デザインビューとSQLビュー
AccessクエリとSQLの関係 フィールド
AccessクエリとSQLの関係 フィールドに式を書く
AccessクエリとSQLの関係 並び替え
AccessクエリとSQLの関係 抽出条件
AccessクエリとSQLの関係 抽出条件(または)
AccessクエリとSQLの関係 抽出条件(INとLIKE)
AccessクエリとSQLの関係 抽出条件(表示のチェックボックス)
AccessクエリとSQLの関係 デザインビューとSQLビュー
AccessクエリとSQLの関係 フィールド
AccessクエリとSQLの関係 フィールドに式を書く
AccessクエリとSQLの関係 並び替え
AccessクエリとSQLの関係 抽出条件
AccessクエリとSQLの関係 抽出条件(または)
AccessクエリとSQLの関係 抽出条件(INとLIKE)
AccessクエリとSQLの関係 抽出条件(表示のチェックボックス)
Access クエリ 徹底活用ガイド ~仕事の現場で即使える
- 作者: 朝井 淳
- 出版社/メーカー: 技術評論社
- 発売日: 2018/05/25
- メディア: 大型本
サイト内を検索
AccessクエリとSQLの関係 並び替え [Accessクエリ]
さて、Accessクエリの続きである。
本日は、フィールドの下にある、並べ替えについてやってみる。フィールドのすぐ下にはテーブルの入力欄もあるが、元となるテーブルが複数になってこないと意味がないので、後回しとする。
さて、並び替えをやるとどうなるのか、何が並び替えられるのかやってみることにする。
並び替え
さて、並べ替えのところをドロップダウンさせてみると、「昇順」「降順」「(並べ替えなし)」と3つの選択肢が存在することがわかる。
並べ替えなしがデフォルトの状態。何も指定していない状態であるので、並び替えは行われない。
テーブルfooの作成方法が良くなかった。a列で並び替えするとわかりにくいので、b列で並び替えをしてみよう。
フィールドを式にしてしまったので、これを単純にb列だけにする。さらに、並び替えで、昇順を指定してみた。
これで、「実行」してデータシートビューに切り替えると、b列が小さいものから大きいものへ順番に並び替えられて表示される。
Excelでいうと、B列を選択して、「並べ替えとフィルター」の「昇順」を実行した感じとなる。
降順で並び替え
元々1,2,3の順番でレコードを作成したので、並び替えなくても結果は同じであったので面白くない。「降順」に変更して、並び替えの様子を見てみよう。
確かに、並び替えられている。
並び替えられるのは、「レコード単位」である。b列に並び替えの条件を指定したが、b列のみが並び替えられるわけではない。従って、a列とb列の対応が崩れることはない。Excelの並び替えでも、同じように行単位で並び替えされるので違和感はないと思う。
SQLとの対比 ORDER BY
SQLビューに切り替えてみよう。
ORDER BY ...といった命令文が追加されている。読み方は、「オーダーバイ」である。ORDER BY句により並び替えを指定することができる。
ORDER BYに続けて、どの列をキーとして並び替えるのかが指定されている。例では、b列で並び替えしているので、ORDER BY foo.bと書かれている。
さらに、降順を指定しているので、DESC(デスク)が付いている。昇順に変更すると、DESCがなくなる。
最後の;(セミコロン)は、SELECT命令文の終わりを意味するもの。
まとめ
ORDER BY
並び替えを指定するとSELECT命令に追加される
foo.b
ORDER BYに続けて、並び替えを行いたい列を指定する
DESC
降順で並び替えを行う指定。昇順で並び替える場合はブランクまたは、ASCを指定できる。
今回はここまで。
詳しくは、SQLポケリを参照して欲しいのだ。
サイト内を検索
本日は、フィールドの下にある、並べ替えについてやってみる。フィールドのすぐ下にはテーブルの入力欄もあるが、元となるテーブルが複数になってこないと意味がないので、後回しとする。
さて、並び替えをやるとどうなるのか、何が並び替えられるのかやってみることにする。
並び替え
さて、並べ替えのところをドロップダウンさせてみると、「昇順」「降順」「(並べ替えなし)」と3つの選択肢が存在することがわかる。
並べ替えなしがデフォルトの状態。何も指定していない状態であるので、並び替えは行われない。
テーブルfooの作成方法が良くなかった。a列で並び替えするとわかりにくいので、b列で並び替えをしてみよう。
フィールドを式にしてしまったので、これを単純にb列だけにする。さらに、並び替えで、昇順を指定してみた。
これで、「実行」してデータシートビューに切り替えると、b列が小さいものから大きいものへ順番に並び替えられて表示される。
Excelでいうと、B列を選択して、「並べ替えとフィルター」の「昇順」を実行した感じとなる。
降順で並び替え
元々1,2,3の順番でレコードを作成したので、並び替えなくても結果は同じであったので面白くない。「降順」に変更して、並び替えの様子を見てみよう。
確かに、並び替えられている。
並び替えられるのは、「レコード単位」である。b列に並び替えの条件を指定したが、b列のみが並び替えられるわけではない。従って、a列とb列の対応が崩れることはない。Excelの並び替えでも、同じように行単位で並び替えされるので違和感はないと思う。
SQLとの対比 ORDER BY
SQLビューに切り替えてみよう。
ORDER BY ...といった命令文が追加されている。読み方は、「オーダーバイ」である。ORDER BY句により並び替えを指定することができる。
ORDER BYに続けて、どの列をキーとして並び替えるのかが指定されている。例では、b列で並び替えしているので、ORDER BY foo.bと書かれている。
さらに、降順を指定しているので、DESC(デスク)が付いている。昇順に変更すると、DESCがなくなる。
最後の;(セミコロン)は、SELECT命令文の終わりを意味するもの。
まとめ
ORDER BY
並び替えを指定するとSELECT命令に追加される
foo.b
ORDER BYに続けて、並び替えを行いたい列を指定する
DESC
降順で並び替えを行う指定。昇順で並び替える場合はブランクまたは、ASCを指定できる。
今回はここまで。
詳しくは、SQLポケリを参照して欲しいのだ。
関連記事
AccessクエリとSQLの関係 デザインビューとSQLビュー
AccessクエリとSQLの関係 フィールド
AccessクエリとSQLの関係 フィールドに式を書く
AccessクエリとSQLの関係 並び替え
AccessクエリとSQLの関係 抽出条件
AccessクエリとSQLの関係 抽出条件(または)
AccessクエリとSQLの関係 抽出条件(INとLIKE)
AccessクエリとSQLの関係 抽出条件(表示のチェックボックス)
AccessクエリとSQLの関係 デザインビューとSQLビュー
AccessクエリとSQLの関係 フィールド
AccessクエリとSQLの関係 フィールドに式を書く
AccessクエリとSQLの関係 並び替え
AccessクエリとSQLの関係 抽出条件
AccessクエリとSQLの関係 抽出条件(または)
AccessクエリとSQLの関係 抽出条件(INとLIKE)
AccessクエリとSQLの関係 抽出条件(表示のチェックボックス)
Access クエリ 徹底活用ガイド ~仕事の現場で即使える
- 作者: 朝井 淳
- 出版社/メーカー: 技術評論社
- 発売日: 2018/05/25
- メディア: 大型本
サイト内を検索
AccessクエリとSQLの関係 フィールドに式を書く [Accessクエリ]
さて、Accessクエリの続きである。
前回は、抽出条件のところで、フィールドを指定をしてみた。
SELECT命令のSELECT句に列名をカンマで区切ってかけば抽出するフィールドを指定することができた。
今回は、フィールドに式を入れてみたいと思う。
フィールドに式を書く
フィールドには列名だけでなく、列名を加工するような式を書くことができる。よくやるのは、単価*個数で金額を計算する、なんていうことです。
やることは単純。フィールドのところに、計算式を書き込めばよい。
b列の倍を計算するように、2列目を変更してみた。
フィールドの入力フォーカスを矢印キーで移動して外すと、自動的に表示方法が変更される。
式1: [b]*2
となった。
なんで勝手にかわっちゃうのよ、と思うのだが、これにはいろいろ事情がある。
式1:の正体
式1:は、Accessがそのフィールドに勝手に付けた名前である。列を指定した場合は、それが名前であるため、Accessはフィールド名として列名をそのまま使用する。計算式にすると、名前とはいいがたくなる。現に記号である「*」を使用しているので、名前としては認められない。
SQLでは、*などの記号は名前に使用できない。
SQLビュー、データシートビューに切り替えてみてみると以下のような対応となっていることがわかる。
式1は、計算式「[b] * 2」に付けられた名前である。
SQLでは、SELECT句の各列に対して、ASキーワードで別名を指定できる。別名なんです。Accessのデザインビューでは、「別名:計算式」といった書式となる。
なので、列名だけのフィールドに対しても別名を付けることが可能。
別名:a
とかしてみたらわかります。
[ ] の正体
記号は使ってはいけないのか、では[と]は?使っても良いのか?
はい、[ と ] は名前のうちに入らない。列名はあくまでbだけで、bが列名であることを正確に表記したいがために、[と]で囲んでやる。
文字列を表現するのに、"で囲む、っていうことをやるでしょ?C言語とかで。SQLでも文字列は'で囲んでやる。囲まれた中のデータが実際のデータで、囲んでいる記号はデータには含まれない。
詳しくは、SQLポケリを参照して欲しいのだ。
サイト内を検索
前回は、抽出条件のところで、フィールドを指定をしてみた。
SELECT命令のSELECT句に列名をカンマで区切ってかけば抽出するフィールドを指定することができた。
今回は、フィールドに式を入れてみたいと思う。
フィールドに式を書く
フィールドには列名だけでなく、列名を加工するような式を書くことができる。よくやるのは、単価*個数で金額を計算する、なんていうことです。
やることは単純。フィールドのところに、計算式を書き込めばよい。
b列の倍を計算するように、2列目を変更してみた。
フィールドの入力フォーカスを矢印キーで移動して外すと、自動的に表示方法が変更される。
式1: [b]*2
となった。
なんで勝手にかわっちゃうのよ、と思うのだが、これにはいろいろ事情がある。
式1:の正体
式1:は、Accessがそのフィールドに勝手に付けた名前である。列を指定した場合は、それが名前であるため、Accessはフィールド名として列名をそのまま使用する。計算式にすると、名前とはいいがたくなる。現に記号である「*」を使用しているので、名前としては認められない。
SQLでは、*などの記号は名前に使用できない。
SQLビュー、データシートビューに切り替えてみてみると以下のような対応となっていることがわかる。
式1は、計算式「[b] * 2」に付けられた名前である。
SQLでは、SELECT句の各列に対して、ASキーワードで別名を指定できる。別名なんです。Accessのデザインビューでは、「別名:計算式」といった書式となる。
なので、列名だけのフィールドに対しても別名を付けることが可能。
別名:a
とかしてみたらわかります。
[ ] の正体
記号は使ってはいけないのか、では[と]は?使っても良いのか?
はい、[ と ] は名前のうちに入らない。列名はあくまでbだけで、bが列名であることを正確に表記したいがために、[と]で囲んでやる。
文字列を表現するのに、"で囲む、っていうことをやるでしょ?C言語とかで。SQLでも文字列は'で囲んでやる。囲まれた中のデータが実際のデータで、囲んでいる記号はデータには含まれない。
詳しくは、SQLポケリを参照して欲しいのだ。
関連記事
AccessクエリとSQLの関係 デザインビューとSQLビュー
AccessクエリとSQLの関係 フィールド
AccessクエリとSQLの関係 フィールドに式を書く
AccessクエリとSQLの関係 並び替え
AccessクエリとSQLの関係 抽出条件
AccessクエリとSQLの関係 抽出条件(または)
AccessクエリとSQLの関係 抽出条件(INとLIKE)
AccessクエリとSQLの関係 抽出条件(表示のチェックボックス)
AccessクエリとSQLの関係 デザインビューとSQLビュー
AccessクエリとSQLの関係 フィールド
AccessクエリとSQLの関係 フィールドに式を書く
AccessクエリとSQLの関係 並び替え
AccessクエリとSQLの関係 抽出条件
AccessクエリとSQLの関係 抽出条件(または)
AccessクエリとSQLの関係 抽出条件(INとLIKE)
AccessクエリとSQLの関係 抽出条件(表示のチェックボックス)
Access クエリ 徹底活用ガイド ~仕事の現場で即使える
- 作者: 朝井 淳
- 出版社/メーカー: 技術評論社
- 発売日: 2018/05/25
- メディア: 大型本
サイト内を検索
Copyright Atsushi Asai Google+朝井淳
[データベースの気持ちがわかる]SQLはじめの一歩 (WEB+DB PRESS plus)
- 作者: 朝井 淳
- 出版社/メーカー: 技術評論社
- 発売日: 2015/03/03
- メディア: 単行本(ソフトカバー)
Access クエリ 徹底活用ガイド ~仕事の現場で即使える
- 作者: 朝井 淳
- 出版社/メーカー: 技術評論社
- 発売日: 2018/05/25
- メディア: 大型本