すべてのブログから「#SQL」タグの検索結果

総務省から先月、発表された「ふるさと納税に関する現況調査結果」（令和7年度）自治体ごとの納税受入額や、住民税控除額が公表されている。組み合わせて都道府県別の収支表作りなど、何かの役に立つかもしれない。総務省の公開資料をもとにAccessでテーブルを作成してみたが、現在の構成だと、フィールド名を統一できていない。自治体テーブル：県・府・都 表記なし受入額テーブル：県・府・都 表記あり控除額テーブル：県・府・都 表記ありとなっていて、このままではデータをリレーション(結合)できない。そこで、Replace関数を用いて「ちび」を消去したときと同じ要領で、受入額および控除額テーブル上の各自治体名から「県」「府」「都」を省き自治体マスタに表示を合わせることを思いついた。【ふるさと納税受入額テーブルの自治体名を変換】SELECT     Replace(Replace(Replace([都道府県], "県", ""), "府", ""), "都", "") 　 AS 都道府県変換,    *FROM     受入額;【住民税控除額テーブルの自治体名を変換】SELECT     Replace(Replace(Replace([都道府県], "県", ""), "府", ""), "都", "")     AS 都道府県変換,    *FROM     控除額;ところが...京都府のフィールド名が申し訳ないことになってしまいました。「県」「府」「都」を空白化する命令を加えたことで、京都府のフィールドには「京」しか残らない結果を招いたのだ。「県」「府」は一律、空白化してよいが「都」は残しておく

テーブル上の特定レコードの全フィールドを表示させる案SELECT テーブル名.*FROM テーブル名WHERE テーブル名.[フィールド名]=抽出条件;☆学習メモ7-1で用いた、データベースの中身を全確認したいときの標準的なデータ取得SQLSELECT テーブル名.*FROM テーブル名;☆学習メモ7-3で用いた、選択済みフィールド情報(列)の中から特定のレコード(行)抽出SQLWHERE テーブル名.[フィールド名]=抽出条件;ふたつの☆の合わせ技で、タイトルに「メカ」とついたレコードを表示させようとした。クエリデザイン画面を使う場合の操作手順：選択クエリ画面にテーブルを置き、*（アスタリスク）をダブルクリックする。あるいは*（アスタリスク）をフィールドグリッドにドラッグする。　↓テーブル内「タイトル」フィールドをダブルクリックする。あるいはテーブル内「タイトル」フィールドをフィールドグリッドにドラッグする。　↓「タイトル」フィールドグリッドの「抽出条件」に「メカ」と直打ち。（Accessは賢いので、文字列と判断し"メカ"と変換してくれる。）　↓データシートビューでクエリ実行結果を確認する。※「！(実行)」ボタンは不要。・・・　↓1件もヒットしない。そんなバカな( ´ﾟдﾟ｀)Accessが自動形成してくれたSQLで、ヒントを見つけていこう。　↓SELECT M_配信リスト.*, M_配信リスト.[タイトル]FROM M_配信リストWHERE (((M_配信リスト.[タイトル])="メカ"));読みにくいのでWHERE句の((()))を消去。※効果は変わらない。　↓SELEC

今般の熊本地震による影響を受けた方々に謹んでお見舞い申し上げると共に心が少しでも救われる場面が一刻も早く訪れることを願っています。今この瞬間にも、救護を必要とされているかたが現地に大勢いるのではと思います。同じく酷暑の時期に被災した経験を持つ身としては、決して他人事ではありません。数週間に及ぶ上下水道の断水。当初は飲み水の確保に苦労しましたが、日数の経過と共に深刻化したのは生活用水の不足です。必要量が飲料とは比較になりません。汗ばむ季節の入浴制限はもとより、女性としては用を足せないことが何よりつらかった。自宅でも職場でも状況は同じ。そんな折、当時の首相が「プッシュ型支援」を内閣府へ要請。（思えば10年前の熊本地震が最初でした。）私たちの街に物資が届くのは早くても2～3日後と覚悟しました。報道翌日には自衛隊の災害派遣車両によって、地域の公園を中心に救援物資が次々と運び込まれ、感激したのを思い出します。水道の復旧は病院などの公共施設、公営住宅エリアが優先でした。自分たちの番が訪れる日が待ち遠しく、蛇口をひねると当たり前のように水が出てくるありがたみをあれほど実感した試しはありません。-∴-∵-∴-∵-∴-∵-∴-∵-∴-∵-∴-∵-∴-∵-∴-∵-∴-∵-∴-∵--∴-∵-∴-∵MicrosoftAccessを用いたデータベース作りの学習記録ですいや、今回の作品はデータベースと呼べるほどのレベルではない。ブログ投稿はココナラブログが人生初。そもそも下書きと公開設定の区別もついておらず、記事は下書きした順に掲載されるとばかり思っていた。投稿前の下書きの段階ではココナラブログの並びに不

以下でAccess内の全テーブル名を取得できます。SELECT MSysObjects.Type, MSysObjects.Name, MSysObjects.Flags FROM MSysObjects ORDER BY MSysObjects.Type, MSysObjects.Name;DAOは使いたくないのでよかった～。これでAccess内の全レコードを検索できます。日々是勉強です。

「ふるさと納税」ゆかりのある自治体、応援したい自治体、お気に入りの特産品を扱う自治体に対し寄附をおこなうことで、納税者が在籍する都道府県や市町村の枠を超え、寄附先の自治体に住民税が振り替えられる形となる制度。Accessで作成したテーブル「受入額」に「自治体が受ける寄附金」を示した。自治体にとっての収益である。一方、テーブル「控除額」には、「本来なら自治体が受け取るはずの住民税の内、他自治体への寄附により失った住民税」を示した。自治体にとっての損失である。ふるさと納税制度による受入額から控除額を差し引くことによって「自治体はお金が増えた（流入超過）のか、減った（流出超過）のか」税収への影響を可視化できる。Accessで計算をおこなうために必要とされた準備①「都道府県」フィールドの条件統一（学習メモ7-19）もともと用意したマスタテーブル「自治体リスト」の都道府県名は都道府県の表記抜きである。一方、「受入額」＆「控除額」の各トランザクションテーブルに用意された都道府県名は、都道府県の表記まで綴られたものだった。②「自治体ID」フィールドの条件統一（学習メモ7-20）マスタテーブル「自治体リスト」で管理番号として使用されている都道府県別の「自治体ID」は「受入額」＆「控除額」の各トランザクションテーブルにはもともと表示されていなかった。Accessで各都道府県別に「ふるさと納税受入額－住民税控除額」を集計するにあたり、①各テーブル間で「都道府県名」表記の差異があったり②３つのテーブルの橋渡し役となる「自治体ID」キーに空欄があったりデータの不整合があることで、テーブル同士のデータ受

クエリ（Query）：データベースに対する要求（命令）SQL：その要求を書くための言語学習メモ7-17で作られた３つのテーブル・マスタテーブル①「M_名簿」・UPDATE文（更新命令句）による「M_名簿」加工テーブル　②「M_名簿_ただの怪獣」　③「M_名簿_大怪獣」これら①～③をひとつのテーブルとして集約したいときの、主な方法【1】アクションクエリ系空っぽのテーブルを作り、3つのテーブルがもつレコードをすべて追加する。※ポイントWHERE 1=0 という絶対に満たされない条件を敢えて付けることで中身のないテーブル構造だけをコピーしている。↓新規テーブル「T_統合名簿」作成SQLSELECT *INTO T_統合名簿FROM M_名簿WHERE 1=0;オブジェクト一覧の見た目はこんな感じクエリ「実行」キーを押下すると中身のないテーブル「T_統合名簿」が新設される。①②③3つのテーブルのデータを新規テーブル「T_統合名簿」へ↑↑↑～レコードを順に追加するSQL～①M_名簿 INSERT INTO T_統合名簿SELECT * FROM M_名簿;②M_名簿_ただの怪獣INSERT INTO T_統合名簿SELECT * FROM M_名簿_ただの怪獣;③M_名簿_大怪獣INSERT INTO T_統合名簿SELECT * FROM M_名簿_大怪獣;それぞれ見た目はこんな感じ（通常の選択クエリと異なる）【2】選択(通常)クエリ系ユニオンクエリ（UNION / UNION ALL）同一フィールド(列の項目)をもつ複数のテーブルを一時的にくっつけて（UNION / UNION AL

”○○から○○まで”をフィールド(列)に条件として指定しテーブルのデータの中から、条件に合致したレコード(行)を抽出する期間の○○～○○：Between #yyyy/mm/dd# And #yyyy/mm/dd#Between #dd/mm/yyyyy# And #dd/mm/yyyy#クエリデザイン画面から設計する場合は日付は##で囲まなくても、Accessが自動で認識して##を付けてくれるがその場合、月日は0埋め(月日とも2桁表示に)しておかないとエラーになる。「特定日(例：今年の元日)から今日まで」を指定する際にはBetween #1/1/2026# And Date() と記入すればOK。文字列の○○～○○：日付を指定する際に用いるBetween演算子は使えない。Like演算子とワイルドカード(*)を使う。Like "[あ-お]*"※ワイルドカード(*)：その後に続く任意の文字列⇒「あ～お」を頭文字とした名称の候補をすべて連れてきてくれる。抽出文字列にひらがなとカタカナが混在する場合Like "[あ-おア-オ]*"[あ-お] ： あ、い、う、え、お のいずれかの1文字[ア-オ] ： ア、イ、ウ、エ、オ のいずれかの1文字【注】漢字の読み仮名はLike "[あ-おア-オ]*"対象外。漢字を抽出対象としたい場合はテーブル制作時に抽出条件用の読み仮名フィールドを設けておく。【注】濁音や半濁音は、五十音順の次音を抽出上限に指定すると含まれるようだ。タイトル「バズろう心霊動画」は「ア～ハ」と指定したときは拾うことができず「ア～ヒ」と指定すると出てきてくれた。【完成形】SELEC

結合したテーブルから特定のフィールドを選び特定のフィールドが持つ値の順に並べ替え、特定のレコードだけを表示する。これまで作成したテーブル①M_名簿②M_登場人物③M_配信リスト④T_視聴各テーブルの共通フィールド(列の見出し)を内部結合(INNER JOIN)表示するフィールドを選択：[ゴジNo][キャラクター名][話数][タイトル][放送日][Seasoon][視聴数(万回)]指定したレコード(行)を抽出：[ゴジNo][キャラクター名]のレコード(行)を抽出し[話数][タイトル]の並べ替え：[視聴数(万回)]を降順表示抽出条件：今年度(Season4)は現時点で配信途中であるため、出力対象から除外。「条件：Season4未満」目的：キャラクター別に人気作品を調査します。SQLはこんな感じ：SELECTM_名簿.[ゴジNo], M_名簿.[キャラクター名], M_登場人物.[話数], M_配信リスト.[タイトル], M_配信リスト.[放送日], M_配信リスト.[Season], T_視聴.[視聴数(万回)]FROM ((M_名簿 INNER JOIN M_登場人物 ON M_名簿.[ゴジNo] = M_登場人物.[ゴジNo]) INNER JOINM_配信リスト ON M_登場人物.[話数] = M_配信リスト.[話数]) INNER JOINT_視聴 ON M_配信リスト.[話数] = T_視聴.[話数]WHERE (((M_名簿.[ゴジNo])="CH001") AND ((M_配信リスト.Season)<4))ORDER BYT_視聴.[視聴数(万回)] DESC

テーブル上の全フィールドを表示させ特定のフィールド順に、レコードの並べ替えをおこないます。特定のフィールドとは、「視聴数(万回)」です。アニメの放送話ごとの再生数を記録したフィールドです。「視聴数(万回)」フィールドの場所：既存のマスタテーブルに追加する方法と新たにトランザクションテーブルを追加しマスタテーブルに内部結合させる方法がある。再生回数の集計結果は日々変化し得る情報でありトランザクションテーブルで管理を行うのが王道なので今回はトランザクションテーブルを新たに設け既存のマスタテーブルと結合(JOIN)させる方法を採用する。1.トランザクションテーブルの構成を決める名称：T_視聴目的：[視聴数(万回)]を記録したい↓[視聴数(万回)]フィールドを置くことは確定。[視聴数(万回)]の記録は複数行(レコード)必要か？↓動画の再生数なので、集計結果は刻々と変化し得る。毎日せっせと集計したいほどではないけど、ないよりはあった方がいいかな・・・↓集計日を記録するための「記録日」フィールドを設けておこう。今回のトランザクションテーブル(T_視聴)は時系列データの保管場所となり「記録日」を軸に進行するため、「記録日」フィールドを主役とする。【注】1レコード1記録日であれば、データ型が日付型であっても頓着することなく「記録日」フィールドを主キーに設定することは可能だが今回のように、複数レコード(放送話)にわたって同じ記録日の入力が想定される場合（他と重複する場合）主キーにはできない。主キーを設けたい場合は「記録ID」など一意の値が入るフィールドを別途、用意する。2.マスタテーブル(M_配

FROM句の対象テーブルからSELECT句で選び取ったフィールド(列)表示ここまでが既存の学習メモ内容今回は、選択済みフィールド情報の中から特定のレコード(行)のみ抽出だんだんややこしくなってきてる(ﾟдﾟlll)SELECTM_配信リスト.[話数],M_配信リスト.[タイトル], M_配信リスト.[放送日], M_配信リスト.[Season]FROMM_配信リストWHEREM_配信リスト.[フィールド名]=抽出条件;  　←【New】1. SQLの構造SELECT～FROM～に加え「WHERE句」が仲間入り。SELECT 句 SELECT M_配信リスト.[話数], M_配信リスト.[タイトル], M_配信リスト.[放送日], M_配信リスト.[Season]役割:どの列（フィールド）のデータを取得するかを指定詳細:テーブル名「M_配信リスト」の内、[話数][タイトル][放送日][Season]フィールドを表示。具体的なフィールド名をカンマ（,）で区切って「どのテーブルの、どの項目か」を正確に指定する。FROM 句 FROM M_配信リスト;役割:データの取得元となるテーブルを指定詳細:「M_配信リスト」テーブルからデータを取るように指定。これまでと違う点：テーブル名の後につける;（セミコロン）は、この後に続くWHERE句が引き継ぐため、今回は不要。WHERE 句WHEREM_配信リスト.Season = 3;役割:データの取得元となるテーブルから、必要なレコードのみ抽出。詳細:「M_配信リスト」テーブルの内、[Season]フィールドに「3」と入ったレコードのみ表示するよう

データベースの中身を全て確認したいときに用いられる、標準的なデータ取得SQLです。SELECT テーブル名.*FROM テーブル名;1. SQLの構造ここではふたつの「句」が登場している。SELECT 句 (SELECT M_配信リスト.*)役割:どの列（フィールド）のデータを取得するかを指定詳細:テーブル名「M_配信リスト」末尾の *（アスタリスク）は「すべての列」を意味し、「M_配信リスト」テーブルにあるすべての項目を取得できる。ただし、SQLの文法上、テーブル名やアスタリスクは独立した単語(トークン)として扱われ、それらを結びつける「ドット(演算子)」が必須とする取扱いが、リレーショナルデータベース業界の共通ルール。小さくて見つけにくいが、テーブル名と *（アスタリスク）の間には「.(ドット)」がちょこんと入る。この場合の「.(ドット)」は、「〜の」や「〜に属する」を意味する修飾子(クオリファイア)の働きをする。これを省略するとAccessはSQLの指示内容を読み取ることができず、「演算子エラー」となり、クエリ実行は中止される。FROM 句 (FROM M_配信リスト;)役割:データの取得元となるテーブルを指定詳細:「M_配信リスト」テーブルからデータを取るように指定。末尾の ;（セミコロン）は、SQL文の終わりを示す。2. 本SQLの役割「M_配信リスト」テーブルに格納されたすべてのレコード（行）と、すべての項目（列）を抽出して表示補足：「列」の呼び方についてAccessの設計画面やMicrosoft公式ヘルプなどでは、伝統的に「フィールド」という言葉が使われる。MyS

ココナラを訪れ、初めて取り組んだのが売上管理システム。【設問】売上日の入力後に売上番号(11桁の番号)を自動表示(編集不可)させなさい売上番号の付番ルール：日々の売上データを001から昇順3桁にて売上日 yyyymmdd に付加 例）売上日 2017年5月13日 当日1件目の売上 の場合 20170513001 売上日 2017年5月13日 当日3件目の売上 の場合 20170513003売上日 2017年5月15日 当日1件目の売上 の場合 20170515001 開発で忙しそうな出品者の手を煩わせたくなくて、生成AIに助けを求めるようになった。主に企業相手の商売だからか、Access関連サービスは価格設定が強気。比較的安価なサービスでも分厚めの参考書と同等のお値段°˖☆◝(⁰▿⁰)◜☆˖°ともあれ、生成AIが考案したコードはきちんと動くし、スッキリまとまっていて、何も問題なしと思われた。そんな中、ほかのココナラ出品者によって開発されたコードの品質が生成AIのコーディングとは異なることに気づいたので、記録しておきたいと考えた。※動画内コードは出品者から得た知識にて自分なりに練習を重ね実装した内容生成AIおよび人間による開発の違い実装結果を比較しながら、自分なりに検証してみた1. 実用向けか否か生成AI：Like演算子を使い、文字列としての売上番号から日付を逆算するため、入力された文字列が日付か否かに関係なく形成実行出品者：WHERE 売上日 = #日付# と、正規の日付項目で入力候補を絞り込み、日付型に該当しない入力をブロック2. 長期利用に耐えうるか生成AI：売上番号のデー

YouTubeでも紹介しています。是非ご覧ください。データベースは、VBAではなく、いかにデータを抽出するかです。 目に見えない、架空のクエリを想像できれば、さらに、データ抽出が楽になります。 目に見えないクエリを想像することで、抽出可能なデータ こんにちは。伊川です。 前回は、SQL文の基礎中の基礎を紹介しました。 また、前回紹介した書籍のChapter3で、LIMIT句というのが登場します。 結論から言いますと、ACCESSでは、LIMIT句は、利用できません。 なので、LIMIT句の代替のコードを利用します。 少し面倒な作業が増えます。 もちろん、このような複雑なことをしなくても、今回のサンプルでは、データ抽出ができます。 しかし、この面倒な作業を、覚えることで、複雑なデータ抽出ができるようになります。 VBAよりも、ずっと面白い内容です。 このブログはこんな人にお勧め ACCESSでクエリを勉強している人 クエリのスキルに限界を感じている人 SQLを勉強している人 このブログを、読み終わるころには・・・・ 初めて、競馬で、データ抽出で、壁に当たった内容でした。 デザインビューを見ても到底、その時の私には、理解できない内容でした。 しかし、目に見えないクエリが、どのように作動しているのかを、このブログで理解できるようになります。 上位2つのレコードを抽出したい この、テーブルから、上位2つのレコードを抽出します。 つまり、伊川直助、伊川直子を、抽出します。 このような状態にします。普通は、これで完了です。 もちろん、これでも正解ですが、架空のクエリを作成して、抽出をしま

YouTubeでも紹介しています。是非ご覧ください。どんなに、優れたデータベースを、作成しても、欲しいデータを抽出できなければ意味がありません。 この、データ抽出は、データベースを操作するに場合に、必須の知識となります。 クエリは、SQL文で記載すると面白くなる？ こんにちは。伊川です。 クエリを制するのみは、データベースを制する。 最近は、すっかりSQLに、ハマっています。 SQLの基本書には、必ず、MySQLを、パソコンにインストールして、開発環境を整えるところから始まります。 ただ、MySQLを、インストールしなくても、ACCESSを利用して、手軽に勉強できます。 今回紹介する書籍は、非常に変わりやすく記載されています。 私も、SQLを基礎から勉強しようと思い、購入しました。 この書籍の良いところは、サブクエリ、相関クエリ等、 ACCESSの基本書では、記載されていないことが、記載されています。 1つのテーブルから、クエリを複数作成してもいいですが、メンテナンスが大変です。 短いSQLを、サクサクっと記載して、万能なデータベースを作成しましょう。 このブログはこんな人にお勧めACCESSで、クエリを勉強している人 SQLの勉強をしている人 サブクエリ等、複雑なクエリを作成したい人 このブログを、読み終わるころには・・・・今回は、SQLの基礎中の基礎です。 しかし、この基礎に関しては、SQLの文法を学ぶに当たり非常に重要なことです。 この基礎を勉強して、複雑な抽出条件を記載できるようになりましょう。 ACCESSを利用して、SQLの勉強をするACCESSには、クエリを作成す

Acccessで扱えるSQLのひとつに、UPDATEがある。テーブルに保管中のデータ(レコード)を自在に上書きすることができるSQLで、「更新クエリ」とも呼ばれる。Accessは（私のように）プログラミングができないユーザーが手軽にSQLを扱えるように開発されたソフトウェアなのだろう。（OracleやSQLServerなどで用いられる標準SQL言語とは別物だろうけど）Access学習用として使われるSQLは平たく言うと作成済レコードを並べ替えたり組み合わせを楽しむ閲覧専用のSQL（安全）レコードそのものを書き換えることができるSQL（取扱い注意）と分類され、それぞれ趣旨が異なる。UPDATEは「アクションクエリ」と呼ばれる命令文の一種で、UPDATE（更新）INSERT（追加）DELETE（削除）CREATE TABLE（テーブル作成）など目的に応じて多彩な文法が用意されている。ちび怪獣たちが成長して大怪獣になったと想定し、名簿から「ちび」を外す。そんなときには「M_名簿」テーブル「キャラクター名」フィールドに対し「文字列中のちびを消す」指示を与えることで、全データを一括更新できる。UPDATE テーブル名SET フィールド名='○○○';UPDATE用SQLにReplace関数を組み合わせる。この場合のReplaceは、文字列の置き換えを意味する。Replace(元の文字列, 置換前, 置換後)という風に使う。ただしSQLが成功すればテーブルの情報は上書き変更されてしまうので、必要に応じ、あらかじめ元テーブルのバックアップをとっておく。アクションクエリはテーブル内の情報を直接

AND条件とOR条件のダブスタ今年度(2027年1月)に成人...じゃなくて成怪獣式を迎える可能性の低いキャラクターをリストアップSELECTM_名簿.[ゴジNo], M_名簿.[キャラクター名], M_名簿.[誕生日], M_名簿.[初登場日], M_名簿.[声優さん], M_名簿.[住所]FROMM_名簿WHEREM_名簿.[キャラクター名]="ちび" ORM_名簿.[キャラクター名] Not In("ちびヘドラ")ANDM_名簿.[キャラクター名] Not In("ちびビオランテ")ANDM_名簿.[誕生日]<#8/25/9999#;基準1：名称（マスタテーブル M_名簿[キャラクター名]を照合）【条件1】名前に「ちび」がついている【または】※OR条件【条件2】名前が「ちびヘドラ」ではない【かつ】※AND条件【条件3】名前が「ちびビオランテ」ではない背景：ヘドラもビオランテも「ちび」と名乗ってはいるものの、話中ではお酒が飲めるお年頃と判明【基準1 かつ 基準2】※AND条件基準2：生年月日（マスタテーブル M_名簿[誕生日]を照合）【条件4】本日(8月25日)より先に誕生日を迎えている背景：お誕生日を過ぎてもまだ条件１が当てはまるのは、ちび怪獣である目安【ポイント】・Accessクエリのデザイングリッドを用いたOR条件の記入位置：OR条件同士を同じ行に置いてはダメみたい。最初の条件を記入した行の下行に記入すれば大丈夫。・文法に注意：#9999/08/25#・・・・・日付は半角かつ##で囲む。Not In("〇〇〇")・・・Not In(○○以外)の指定値は()で囲む

現在115話分のデータ登録中のAccessデータベース内においてみっつの首をもつギドラさんを題材にWHERE句のOR条件を何フィールドまで組めるか実験してみた。CH003:ちびギドラ(真ん中の首)CH004:ちびギドラ(左の首)CH005:ちびギドラ(右の首)みっつの首にはそれぞれ別々の人格があるため、登録IDを別々にしているが(入力の手間が3倍・笑)彼らはバラバラには動けない。常に3人(？)揃って出演しているわけであり、つまり、ちびギドラが登場する回を知りたければ、CH003もしくはCH004もしくはCH005のいずれかがヒットする話数を探せばいいということになる。目的：全115話の内、CH003もしくはCH004もしくはCH005が出演する話数フィールドを探して抽出したい。AccessSQLの根本的な仕組みとして、テーブル内のデータを自動で読み込み表示フィールドを抽出する機能は存在しないためSQLの冒頭SELECT句には表示したい列、つまりギドラたちが出演する話数をあらかじめ手書きで指定する必要が生じる。SELECT[第2話],[第5話],[第7話],[第10話],[第12話],[第13話],[第14話],[第17話],[第18話],[第21話],[第22話],[第25話],[第30話],[第31話],[第33話],[第34話],[第38話],[第44話],[第45話],[第49話],[第50話],[第53話],[第55話],[第56話],[第58話],[第62話],[第64話],[第65話],[第66話],[第67話],[第68話],[第69話],[第73話],[第75話

MicrosoftAccessでは、テーブルに格納済みの情報を目的に応じ取り出す際「あれと、これと、その項目も見たい」という風に一度に抽出する条件の数を追加できる。「または」とする抽出条件を「OR条件」と呼ぶのに対し抽出条件を併用する今回のケースは「AND条件」と呼ばれるらしい。そのAND条件、MicrosoftAccessのSQLにおいて、いくつまでなら指定OKか？Accessを長年極めている先人たちの間ではカリスマ的存在らしいある有名な先生の記事によると「ANDの数は99、つまり追加できる抽出条件は100までかな」と想定されておられたので今回、そのお話を確かめるべく自作ファイル内に115個のフィールド入りテーブルを新設し実験してみました٩(σ-σ)وアニメ配信数が現時点で115話。実証実験の材料にはピッタリ。ただ、タテ並び(レコード)単位のデータをヨコ並び(フィールド)単位に置き換える作業が必要で、Accessの場合、すんなりとはいかない。Excelエクスポート＆インポート機能をフル活用し、ExcelとAccessを行ったり来たり。Excelのデータは、Accessのレコードにまんまコピペできるけどコツが必要。レコード端っこの「＊」マークをつかんでレコードを全選択してから貼付。うっかり貼る位置がずれてカーソルを中途半端に動かしてしまうと、画面を閉じたくても、Accessが「まだ入力は済んでいませんよ」と、ユーザーの行動をいちいち阻んできたりする。そして魔のEscキー鬼リピ。Accessを長年愛用しているユーザーと、こういう小さなストレスの積み重ねで離脱するユーザーの相違って

数値フィールド「超え/以上/未満/以下」　　　　＆昇順/降順の並べ替え☆ポイント※以上/以下：≧や≦の1文字記号は使えない。記入順は=を最後とする。※昇順・降順：昇順はASC抜きでも並べ替え可能。【超え】視聴回数が11万回超えの配信を昇順(12～TOP)で並べるSELECTM_配信リスト.[話数],M_配信リスト.[タイトル], M_配信リスト.[放送日], M_配信リスト.[Season],T_視聴.[視聴数(万回)]FROMM_配信リストINNER JOINT_視聴ONM_配信リスト.[話数] = T_視聴.[話数]WHERET_視聴.[視聴数(万回)]>11ORDER BYT_視聴.[視聴数(万回)] ASC;視聴回数が11万回超えの配信を降順(TOP～12)で並べるSELECTM_配信リスト.[話数],M_配信リスト.[タイトル], M_配信リスト.[放送日], M_配信リスト.[Season],T_視聴.[視聴数(万回)]FROMM_配信リストINNER JOINT_視聴ONM_配信リスト.[話数] = T_視聴.[話数]WHERET_視聴.[視聴数(万回)]>11ORDER BYT_視聴.[視聴数(万回)] DESC;【以上】視聴回数が11万回以上の配信を昇順(11～TOP)で並べるSELECTM_配信リスト.[話数],M_配信リスト.[タイトル], M_配信リスト.[放送日], M_配信リスト.[Season],T_視聴.[視聴数(万回)]FROMM_配信リストINNER JOINT_視聴ONM_配信リスト.[話数] = T_視聴.[話数]WHERET

INNER JOIN句を用いた検算方法（請求書）管理職の代理で、請求書の内容チェック～決裁をおこなう必要が生じた。私の人生にAccessは必要ない...と断言して早1ヶ月。電卓を叩く工程だけでもAccessに任せられないものか、画面と睨めっこ中。方法を調べる内、これまで取り組んできたINNER JOINの学習が活かせる可能性が生じた。別々のオブジェクト(テーブルやクエリ)に存在する同一データのレコード(行)を探し当て各オブジェクトの列(フィールド)をあたかもひとつのオブジェクト上のデータのように繋ぎ合わせることができる。ココナラのユーザー登録を例に挙げると...(会員IDを各テーブルの仲介役と仮定）テーブル1: ココナラ登録会員リストテーブル2: ココナラブログ投稿歴のある会員リストテーブル3: ココナラサービス出品歴のある会員リストテーブル4: ココナラサービス購入歴のある会員リストそれぞれのテーブルに、各条件を満たす会員IDが格納された状況下において「ココナラに会員登録している」かつ「ココナラブログを1度でも書いたことがある」かつ「ココナラで何らかの商品を出品したことがある」かつ「ココナラで何らかの商品を購入したことがある」INNER JOIN句を用いたSQLにより命令を与えることで、テーブル別に分類された上記条件をすべて満たす会員データを抽出することも可能。INNER JOIN句のこうした働きを応用することで、日頃は別々に運用されているテーブル同士またはテーブルをもとに作成されたクエリ同士を呼び集め一定の条件下における演算にも展開できる・・・はず。社内情報を社外に持ち出す

右外部結合（RIGHT JOIN）SQLをつくらないといけないパターン複数テーブルを用いてSQLを構成する際に用いる結合(JOIN)方法には、内部結合と(左/右)外部結合がある。【内部結合（INNER JOIN）】結合相手となるレコードが存在しない（またはNullである）場合結合を中止しお互いのテーブル(レコード)は非表示となる。【外部結合（LEFT JOIN/RIGHT JOIN）】結合先テーブルに一致するレコードがなくても（Nullでも）お互いのテーブル(レコード)を必ず表示する。【注意点】内部結合/外部結合の対応差によって影響を受けるのは「レコード（行）が表示されるか、されないか」であり設計したフィールド(レコードの見出し)自体はデータの有無に応じて消失することはない。【今回のテーマ】右外部結合(RIGHT JOIN)の必要性クエリのデザインビュー画面でテーブル間に結合線を引きJOIN(結合)させる際テーブル置き順、或いは結合線(矢印)の引く際のドラッグの方向によっては画面上の配置と、Accessが認識する「左右」が逆転するケースがある。Accessの「結合プロパティ」における左右は「画面上の見た目の位置」ではなく「結合線を引いた順番やAccess側の内部順序」で決まることがあり、「左外部結合にしたいから2番（左の全レコード）を選ぼう」と機械的に選ぶと失敗する。外部結合を選ぶ場合、左右どちらを主フィールドとするかは画面上の左右ではなく、ダイアログ内の具体的な説明文で判断しないと危険！第1段階のJOIN(結合プロパティ)上から2番め: M_登場人物の全レコードを表示する設定

左外部結合（LEFT JOIN）SQLをつくる複数テーブルを用いてSQLを構成する際に用いる結合(JOIN)方法には、内部結合と(左/右)外部結合がある。【内部結合（INNER JOIN）】結合相手となるレコードが存在しない（またはNullである）場合結合を中止しお互いのテーブル(レコード)は非表示となる。【外部結合（LEFT JOIN/RIGHT JOIN）】結合先テーブルに一致するレコードがなくても（Nullでも）お互いのテーブル(レコード)を必ず表示する。【注意点】内部結合/外部結合の対応差によって影響を受けるのは「レコード（行）が表示されるか、されないか」であり設計したフィールド(レコードの見出し)自体はデータの有無に応じて消失することはない。【今回のテーマ】現時点における全放送話リストの記録状況を出力し、未記入や条件不適合のレコード情報をチェックする。（「M_配信リスト」の話数に「M_登場人物」、  「M_登場人物」のゴジNoに「M_名簿」を繋ぎ、リストを見える化。）【左外部結合（LEFT JOIN）】【例】それぞれの放送話に登場するキャラクター名を記録していく。ただし、114話のうち、「M_登場人物」にデータがあるのは70話まで。また、71話めのゴジNoとして、「ココナラ」とダミー情報が混在。もちろん、「M_名簿」にはそのようなキャラクター登録はない。左外部結合の結果、データはどのように表示されるか？SELECT  M_配信リスト.[話数],   M_配信リスト.[タイトル],   M_登場人物.[ゴジNo],   M_名簿.[キャラクター名]FROM  (M_配信

内部結合（INNER JOIN）SQLをつくる複数テーブルを用いてSQLを構成する際に必要な結合(JOIN)方法には、内部結合と(左/右)外部結合がある。【内部結合（INNER JOIN）】結合相手となるレコードが存在しない（またはNullである）場合結合を中止しお互いのテーブル(レコード)は非表示となる。【外部結合（LEFT JOIN/RIGHT JOIN）】結合先テーブルに一致するレコードがなくても（Nullでも）お互いのテーブル(レコード)は必ず表示される。【注意点】内部結合/外部結合の対応差によって影響を受けるのは「レコード（行）が表示されるか、されないか」であり設計したフィールド(レコードの見出し)自体はデータの有無に応じて消失することはない。【今回のテーマ】それぞれの放送話に登場するキャラクター名を記録していく。すでにほかの記事で作成した「M_名簿」マスタテーブルを使用。各放送話への出演記録は別のマスタテーブルで管理をおこなう。【New】マスタテーブル「M_登場人物」を新設。114話分のレコードを設けたが、1話1レコードの構成。それぞれの放送話には複数名のキャラクターが登場する。そこで、複数の「ゴジNo」フィールドを試みたがAccessに拒否られる。1話に複数の登場人物を記録するためには、レコードを増やすしかない。当たり前のことかもしれないが、こういうところで躓くのだ。そこで、レコードを増やすための作業にかかる。2行目に新しいレコードを追加しようとしても114行目の下(最下段)に流されてしまう1話から順にレコード増やそうにも新規作成は最終行とかこういうとこホント、融

テーブル上の全フィールド(列)・全レコード(行)を表示させ特定のフィールド順に、レコードの並べ替えをおこないます。特定のフィールドとは、「視聴数(万回)」です。アニメの放送話ごとの再生数を記録したフィールドです。「視聴数(万回)」の降順に並べ替えを行い、人気順を調査します。「視聴数(万回)」フィールドの場所：既存のマスタテーブルに追加する方法と新たにトランザクションテーブルを追加しマスタテーブルに内部結合させる方法がある。再生回数は流動性を持つ集計情報であり、トランザクションテーブルで管理を行うのが王道。ただし集計日別の管理をおこなう必要がなく、単純に集計時点の累計視聴数を上書きする形で問題なければ、M_配信リスト内で記録をとり、レポート機能で都度、集計日ごとの読み取りデータを出力しPDF等で情報を残せば足りる。基礎学習⑤では同一テーブル内に「視聴数(万回)」フィールドを準備。基礎学習⑥では別テーブルを用意し、記録日ごとに「視聴数(万回)」の累計数を書き留めていく方法をとってみる。⑥の方法では追加項目が一気に増えるため、順を追って整理していきたい。並び替えのために使用する関数DESC：降順ASC：昇順クエリを使わず、テーブルプロパティ「並べ替え」で降順設定をおこなう方法もある。[M_配信リスト].[視聴数(万回)] DESC同一テーブル(※)にて[視聴数(万回)]集計(※)マスタテーブルM_配信リスト全フィールド(列)・全レコード(行)表示SELECT M_配信リスト.*, FROM M_配信リスト【New】ORDER BY 句ORDER BY テーブル名.[フィールド名] D

データベースのテーブル全フィールドの内、特定フィールドを表示したいときに用いられる、標準的なデータ取得SQLです。SELECTテーブル名.[1つ目の指定フィールド名],テーブル名.[2つ目の指定フィールド名], テーブル名.[3つ目の指定フィールド名]FROM テーブル名;1. SQLの構造7-1.SQL基礎学習①と同じく、ここでもふたつの「句」が登場する。SELECT 句:SELECTM_配信リスト.[話数], M_配信リスト.[タイトル], M_配信リスト.[放送日], M_配信リスト.[Season]役割:どの列（フィールド）のデータを取得するかを指定詳細:テーブル名「M_配信リスト」前回のように全フィールドを一括取得する場合、*（アスタリスク）を用いた命令句が成立するが、一部のフィールドのみ取得する場合においては、具体的なフィールド名をカンマ（,）で区切って「どのテーブルの、どの項目か」を正確に指定する必要がある。今回はテーブル名「M_配信リスト」の内、[タイトル][放送日][Season]フィールドを表示。FROM 句:FROM M_配信リスト;役割:データの取得元となるテーブルを指定詳細:「M_配信リスト」テーブルからデータを取るように指定。末尾の ;（セミコロン）は、SQL文の終わりを示す。2. 本SQLの役割「M_配信リスト」テーブルに格納されたすべてのレコード（行）の内、指定した項目（列）を抽出して表示。補足：「フィールド名」の[](角かっこ)の意味「プログラムの命令(予約語)の内、ここからここまでが名称」と固有名詞の存在をAccessに伝えるための境界線。一

長年使ってきたソフトを開いたら、起動しない。エラーの文言をそのまま検索すると、データベースが壊れているらしい。そんな状況になったことはありませんか。・業務で使っているアプリが起動せず、データが読めなくなった・`database disk image is malformed` のようなメッセージが出る・バックアップはあるが、半年前のもので、そこから今までの入力が入っていないまず、いちばん急ぐことをお伝えします。何よりも先に、コピーを取ってくださいそのファイルに、これ以上さわらないでください。やることは1つだけです。壊れたファイルを、別の場所へコピーする。それだけです。USBメモリでも、別のフォルダでも構いません。できれば2か所に置いてください。理由は単純で、復旧を試みる操作そのものが、状態をさらに悪くすることがあるからです。修復ツールを走らせる、アプリで開き直す、再インストールする。どれも、残っている断片を上書きしてしまう可能性があります。元のファイルさえ手つかずで残っていれば、何度でもやり直せます。復旧で最初にやるべきことは、直すことではなく壊れた状態を保存することです。「何％戻りますか」に答えられる人はいません次に聞きたくなるのが、これです。ですが、この質問に事前に答えられる人はいません。データベースが壊れるといっても、壊れ方はさまざまです。先頭の数十バイトだけが書き換わったのなら、中身はほぼ無傷です。ファイルの後ろ半分が切り落とされていたら、その部分は誰にも取り戻せません。消えたバイトは、どんな技術でも復元できません。そして、どちらの壊れ方なのかは、開いてみるまで分かりま

クエリを通してテーブルを学ぶ...選択クエリ作成問題で登場する式・発注数量 ＝ 最大在庫数（計）ｰ（出庫数（計）-入庫数（計））Accessの集計関数で表現すると、こうなるらしい。発注数量: [最大在庫数] - ( Nz(Sum([出庫数]),0) - Nz(Sum([入庫数]),0) )” Nz(Sum([]),0)”とは？トランザクションテーブルに対象レコードが1件も見当たらない場合、Sum() は合計値を出せず“結果なし（Null）”になる。その Null が式に混ざると計算結果を出せなくなるため、Null を0(ゼロ)に置き換える保険として Nz(Sum([ ]),0) が使われる。” Nz(Sum([]),0)”が最大在庫数には不要な理由商品マスタの「最大在庫数」は1商品につき1行だけ存在する固定値であり、設計上Nullになる恐れはない。データインポート用のExcelにも数字がしっかり入っており、Nz()不要。1商品につきデータ1件の構成なので、集計Sum() も必要ない。” Nz(Sum([]),0)”が必要なのはトランザクションテーブル上の「入庫数/出庫数」だけSum([出庫数]) ：出庫数の合計Sum([入庫数]) ：入庫数の合計Sum()は「対象レコードが1件もない」場合にNullを返す(計算できる材料が揃わないことにより算定結果を出せないと判断する)働きがある。対象レコードが 1 件以上 → 合計値（数値）を認める対象レコードが 0 件 → Nullを認める例：「商品マスタ」のある商品に対し、入出庫トラン上の入庫が1回も無い → Sum([入庫数]) = N

Accessで介護支援記録システムを作った理由－11 これまで長い間、介護支援記録を管理するデータベースシステムをAccessを使い開発することとした経緯等について語ってきましたが、このシリーズの最後として、別の視点から見たAccessの凄さにについて触れたいと思います。 Accessのアプリケーションとしての性格は、現状、小規模かつローカルな環境下で、高度なリレーショナルデータベースシステム(RDBMS)を開発し運用するためのソフトとして定義づけられると思います。 長年にわたりバージョンアップを重ねてきた結果、動作も安定しており、データベースを動かすスピードも高速です。しかも一ライセンス当たりの価格が安く、無料のランタイムも使えるなど、他のデータベースソフトよりもコスパの良さは抜きん出ています。 しかし、Excelに比べるととっつきにくく、マクロやVBAを使ったアプリの開発も初心者にとってハードルが高いため、様々な職場で広く普及することは妨げられてきたように思います。 視点を変えてみると、これは実に「勿体ない」の一言です。 企業が自らのオープン系システムの中に、情報通信会社に頼んでRDBMSを構築しようとする場合には、データベースを操作する言語としてSQLが一般的に使われています。 SQLは優れた言語で、RDBMS開発に欠かせないものであり、様々な仕様を持つデータベースの殆どがSQLに対応しています。 しかし、SQLはデータベースに対してしか命令できない言語のため、C言語など他のプログラミング言語の中に組み込んでシステム全体を開発しなければなりません。当然ながら、このような作

YouTubeでも紹介しています。是非ご覧ください。SQLをSQLビューから作成を始めると、今までのクエリが無駄に思えてきます。 エイリアスとjoinを利用して、クエリを作成します。サイバイマンを減らすクエリ こんにちは。伊川です。 前回は、エイリアスについて解説しました。 しかし、実行するクエリに関しては、3つあります。 この3つのクエリを1発で実行する方法を紹介します。 単純に、INNER JOINと、エイリアスを利用します。 JOINに関しては、下記の記事で紹介しています。 相変わらずですが、競馬ネタであることをご了承ください。 このブログはこんな人にお勧め ACCESSを勉強している人 クエリを勉強している人 ACCESSにクエリが沢山ある人 このブログを、読み終わるころには・・・・ 複数のクエリを作成すると、メンテナンスが困難になります。 SQLを、直で編集するスキルがあれば、複数のクエリを作成することなく、 1つのクエリで実行することができます。 1発のクエリで実行する Q_買い目1というもを作成するのに、 Q_指数買い目順位2 Q_指数買い目順位5 上記の2つのクエリが必要となります。 当然、1発で実行できるなら、2つのクエリは不要になるわけです。 この、Q_指数買い目順位2、Q_指数買い目順位5は、MT_数値追加から、派生したものです。 MT_数値追加から、派生したクエリ（サイバイマン）ならば、1発で実行できます。 1発のクエリで実行する　作業手順　その1　見出しの考え方 SELECT ～ FROM～ WHERE～ この形が基本です。 SELECT ここには、ク

　何種類かのデータベースを扱う技術者にとって、専用ツールを使用したクエリテストは避けられないものです。　　私がストレスを感じるのは、データベースエンジンごとに、ユーザーインターフェースの使い勝手が全然違って、「ただクエリをテストしたいだけ」なのに、クエリに集中できないことです。　そこで私が愛用しているツールが「WinSQL」です。　　　www.synametrics.com/SynametricsWebApp/Download.do?ProgName=WinSQL　これは様々な種類のデータベースに対して、一つの共通したインターフェースからクエリを発行することが出来るツールです。　これを使用すると、データベースにアクセスするプログラムを開発する、一般的な手順の中で(１) 画面設計／作成(２) DB接続※場合により、トランザクション処理を開始。(３) SELECTクエリでテーブルデータを読込み。(４) (３)項の結果に応じて、INSERT, UPDATE, DELETEなどのクエリを発行。(５) SELECTクエリで、データの不整合がないか確認。※場合により、トランザクション処理を終了。といった流れの (３)(４)項を 効率的に進めることができます。非常におすすめのツールです。

Accessに搭載中のReplace機能今さらだけど、AccessのSQLビュー画面においてもモジュール画面と同様に「検索・置換」の機能が使えることを知った。顧客から依頼を受けた期日までに、見積資料を仕上げる必要があり過去の学習メモ内ですでに制作済みのAccessファイルをベースにコードの一部をちゃちゃっと入れ替えて完成させたかったのでこういう機能が使えるのは、地味に助かる。「検索・置換」といえばAccessに限らず「Ctrl キー+ F」がお馴染みだけど「Ctrl キー+ H」を使っても、ビュー画面に「検索・置換」ボックスを呼び出すことができる。【Microsoft365 画面】画面右上に出現した「検索・置換」ボックス上の枠に文字列を入力すると、Accessが該当する文字列をマーキングしてくれる。「Replace」と書かれた下の枠に、書き換えたい文字列を入力する。上段：置換前（現在）の文字列下段：置換後の文字列入力枠の右にある二つのイラスト右に位置する(黒枠で囲まれた)イラストが「すべて置換」を意味する。クリックと同時に、該当するすべての文字が書き替わる。VBAコードを記入する際に用いるモジュール画面では「検索・置換」機能はとても便利。「Ctrlキー+ F」や「Ctrlキー+ H」を押して画面を呼び出せる部分は同じ。モジュール画面の機能のほうがぱっと見、分かりやすい。置き換え後の画面。日本語を用いてはいけない箇所なので、Accessが怒って真っ赤。【Access2024 画面】MicrosoftAccess365と同様の手順で呼び出せる「検索・置換」ボックス。こちらの方がデザ

納税の義務化により、労働者は住民票のある自治体に対し、条件に応じ税金を納める必要がある。「ふるさと納税」は、一定の手数料を支払うことで納税者みずから納付先自治体を選び寄附という名目で住民税の一部を前払い(所定の控除申請が必要)できる制度である。納税者にとっては、寄附への返礼として各地の特産品を受け取ることができ、人生の楽しみが増える。（マイナと連携されてからは控除申請も便利になりましたね。）納税者には人気の制度、自治体にとってはどうだろう。Accessで作成したテーブル「受入額」：「自治体に入ってきた寄附金総額」を示す。自治体にとっての収益である。Accessで作成したテーブル「控除額」：「本来なら自治体が受け取るはずの住民税の内、他自治体への寄附により失った住民税」を示す。自治体にとっての損失である。受入額から控除額を差し引くことによって「ふるさと納税によって、自治体は最終的にお金が増えた（流入超過）のか、減った（流出超過）のか」税収への影響を可視化できる。これまでの作業では「自治体リスト」と「受入額」＆「控除額」の各テーブルの自治体名(フィールドの値)に差異があったことから計算のためのリレーションがむずかしい状況にあったので名称を統一するためのSQLを追加した。前記事でクエリを用いた各テーブルの自治体名の統一に成功したはずなので次はそれぞれの自治体レコードに自治体IDを適用する段階に移ります。まず、変更前後の確認用SQLを用いて都道府県47件が全部表示されることを確認してから。「自治体リスト」の都道府県と、「変換クエリ」で県や府を取り除いた都道府県をINNER JOINで重

業務システムで「保存できない」「計算結果が合わない」「特定の画面だけエラーになる」といった問題が起きると、すぐに修正箇所を探したくなります。しかし実務では、原因が見えないまま修正に入るほど、影響範囲の見落としや別不具合につながりやすくなります。最初に大切なのは、直すことではなく、何が、どの条件で、どこまで起きているのかを整理することです。問題が長引く理由の多くは、情報が断片的なまま共有されることにあります。「エラーが出る」という一言だけでは、入力値の問題なのか、権限なのか、データの状態なのか、プログラムの分岐なのか判断できません。業務システムは、画面、処理ロジック、データベース、外部ファイル、利用者権限がつながって動くため、画面だけを見ても原因がわからないことがあります。最初に確認したい情報は5つあります。1つ目はエラーメッセージです。文言だけでなく、発生時刻、画面名、操作内容も残します。2つ目は再現手順です。どの画面を開き、どの項目に何を入力し、どのボタンを押したかを順番に書きます。3つ目は発生条件です。特定の利用者だけか、特定の日付や区分だけか、同じ操作でも成功する場合があるかを確認します。4つ目は正常時との違いです。過去に成功したデータ、別の利用者、別の月度などと比較すると差分が見えます。5つ目はログ、ソースコード、DBデータです。ここで画面の現象と内部処理を突き合わせます。対応手順としては、まず現象を1枚にまとめ、再現できるかを確認します。次に正常データと異常データを比較し、入力値、権限、マスタ、履歴データの違いを見ます。そのうえでログの時刻と処理の流れを合わせ、該当す

クエリを設計したあとテーブルの構成を変更したとき、クエリを編集したくてもデザインビューに切り替えられないことがある。シンプルなクエリであればSQLビューで直接、式を編集してみるしかない。例：「書籍マスタ」に外部キーとして「利用者マスタ」の「キャラＩＤ」が含まれ、相応の選択クエリを組んだ後、その構成が不要となり「書籍マスタ」から「キャラＩＤ」を削除したケース【修正前】SELECT 書籍マスタ.書籍ＩＤ, 書籍マスタ.書名, 書籍マスタ.[キャラＩＤ　], 利用者マスタ.[キャラ名]FROM 書籍マスタ LEFT JOIN 利用者マスタ ON 書籍マスタ.[キャラＩＤ　] = 利用者マスタ.[キャラＩＤ];【修正】SELECT 書籍マスタ.書籍ＩＤ, 書籍マスタ.書名FROM 書籍マスタ;他オブジェと結合後のテーブルを編集する際は、クエリの関係フィールドを整理してから。フォームやレポートは後出しの編集も可能だけど、クエリは全体が機能しなくなるから気を付けないといけない。今回、貸出入力簿の作成にあたり、数値のみである書籍ＩＤのデータ型を意図的に「短いテキスト」としている。当初の設定は数値型だったが、書籍マスタ＆貸出トランのリレーションの際、プロパティシートの規定値を0にしていても、フォーム読み込み時にAccessがマスタキーを0埋めし、勝手にレコードに0が書き込まれ＋データ不整合によりAccessが落ちる現象が起きてしまい、かなりの時間をムダにした。データ型を「短いテキスト」にすると症状は治まった。これまで例題を解いていて、数値しかないフィールドにテキスト型が使われていて不思議だった

SQLで「ユーザーごとの最新データだけ取得したい」という場面があり、当初は `MAX(update_date)` を使って取得しようとしていました。ただ実際の要件としては、> 「最新日付の“行そのもの”を取得したい」というもので、単純なMAX集約では対応できず、少し悩んだポイントでした。最終的に採用した方法最終的には、`ROW_NUMBER()` を使って対応しました。SELECT *FROM (    SELECT         user_id,        update_date,        ROW_NUMBER() OVER (            PARTITION BY user_id            ORDER BY update_date DESC        ) AS rn    FROM your_table)WHERE rn = 1 ポイントこの書き方にすることで、以下が実現できます。* ユーザーごとの最新1件を取得* 重複データの整理* ランキング的な抽出* 柔軟な並び替え条件の指定実務でよく使う場面実際の業務では、以下のようなケースでよく使います。* 最新履歴の取得* 重複データの除外* ステータスごとの最新情報取得* ランキング・順位付け処理特に「最新1件だけ欲しい」という要件は意外と多く、この書き方を知っているかどうかでSQLの設計がかなり変わる印象があります。MAX()との違いで詰まりやすいポイント最初に `MAX(update_date)` で考えると、* 最新日付は取れるが行全体が取れない* JOINが必要になる* 複雑

Private Sub Form1_Load(sender As Object, e As EventArgs) Handles MyBase.Load  '*********************************************************************  ' Form1　を Load した時のイベント　押した処理  '*********************************************************************         ' ポスグレ接続         Dim Con As NpgsqlConnection = Nothing         ' クラス ClassDB　から　接続文字列を取得 （接続文字列を入れればOK）         Con = New NpgsqlConnection(ClassDB.ConString)         Con.Open()         ' コマンド         Dim Cmd As NpgsqlCommand = New NpgsqlCommand("select id, name, ranking,group_name from countries;", Con) ' SQL　の結果を格納する         Dim rs As NpgsqlDataReader ' SQL 実行         rs = Cmd.ExecuteReader         rs.Read()         txthyouji.Text = rs

プレースホルダINSERT INTO テーブル (列1, ...) VALUES (?, ...)サブクエリINSERT INTO テーブル (列1, ...) サブクエリテーブルの列とサブクエリの列の配置が同じ場合INSERT INTO テーブル サブクエリINSERT + UPDATE重複していたら UPDATE するINSERT文 ON CONFLICT(主キー)DO UPDATE SET 列1 = excluded.列1, ...

日付の値年CAST(strftime("%Y", 日付) AS INTEGER)月CAST(strftime("%m", 日付) AS INTEGER)日CAST(strftime("%d", 日付) AS INTEGER)計算n日前date(日付, '-n day')列のデフォルト値現在時刻 （TEXTとして格納）DEFAULT CURRENT_TIMESTAMP

テーブルSELECT ...FROM (サブクエリ)列SELECT ...FROM ...WHERE ... IN (サブクエリ)

グループ化SELECT A列, ...FROM テーブルGROUP BY A列合計SUM(列)平均NULL を除外AVG(列)NULL を 0 として計算AVG(COALESCE(列, 0))最大MAX(列)最小MIN(列)並べ替え集計した列で並べ替えるSELECT A列, SUM(B列) AS 別名FROM テーブルGROUP BY A列OEDER BY 別名集計してから絞り込むSELECT A列, SUM(B列) AS 別名FROM テーブルGROUP BY A列HAVING 条件

ココナラでは、自身のブログの閲覧数をマイページ「サービス・ブログ分析」画面から確認できます。折れ線グラフで表示もしてくれる。便利デスネ～ただし、記録はマイページに訪問した当日の90日前まで。8月1日(土)に確認できたのは、5月3日(日)の閲覧数までだった。8月3日(月)に確認できるのは、5月5日(火)の閲覧数まで。91日後になると今日の情報は消えてしまうということになる。累計閲覧数を毎日1レコードずつ保存し、たとえば翌年同日の訪問数と本日分を比較し増減の動向など追跡できる。その気になれば、「本日から遡った90日間の閲覧数の増減」を日々集計することもできる。「本日から遡って90日間の閲覧数の増減」を算出するための計算式：増減: [90日累計閲覧数]-Nz(DMax("[90日累計閲覧数]","T_閲覧記録","[記録日]=#" & Format([記録日]-1,"yyyy/mm/dd") & "#"),0)[90日累計閲覧数]：フィールド名は[]で包んで、固有名詞であることをAccessに伝えるFormat([記録日]-1,"yyyy/mm/dd")：今日の記録日から 1日引いて「前日の日付」を作る"[記録日]=#2026/08/01#"：「前日の日付と一致するレコードを探せ」という検索条件を文字列で作る日付検索の際は必ず#2026/08/03#  のように日付を # で囲むDMax("[90日累計閲覧数]","T_閲覧記録", 条件式)：前日のレコードの「90日累計閲覧数」を取り出す（1日1行なら「前日の値そのもの」になる）Nz(前日の値, 0)：前日のレコード

昇順RANK() OVER (ORDER BY 列 ASC)降順RANK() OVER (ORDER BY 列 DESC)グループ内で順位付けするA列でグループ化して、B列内で順位付けRANK() OVER (  PARTITION BY A列  ORDER BY B列 ASC)

「誰かが毎日やっている」という違和感どの職場にも、当たり前のように存在している「毎日のルーティン作業」があります。「各拠点から送られてくる数字を集計する」「決まった形式のレポートを毎朝作成してメールする」一回あたりは5〜10分程度の作業かもしれません。しかし、それが365日積み重なり、仮に複数の担当者が行っているとしたら、それは年間でどれほどの損失になるでしょうか。私はかつて、こうした「人間がやらなくてもいい苦労」を技術で消し去ることに没頭していました。「現場の痛み」をコードに変える私が社内SEとして現場を支えていた頃、大切にしていたのは最新のIT用語を並べることではなく、目の前の担当者の「手が止まっている時間」をなくすことでした。例えば、毎日の帳票作成。以前は、データベースから手動でデータを抽出し、Excelに貼り付け、加工して、ようやく関係者に送信していました。「これ、自動でできるんじゃないか？」そう思い、PythonやSQLを独学し、VBAと組み合わせて独自のプログラムを組みました。結果、ボタン一つ……いや、ボタンすら押さなくても、決まった時間にシステムが勝手にデータを集計し、整理されたレポートが関係者のメールボックスに届く仕組みが出来上がりました。「自動化」の本当の価値は、時間の節約だけではない事務作業が自動化されると、職場には二つの大きな変化が起きます。「ミス」というストレスからの解放人間が手作業で行う以上、コピー＆ペーストのミスや入力漏れはゼロにはできません。プログラムによる自動化は、精度を100%に引き上げます。「考える仕事」に集中できる単純作業に追われていた担当

SQLUPDATE テーブル SET 列 = 値 WHERE句

NULLを含めたテーブルの行数COUNT(*)NULL以外の値COUNT(列)

学習メモ2-1.の再現ウィザード機能でフォームを設計する際、フィールド名にカッコ（）が用いられていると処理が中断してしまう。エイリアスにてカッコなしの名称に置き換えると直ちにウィザードが機能する様子を伺うに、カッコが原因。

合計SUM(列)行数 COUNT(*) 　NULLを無視 COUNT(列)

はじめまして。ChrSantaと申します。ココナラで、SQLクエリの作成・修正サービスを始めました。【サービス内容】「やりたい集計をSQLで書けない」「動いているSQLの結果がおかしい」「処理が遅い」といったお悩みに対して、クエリの作成、不具合の調査と修正、書き方の見直しやインデックスの提案を行います。MySQL・PostgreSQLを中心に対応し、Oracle Databaseは標準的なSQLの範囲で対応します。各クエリには、処理内容を説明するコメントと解説書を付けてお渡しします。【こんな方におすすめです】・データの集計を、SQLで効率化したい方・自分で書いたSQLの結果がおかしく、原因が分からない方・社内で使うSQLを、説明付きで残しておきたい方本番環境への直接の接続は行わず、テーブル構成と個人情報を含まないサンプルデータをお送りいただく形で対応します。気になる方は、まずはお気軽にメッセージでご相談ください。ご相談は無料です。

データ型整数INTEGER小数REAL小数に変換CAST(値 AS REAL)剰余計算値1 % 値2

if CASE   WHEN 条件式1 THEN 値1  ...  ELSE その他の値END入れ子OKswitch CASE 列   WHEN 値① THEN 値1  ELSE その他の値END入れ子OK

WHERE　と　HAVING ①WHERE　で行を絞り込む ②グループ化して集計③HAVING　で行を絞り込むJOIN ON ①左テーブル　をSELECT ②ON　で結合する行を　右テーブル　から探す

# はじめにSQLAlchemy とは、Python で使用できる ORM です。Python コミュニティにおける最も使用されている ORM ライブラリの一つとなっているので、使用する機会も多いかと思います。そんな SQLAlchemy の基本的な使い方をまとめてみました。まずは、ここから基本的な操作を学び、応用的なものについては、随時調べながら実装すると良いかと思います。# 使い方## インストール```$ pip install sqlalchemy```## モデルの作成以下のようにモデルを定義することで実行のタイミングでテーブルが生成されます。```pythonengine = sqlalchemy.create_engine('sqlite:///db.sqlite3', echo=True)Base = declarative_base()class Account(Base):__tablename__ = 'account'email = Column(String, primary_key=True)password = Column(String)Base.metadata.create_all(bind=engine)```## 基本操作### Insertデータを追加する際は、まず、session を生成します。その後、作成したモデルにデータを入力し、session に対して追加します。追加したデータを commit でデータベースへ反映して、session を閉じます。```pythondb_session = sessionmaker(bind=e

SQLSQL was developed to use relational database. It is standardized by ISO andJIS and is widely used.You can use SQL (Structured Query Language) to create, manipulate, update,and delete tables. SQL consists of DDL (Data Definition Language),DCL (Data Control Language), and DML (Data Manipulation Language).DCL may be included in DDL.■Define a tableThe table has a two-dimensional structure consisting of rows and columns.It stores the actual data. There can be multiple tables, but the table namesmust be different.（To identify the table）For example, if you define a "Grade" table consisting of "Student_Number","Name", "Language", "Math", and "Class", SQL is as bellows.CREATE TABLE Grade(Student_N