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

コンボボックスには「表示専用」パターンと「編集/保存」パターンがある目的はⅠ.値集合ソースの参照（レコードの表示）なのか　　　Ⅱ.値集合ソースの代入（レコードの上書き保存）なのか【例】図書館の利用者登録フォーム利用者の初回利用登録日に応じて利用期限を算出する必要があるためクエリに計算式を持たせ、フォームのレコードソースはクエリとしているⅠ. 照合が目的のフォーム     コンボボックスは、値集合ソースの参照（レコードの表示）のみレコードソースはクエリのまま各テキストボックスのコントロールソースに直接、column関数を書き込む利用者名∇=[cmb利用者].Column(1)誕生日∇=[cmb利用者].Column(2)住所∇=[cmb利用者].Column(3)登録日∇=[cmb利用者].Column(4)利用期限∇=[cmb利用者].Column(5)Ⅱ. 登録変更および新規登録が目的のフォームコンボボックスは、値集合ソースの代入（レコードの上書き保存）使用レコードソースをクエリからマスタテーブルに変更し各テキストボックスのコントロールソースからcolumn関数を消去テキストボックスがテーブルの項目と直接つながる（連結）必要があるため値集合ソースから選択した各フィールド名を各コントロールソースにセット※VBAが実行されれば、クエリを通じテーブルのレコードに計算結果が反映更新後処理の[イベント プロシージャ]にcolumn関数をVBA形式にて記入∇Private Sub cmb利用者_AfterUpdate()     Me!利用者名 = Me!cmb利用者.Column(1)

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

「Accessを使って業務効率化」Accessに罪はないが、この「業務効率化」を大義名分とする動きが私はちょっと苦手だ。従業員の労働環境を思いやってる言葉の裏で、念頭にあるのは「人件費の削減」でしょうねとしか。基本給だけでは食べていけない層も一定数いる。Accessを学習し始めた動機は自己研鑽であり、業務(会社)のためではない。お客さんや職場の仲間のためなら、いくらでも頑張るけどね。ただ、お盆の時期が来るたび、思い出す言葉がある。「仕事はだいじにせないかん」祖父の口癖だった。祖父の家は米農家。ふるさと納税の返礼品として利用いただくこともある特産品だがそれだけでは生計が成り立たず祖父は60過ぎて運転免許を取得し副業を始めた。妹たちは医療の国家資格を取り専門職の道に進んだ。名称から敬遠されがちな職種だが体力のない女性でも長く勤めることができ収入が安定しているとのことで、父の旧友からおススメされた職業。祖父は、実習先の病院の玄関先に軽トラを乗りつけ「孫がお世話になっております」と、病院関係者に深々と頭を下げて回った。今も語り草だ。それから数年が経過したある日。久しぶりに会った妹が「やば、始末書」と頭を抱えていた。勤め先の院内でハサミが1丁、行方不明。職員総出で探したが見つからないとのこと。患者が誤って持ち出した場合、命の危険にさらされないとも限らず大問題。ほかにはこんなエピソードも。「教授と食事する時は同時に食べ終える。早すぎても遅すぎてもダメ」別の妹からは、看護師の残務を何度も肩代わりしていると聞く。「私のほうが後輩だし」そうした日常を繰り返しつつ、妹のひとりは仕事の傍ら大学院に通

テーブル上の特定レコードの全フィールドを表示させる案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を用いたデータベース作りの学習記録ですいや、今回の作品はデータベースと呼べるほどのレベルではない。ブログ投稿はココナラブログが人生初。そもそも下書きと公開設定の区別もついておらず、記事は下書きした順に掲載されるとばかり思っていた。投稿前の下書きの段階ではココナラブログの並びに不

【例】図書館の利用者登録フォーム学習メモ3-7では利用者の初回利用登録日に応じ、利用期限を算出した。しかし実際には運転免許等と同様、利用者の生年月日を基準に「初回登録年の○年後の誕生日まで」と定めているケースもある。実務上、個人情報が掲載されたテーブルと、その他の登録情報テーブルとは分けて管理したほうが望ましいケースもある。そこで、「利用者マスタ」テーブルの内、個人情報を利用者マスタに残し、図書館利用情報を示す「登録日」と「利用期限」を「図書利用券マスタ」として利用者マスタから切り離してみることを思いついた。両テーブルはクエリで結合させ、利用期限を算出し、フォームのレコードソースとすれば問題ないと考えた。利用期限は登録年の3年後の誕生日まで利用期限: DateSerial(Year([登録日]) + 3, Month([誕生日]), Day([誕生日]))しかし、さすがはガンコ爺Access（言い方！）テーブルを切り分けた以外はゆうべとまったく同じ設計なのに、微動だにしないではないか!!わたし遅くとも1時には寝たいのよ(੭ु(;・∀・))੭ु⁾⁾「連結列」：デフォルトは１だが、ソースであるクエリ構成上「図書利用券ID」が1列目。利用者IDの列を基準とする場合、2列目なので「2」とする必要があったみたい。「column関数」：レコードソースが変更され列数が変わったため、調整する必要がある。利用者名∇=[cmb利用者].Column(2)誕生日∇=[cmb利用者].Column(3)住所∇=[cmb利用者].Column(4)登録日∇=[cmb利用者].Column(5)利用期限∇

【例題】選択クエリの作成以下仕様に基づき、商品ごとの[理論在庫数](注)が[最小在庫数]を下回る商品を抽出のうえ、必要な[発注数量]・[仕入金額]を算出する選択クエリを作成しなさい。(1) クエリ名は『仕入先別発注対象商品』とすること。(2) 表示するフィールドは下記とすること。① [仕入先ＩＤ]② [仕入先名]③ [電話番号]④ [ＦＡＸ番号]⑤ [商品ＩＤ]⑥ [商品名]⑦ [仕入単価（税抜）]⑧ [最大在庫数]⑨ [最小在庫数]⑩ [理論在庫数]⑪ [発注数量]⑫ [仕入金額](3) [理論在庫数]のフィールドについては、下記の値を算出し設定すること。●下記（ア）から（イ）を減算した値（ア）「商品ＩＤ」ごとの「入出庫トラン」テーブル「入庫数」の合計値（イ）「商品ＩＤ」ごとの「入出庫トラン」テーブル「出庫数」の合計値(4) [発注数量]のフィールドについては、下記の値を算出し設定すること。●[最大在庫数]から、上記(3) [理論在庫数]を減算した値(5) [仕入金額]のフィールドについては、下記の値を算出し設定すること。●[仕入単価（税抜）]に、上記(4) [発注数量]を乗算した値(6) 抽出条件として、下記を設定すること。●上記(3)[理論在庫数]が、[最小在庫数]を下回るレコードのみ抽出(7) [仕入先ＩＤ]の昇順で、並び替えを設定すること。(8) クエリ内の各テーブル間に適切な結合および結合プロパティが設定されていること。学習メモ1-9.でひと通り作成「例題⑪：発注数量」演算で失敗【×】発注数量:Nz(Sum([最大在庫数]),0)　　　-(Nz(Sum([入庫数])

学習メモ4-1.において作成してみたレポート（見積書）たまたま明細が2ページ目に突入したことでレポートヘッダーに置くべき情報をページヘッダーに格納してたと気づけた理解が足りない(///∀///)Accessレポートの構造自分なりにまとめてみたまちがっているかもしれないけど① レポートヘッダー役割: 表紙/背表紙、まえがき配置：レポートの冒頭（1回だけ表示）② ページヘッダー役割: 見出し（ラベル）配置: 全ページ先頭（レポートヘッダーの次項目）③ グループヘッダー役割: 指定したフィールド単位におけるグループ化配置: グループ毎の先頭（ページヘッダーの次項目）④ 詳細セクション役割: 収納されたレコード全数分のデータ表示　　　セクション内のデータをレコードの数だけ繰り返し表示配置: レポートの中央（ヘッダーとフッターのあいだ）⑤ グループフッター役割: 指定したフィールド単位におけるグループごとの小計配置: グループ毎の末尾（詳細セクションの直下）⑥ ページフッター役割: ページ番号配置: 全ページ末尾　　　レポートフッターが用意されている場合、その下段に表示⑦ レポートフッター役割: 奥付け、あとがき、総計配置: レポートの最後（1回だけ表示）　　　ページフッターが用意されている場合、その上段に表示        

「ふるさと納税」ゆかりのある自治体、応援したい自治体、お気に入りの特産品を扱う自治体に対し寄附をおこなうことで、納税者が在籍する都道府県や市町村の枠を超え、寄附先の自治体に住民税が振り替えられる形となる制度。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

٩(σ▿σ)و 宛先＋CC欄追加に成功数十万円かけ開発した社内アプリと遜色ないどころか機能を拡充できるなんてありがとうAccess　|дﾟ)コード編集にはOneNoteが便利Microsoft標準搭載履歴を書き留めていけるし検索しやすく学習向きCC欄追加のためのコード編集箇所は４つ① SELECT文に 「T_送信先」マスタテーブルの[CC] 追加② CC情報格納のための変数宣言：Dim ccAddr As String 追加③ CCフィールド読込：ccAddr = ParseEmail(rs.Fields("CC").Value)追加　※ParseEmailとは構文からアドレス文字列のみ抽出して整形する働き④ CCの中身を設定：If Len(ccAddr) > 0 Then　追加　※CC欄にゼロを超えるデータ量、つまり何らかの情報が存在すれば稼働CC追加版コード全文掲載Private Sub cmd_メール作成_Click()    On Error GoTo ErrHandler    ' 実行パラメータ    Dim AccountIndex As Long: AccountIndex = 1    Dim IntervalMs As Long: IntervalMs = 700    ' 送信フロー制御    Dim ShowConfirm As Boolean: ShowConfirm = True ' 送信前にプレビュー表示する    Dim SaveToDrafts As Boolean: SaveToDrafts = False ' メール下書

(*σ_σ)「学習メモ6-2. Access使ってOutlookメール②」に掲載した「メール作成」VBAコードの書き換え（不要コードの撤去）顧客アドレス欄(F_送信先編集)に複数のメールアドレスが含まれていた場合、先頭の1送信先に限定しメールを作る仕様のコードを組んでた(下記)。↓　↓' 区切り（; , 空白 など）は先頭だけ採用Dim pos As Longpos = InStr(1, s, ";"): If pos = 0 Then pos = InStr(1, s, ",")If pos = 0 Then pos = InStr(1, s, " ")If pos > 0 Then s = Left$(s, pos - 1)コードの意味：『セミコロンの位置(pos)を探し、その左側の文字列(posのひとつ前の文字まで)をメールアドレスとして拾い上げる』1社につき1宛先と固定したい場合は上記内容で問題ないが、実務上はひとつの事業所につき複数の担当者にメールを一括送信すべきケースが多い。これまで自分は、上記仕様をバグと勘違いしていた。複数の宛先に対しメール起こしする際には、アドレス欄への複数アドレス記入は「セミコロン(;)」を外した状態でアドレス同士を連結させておき、Accessによるメール下書きが完成するのを待って、Outlookメールアドレス欄に直接「セミコロン(;)」を記入し、Access上で結合済みのアドレスを再び切り離すという、手間ひまをかけていた。(///Д///)余分な処理コード数行を消すだけで解決できたはずなのに、なぜ今まで気づかなかったのか？おバカなくせ

著作権おまいう、ごめんなさい　|_σ)ゞ※アニメのタイトルは著作権というより商標権(商取引に利用しなければギリ許容範囲)ココナラ出品者さんに依頼し、おかげさまでこれまでほんとうに多くの学習ヒントやシステムサンプルをいただいてきた。Accessに関するスキルを問う大会に出場することが目標だった。インターネット検索しても引っかからないぐらいマイナーな大会で、成績を出したところで履歴書や職務経歴書を飾るような武器にはならない。けれど、自分にとっては夢の舞台であり納得できる作品を作りあげることが、なんとしても叶えたい夢だった。そのための自己投資は惜しくなかった。だけど能力不足により、今年も好成績を残せないまま終わってしまった。加えて、事情により大会は今年限りで廃止。傾けてきた情熱も努力も空回りに終わることとなった。ココナラで入手できた数えきれない貴重な教材。そのほとんどが時間不足により、一度も紐解かれないまま手許にある。実務では、Access活用機会はほとんどない。社内システムの補佐的役割として資料作成やメール送付に一役買ってきたのは間違いないが、近々システムもリニューアルし、Accessによる業務支援を要さない体制となる見込み。学習メモ0-6で「Accessは必要ない」と書いたのは酸っぱい葡萄というわけではない。ただ、このまま想い出として葬ってしまうのは、あまりにもったいない。そこで、これまで手に入れた教材をもとに作り上げた学習記録を、ここに公開していきたいと考えた。ここで問題となるのが、成果物の著作権です。AccessというアプリケーションそのものはMicrosoftによる著作物だ

運転免許証（初回グリーン）のように、登録開始日にかかわらず本人の誕生日を基準として(※)、以後の期限満了日を算定するケースがある「登録してから3回目に訪れる誕生日」を基準とする制度（3年後≠3回目）※実際には、運転免許の有効期限は誕生当日でなく誕生日の1か月後　ややこしい部分は割愛この場合、登録日が誕生日の前日以前のケースに注意する必要があるたとえば、ゴジ図書館の一期における利用期間の上限を3年とします7月25日誕生日の人が7月11日に登録開始した場合登録3年後の誕生日を算出しただけの下記式では有効期限が3年後の2029年7月25日となり実際の利用可能期間が3年を超過してしまうせっかく計算式を設定しても、ちょっと残念な仕上がり=DateSerial(Year([登録日])+ 3,Month([誕生日]),Day([誕生日]))その年の誕生日が到来する前に登録を開始するケースへの対策として利用期間は3年を上限とするよう制定する必要がある=DateSerial(Year([登録日]) + IIf(Format([登録日],"mmdd") > Format([誕生日],"mmdd"), 3, 2), Month([誕生日]), Day([誕生日]))※削除された部分+ 3,※追加された部分+ IIf(Format([登録日],"mmdd") > Format([誕生日],"mmdd"), 3, 2), 丸3年の利用権を得ることができるのは、誕生日当日に登録開始した人のみ①誕生日より前に登録した人は登録2年後の誕生日が有効期限②誕生日より後に登録した人は登録3年後の誕生日が

(っσ-σ)و　理数系が苦手でもAccessを使いこなしたいAccessはWordやExcelに比べユーザーを選ぶすごく選ぶ「簡単に作成できます」と販売元のMicrosoftも紹介してるし（ttps://www.microsoft.com/ja-jp/microsoft-365/access）Accessはもっと敷居の低い存在であっていいはず覚えておくと便利な関数（フォーム・クエリ・レポート共通）内、フォーム・レポートはコントロールソースに記入するため頭に＝必須（Excelの数式と同じ）(っσ-σ)و　Count() → 件数Count(*)→すべてのレコードの行数を数える（カウント対象がNull値のない主キーの場合に有効）Count([氏名]) →「氏名」フィールドに記入がある（Null値でない）レコード行数を数える(っσ-σ)و　ラベル付きで表示したいとき="貸出件数：" & Count([ジャンルID]) & "件" → 貸出件数：〇件(っσ-σ)و　Sum()→ 合計例：Sum([金額]) →「金額」フィールド内の数値計(っσ-σ)و　Avg() → 平均例：Avg([納品日数])→「納品日数」フィールド内の平均数値(っσ-σ)و　Max() → 最大, 最高, 最新, 最後, 末尾例：Max([登録日])→「登録日」フィールド内の最大の日付=最終更新日(っσ-σ)و　Min() → 最小, 最低, 最古, 最初, 先頭 例：Min([登録日])→「登録日」フィールド内で最小の日付＝初回登録日(っσ-σ)و　Date() → 本日(っσ-σ)و　Now(

勤務先にてMicrosoft365を使用しており、ちびメカ自作のOutlookメール生成Accessアプリが月1回限定でこっそり活躍中。先日、もともと使用中の事業所マスタ(Accessフォーム)をコピーし、メール取引のない事業所用として別フォームを新たに設け、不要なレコードを削除。ななんと片方のフォームからも当該レコードがきれいに消失していた！肝を冷やした(ﾟдﾟlll)さいわいバックアップをとる習慣をつけているので、大事には至らなかったが、うかつだったと反省した。見た目は別々のフォームでも、同じテーブルを参照する以上、根っこは同じ。うっかり消してしまった場合もデータが保護されるよう、バックアップ用の作業テーブルを作っておくことを思いついた。バックアップ用テーブル運用の準備作業（私用ファイルで検証）① 元テーブルと同じ構成のバックアップ用テーブルを用意②「元のテーブル（配信テーブル）」にて、ユーザーが指定した話数レコードを「保存用テーブル（配信テーブル_バックアップ）」に移籍VBAによるINSERT → DELETE → RequeryPrivate Sub Cmd_削除_Click()　’エラーが発生したら、処理を中断して ErrHandlerラベル位置へジャンプ  On Error GoTo ErrHandler    Dim db As DAO.Database    Set db = CurrentDb         ' 指定したテーブル/フィールドのレコードを抽出し、保存用のバックアップテーブルへコピー開始    db.Execute _        "INSER

選択クエリのデザイングリッドに、アニメの「配信リスト」と「キャラクター名簿」をなんとなく置いて「クエリを実行」しただけで...Accessは「配信リスト：全111レコード」と「名簿：全20レコード」を掛け合わせた2,220行のレコードを表示させてくれる。「リレーションシップ（結合線）」を組んだわけでもなく、そのような命令式を書いたわけでもないのに、なぜなのか不思議。リレーションの話題になると、よく目にする「一対多（いち-たい-た）」テーブル同士において、1件のレコードに複数のレコードが結びつく様子を表現するらしいけど、日本語として不自然だしどちらが「多」なのか毎回こんがらがってしまう。でも、こういう場面に出会うとなんとなく腑に落ちる。配信リスト側が「一(一意)」、そこに群れるキャラ達が「多」で合ってる？人間の目では「これは配信リスト」「これは名簿」って各々のテーブルを独立した存在と理解する。でもAccessは違う。テーブル同士の関係性（ルール）に基づくデータ整理が目的のクエリデザイン画面に、命令をもたない双方が並ぶと、「とりあえず全ての組み合わせ（全パターン）を表示しとけば間違いないだろう！」と判断するのだろう。たまたま双方のテーブルに「Season」という共通フィールド。・「配信リスト」上のSeasonは、そのお話がどのSeasonに紐づくかを表示したもの・「名簿」上のSeasonは、そのキャラクターがどのSeasonから参加し始めたかを表示したものそれぞれ役割が異なる。ためしに「Season」同士をリレーションさせたが「名簿」マスタのSeason定義のあいまいさにより、実態

ココナラを訪れ、初めて取り組んだのが売上管理システム。【設問】売上日の入力後に売上番号(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：売上番号のデー

Accessファイルの正式納品を承ったら、ファイルの格納先として「信頼できる場所」を設定し(Access標準機能)、決められた場所に大切に格納していこうと決めた。 ファイル右クリック→プロパティ「セキュリティ...許可」の認証手順と同等の効果を得られる上に、外部ファイルと連携する機会が多くパス(保存場所)へ依存しやすいAccessの整理整頓にも役立つ。 手順：Accessを開く→ファイル→オプション→MicrosoftAccessトラストセンター→トラストセンターの設定(T)→信頼できる場所→新しい場所の追加(A)→パス参照(B)→OK

買い換えたPCにAccess2024をインストールし、ココナラで購入したAccessをUSB経由で移し替えたところ、新PCでファイルが使えない事態となった。 ココナラで初購入し、出品者から正式納品された段階のAccessファイル。 Accessタイトルバーには、データベースファイルのパス(保存場所)が表示される。使用環境への属性があり、受け取ったファイルをひとたび展開するだけで(Excelのようにデータを上書きしなくても)ファイル情報が更新される。 ココナラ上の取引において、データベース購入者としてはその特性が不安要素だったりする。正式納品を受け売買契約を終了した後、商品に心配な点が仮に見つかったとき、それが納品の時点から既にあったものなのか、こちらの使用状況に起因するものなのかぱっと見わかりにくい。 購入済み商品は購入履歴から遡れる。トークルーム利用中はもちろん、終了後も必要に応じダウンロードできる。 ただ購入者が手にできるのは厳密に言えば「成果物のコピー」であり、ダウンロードされた日時による新規データベースとしてPC上は認識される。 もちろん、中身までが更新されるわけではないからちゃんと状況は遡れるが、出品者へ問い合わせが必要な場合、できれば実際の納期に近い日時に形成された成果物を持参した方が説得力は増すだろう。 日常使い用とは別に、納品受理時点の成果物をちゃっかり保管している。 今回はそれが仇となった形。 Windowsにはセキュリティ対策として、ココナラのようなインターネットからダウンロードされたファイルに対し、Zone.Identifierとかいう出生地情報を紐づける

MicrosoftAccessを用いたデータベース作りの学習記録です

職場の社内システムに、10数年ぶりのリニューアル案が浮上した。これまでは顧客に所定のExcelを提供して情報をとりまとめていただき、顧客から預かったExcelを受付担当(ちびメカ)が社内システムにアップロードし、編集・修正・登録を行い、仕上がったデータを顧客と相互確認し合う業務体制をとってきた。今後は顧客向けポータルサイトが新設され、顧客と同一データベースを共有し合う、いわゆるクライアントサーバー型Webシステムへと移行する。顧客にとっては、自社データ取得や部分編集が自在に行える一方で、これまで当社に一任してきた情報管理を自らの責任において行う必要が生じる。これまでは、データ保管庫の整理や情報出し入れを、私たちに電話ひとつで要請でき、あとは仕上がりを待っていればよかった。その対応窓口が突然、なくなり「明日からはセルフサービスでお願いします」「大丈夫、完璧なシステム用意しておきますから」と、案内を受けるわけだ。計画案の施行にあたり、先ずは現場の声を・・・というわけで、私たちの住む怪獣島(仮名)に開発エンジニアがやってきた。「パソコンに明るくない島々の人たちでも、画面上のボタン操作ひとつで簡単に扱えます」その希望あふれるプレゼン冒頭に、ベテラン社員による直球が水を差す。「あなたたちエンジニアが思う『簡単』は、不慣れなユーザーにとっての『簡単』ではないんですよ」エンジニア(開発者)は「ボタンを数回押すだけの最低限の操作を」と、技巧面での理想を目指す。ユーザー(顧客)にとっては「そのボタン操作を誤ってしまったら」「別の画面に迷い込んでしまったら」とする不安や抵抗感が拭えるわけではない。

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に伝えるための境界線。一

私たち夫婦には子どもがいない。生きていたら今年は何歳と、季節の行事のたびに暦を数える。来る日も来る日も、思い出さない日はない。そんなことばかり考えていても仕方ない。思い切って里親活動に参加してみることに。夫婦して履歴書を片手に、児相や民生委員から数々の審査を受ける。お互いの家族構成、養育環境、学歴、職業、年収、家計、犯罪歴（！）、自宅の坪数、部屋数、間取り、隅々までぜんぶ調べ尽くされた。同じ志を持つ仲間たちと共に研修を受け、児童養護施設で教育実習を体験し、晴れて里親認定をいただけた。児相や里親会への報告書類は基本的に、手書きを前提としている。大切な子どもの成長記録ということで、本来は1ページで充分なところをつい熱くなり、気づけば10ページ近く書きあげてしまい、書いては消し、の繰り返しに初年度で懲りてしまった。とりあえずWordでフォーマットに寄せて原稿を作っていた。このたび、せっかくだからAccessで様式を設計してみようと思い立つ。°˖✧*～＊✧˖°＊°˖✧*～＊✧˖°＊°˖✧*～＊✧˖°＊°˖✧*～＊✧˖°＊°˖✧*～＊✧˖°役所関係だから、日付出力は和暦表示...コントロールソースには日付フィールドを設定、書式タブにggge"年"m"月"d"日"(σ▿σ; 元号対応版も=IIf(Format([年月日], "e")="1", Format([年月日], "ggg") & "元年" & Format([年月日], "m""月""d""日"""), Format([年月日], "ggge""年""m""月""d""日"""))計算式なので、フォームのテキスト(

ココナラ利用はもっぱらMicrosoftAccessを習得するためであり、購入専門である。自宅から通える範囲にOffice関連の教室はあるが、Accessを取扱っていない。オンラインスクールは講師が定めたカリキュラムに従う必要があり、料金は安くない。だが結局は、学校へ通うのとあまり変わらない期間や費用を要してしまった。この選択が正しかったのか、今でもよく分からない。黒歴史：その1某大手購入サイトで詐欺に遭う目標としたステージが今年限りで打ち止めになるとは、夢にも思っていなかった当時の自分。Access習得が1年や2年で達成できるとは到底思えず、長く学習するなら環境を整えておきたいと、PC新調を検討した。Access2021を含むOffice一式が搭載されたPCだった。Ryzen7 + 64GBとスペックも上出来。国内企業が販売する国産PCという安心感もあり、即決した。「インストール不要。直ちに使えます」などと謳っているPCに搭載されたMicrosoft製品は、違法な海賊版である可能性が高い(※)。※販売元がPC製造メーカーである場合を除く。2026年1月時点で、買い切り型MicrosoftAccessが含まれる永続ライセンスとしては、Office Professional 2021が最新版であり、すでに品切れ。後続版のOffice 2024 LTSCは法人に特化されたライセンス。詐欺PCには、Office Professional 2021がすでに含まれていた。新規製品と謳っていたが、販売終了済みライセンスが搭載されているということは、恐らく企業の型落ち。Accessの追加購入

学習メモ「6-1. Access使ってOutlookメール①」の続きです(*σ-σ)VBAコード内に発信者メアドや参考URLが含まれるため、coconalaNGワードに抵触。もちろん架空だし、学習のためのガチネタなのでお許しを...Accessファイルと①で作成した「Mail添付用」フォルダ、各種pdf資料は必ず同一ドライブ上に置く============= メール作成イベントModule　=============「②メール作成」コマンドのイベントプロシージャ'② ①で作成したExcelおよび各資料を顧客あてOutlookメールに添付Private Sub cmd_メール作成_Click()    On Error GoTo ErrHandler    ' 実行パラメータ    Dim AccountIndex As Long: AccountIndex = 1    Dim IntervalMs As Long: IntervalMs = 700    ' 送信フロー制御    Dim ShowConfirm As Boolean: ShowConfirm = True ' 送信前にプレビュー表示する    Dim SaveToDrafts As Boolean: SaveToDrafts = False ' メール下書き自動保存は使わない    ' 添付ON/OFF（メールに添付したいファイルを選択可）    Dim UseAttach1 As Boolean: UseAttach1 = True ' 添付1：Excelを添付1として送付, 送る＝

職場では毎月、社内システムから自動抽出したExcel資料を顧客あてにメールでお届けする必要がある。150社分ほどあるそのExcelは、何故か1ファイルずつフォルダに格納。タイトルもコード表記のみでわかりにくい。Accessを用いて作業１：フォルダに格納されたExcelをひとつひとつ取り出し、「Mail添付用」フォルダに全部を集約作業２：各顧客に失礼なく、かつ間違いなく安全にメールをお届けできるよう、添付ファイルであるExcelに、適切なファイル名をつけていく(｡◕ˇдˇ​◕｡)・・・そもそもシステムがお客さま目線でキチンと機能してくれれば、本来ここまで手を焼かなくていいはずなんですけどね。大金かけてエンジニアとアプリ開発契約して、生じたシステム不備のために、従業員の実働時間も結局、増えちゃって。「Accessを使った業務効率化」って、ほんとうに素晴らしい(だけで片付けていい)ことなのかな。不完全なシステムの後始末に追われ、現場の負荷が増えてしまう状況は、会社にとって健全と言えるのかな。Accessを使った開発も、かなりの集中力や忍耐を要する消耗試合だし、本格的に取り組んでたら本業への影響大。誰もが副業できる余裕を持ち合わせて仕事してるわけじゃないし、そんなに簡単なことじゃない。Accessって時間を贅沢に使える管理職とか、内職しても叱られない勝ち組な社会人のために用意されたんだ、きっと。・・・(｡◕ˇдˇ​◕｡)作業１：システムからダウンロードされた各顧客向けExcelファイルは「事業所コード」別の個別フォルダに格納され、そのままではメール送信できないため、ひとつひとつフォルダ

日付の編集方法A.「プロパティシート」から書式変更する方法テキストボックス(コントロールソース)記入は「=Date()」プロパティシート（F4キー）→「書式」タブ令和○年○月○日 としたい場合： ggge"年"m"月"d"日"R○/m/d としたい場合： ge/m/dB.「テキストボックス(コントロールソース)」へ式を入力する方法令和○年○月○日 としたい場合：=Format(Date(), "ggge年m月d日")R○/m/d としたい場合： =Format(Date(), "ge/m/d")過去問にて「現在の日付を算用数字にて西暦4桁年・0埋めなし月・日で表示しなさい」との設問があった。それに対し私が「"yyyy(ggge)年m月d日"」と記入していたことで、「指示から逸脱している」とのご指摘を受けたことがある。逸脱は理解しています。西暦年月日表示なら、プロパティシート「書式」にて「日付(L)」選択することで対処可能だが、和暦表記についてはAccess標準機能が備わっていない。だからこそ、和暦を問われる可能性は否めないと考え、どの角度からの出題にも対策しておきたいと考えた。限られた準備期間で、ひとつの設問への情報収集のために何往復もできない。1回の練習に、想定し得る回答候補を詰め込んでおきたい切実さがある。結局はご指摘を受け入れ、和暦表示を消して、コントロールソース「=Date()」にて、プロパティシート上で書式をコントロールする方法にあらためた。レポート作成において優先すべき目標は、時短でもあったからだ。その判断が失敗でした。昨年から練習を繰り返し、記憶に刻めていたはずの

1. メインメニュー起動時プロパティシート選択の種類：フォームイベント：読み込み時Private Sub Form_Load()    MsgBox "図書館 貸出管理システムを起動します", vbInformation, "システム起動"End Sub時短コード°˖*✧◝(⁰▿⁰)◜✧*˖°Private Sub Form_Load()    MsgBox "起動します", 64End Sub2. 利用者登録フォームを開く（はい/いいえ確認あり）プロパティシート選択の種類：コマンドボタンイベント：クリック時Private Sub Cmd_利用者登録_Click() If MsgBox("利用者登録を確認しますか？", vbYesNo + vbQuestion) = vbYes Then    DoCmd.OpenForm "利用者登録" End IfEnd Sub時短コード°˖*✧◝(⁰▿⁰)◜✧*˖°Private Sub Cmd_利用者登録_Click() If MsgBox("開きますか？", 36) = 6 Then    DoCmd.OpenForm "利用者登録" End IfEnd Sub3. 貸出入力簿フォームを開く（はい/いいえ確認あり）プロパティシート選択の種類：コマンドボタンイベント：クリック時Private Sub Cmd_貸出入力簿_Click() If MsgBox("貸出入力簿を確認しますか？", vbYesNo + vbQuestion) = vbYes Then    DoCmd.OpenForm "貸出入力簿" End IfEnd Sub時

フォーム上で、貸出本の返却状況をチェックし=IIf(IsNull([返却日]),"未返却","返却済")=IIf(IsNull([返却日]),"要確認","貸出可能")クエリ上で、未返却(貸出中)冊数や返却済冊数を計上し貸出中冊数: Count(IIf(IsNull([返却日]),1,Null))　　⇅返却冊数: Count(IIf(IsNull([返却日]),Null,1))いかにもキチンと管理してます感のゴジ図書館だが、実のところ上記データは各書籍の所蔵(在庫)数には紐付けられてこなかった「本の在庫数に対し、何冊貸出中で何冊返却済か、利用者の貸出依頼を受付できる状況か否か」という、具体的な数の管理を一切おこなえていない人気ジャンルの統計など貸出実績の把握も重要だが、「持ち出し中の在庫品」管理は図書館の運営実務において最も注意を要求されるポイントに違いなく、役目を果たせなくてはデータベースの意味がないなので今回、貸出入力簿の情報を書籍マスタ上の所蔵数に紐付ける在庫計算を実装してみた貸出入力簿上で、貸出可能な数が揃わないと判断された時点で、貸出入力簿へ記入できなくなり、貸出受付をストップする仕組み@σ-σ) 1.貸出入力簿(メインフォーム)「在庫数」テキストボックス=IIf([所蔵数]-DCount("*","貸出トラン","[書籍ＩＤ]=" & [書籍ＩＤ] & " AND [返却日] Is Null")>0,"貸出可","在庫なし")@σ-σ) 2.貸出明細(サブフォーム)「挿入前処理」イベントプロシージャPrivate Sub Form_Before

＊°˖✧ゴジ図書館の貸出入力簿✧˖°＊なるべくラクに簡単に、最低限の機能だけ備えた設計を目指していて、なのにいつもめちゃ時間も気力も消耗してるけど、なんとか形にできた。メインもサブもコンボボックスもすべて揃えた。貸出日の14日後が返却期限:DateAdd("d",14,[貸出日])　〃　の1ヶ月後が返却期限:DateAdd("m",1,[貸出日])図書館を利用できるか利用可否: IIf([利用期限]<[貸出日],"利用不可","利用可能")貸出後の返却がなされているか返却状況：IIf(IsNull([返却日]),"未返却","返却済")本は貸出可能か貸出可否: IIf(IsNull([返却日]), "要確認", "貸出可能")

MicrosoftAccessを用いたデータベース作りの学習記録です既存データ検索フォームと、新規データ入力用フォームを同一ページ上に...メインフォームにコンボボックスを置き、新規入力はサブフォームでおこなわせる構成を組んだ。コンボボックスに謎が多すぎて前に進めず...一覧化して情報を整理。1年前から同じことで同じように悩み続ける自分。Accessは向いていないと実感する瞬間。

クエリの操作を覚え始めた頃から、謎で仕方なかった。デザイングリッドで必要なフィールドをちゃんと選択しているのに、いざクエリを実行すると、選択したはずのないフィールドが勝手についてくる。使用中のAccessファイルのみに適用できる設定方法いろいろ探して、プロパティシート上にある「全フィールド表示」初期設定の「はい」を「いいえ」にすれば、解決することを学習した。このプロパティシートを表示させるには、クエリ画面の背景であるグレー色の部分をあらかじめクリックしておく必要がある。（誤ってテーブルを選択した状態では、この設定項目を確認できない。）デフォルトのクエリをSQLビューで覗くと、SELECT＊とある。*（アスタリスク）はこの場合「全フィールドを引用しておくね」という意味で、それ前提に設計されている以上、ユーザーにはどうしようもない。SQLを自在に扱える上級者であれば、デザイングリッドを使うより自らコーディングして、その前提を覆す方が早いに違いない...か弱い初学者（当人比）にそんな余裕などあるはずもなく。Accessファイル全般に適用できる設定方法Microsoft公式による下記説明に辿り着いた。 ”「すべてのフィールドを出力する」オプションを選択すると、　クエリに Select * ステートメントが追加されます。” ”その後、そのステートメントは、特定のクエリの基になるテーブル　またはクエリ内のすべてのフィールドを取得します。”ttps://support.microsoft.com/ja-jp/access/customize-design-settings-for-objec

たとえば「仕入単価（税抜）」とか「ちびメカ（めんどくさいやつ）」など、（）付きの名称...フィールド名を利用せざるを得ない場合、データベース上では何かと作業の妨げに繋がることがある。設計指示がある場合、テーブルはその通りに作るしかない。でもクエリの段階で、デザイングリッドのフィールド上で別名を与えてあげることができ、エラーの可能性を抑えることができる。「仕入単価（税抜）」をシンプルに「仕入単価」と呼びたい場合クエリビルダーを使って仕入単価:仕入単価（税抜）と式を加えるだけで、当該クエリをレコードソースとしたフォームやレポートでは、（）書きに泣かなくて済む。ラベル名などオモテ向きのネーミングには正式名称を使うよう気を配る必要がある。あらゆるオブジェに細心の注意を払うことを思えば、そのぐらいどうってことない。クエリのフィールド名の欄に「エイリアス:○○○...」と入力したことはこれまで数えきれないけど、計算結果に名前をつけるための作業以外には使う機会がないと思っていた。好きに名付けていい役割があるんだと、初めてそれを知った時は、まさに宇宙まで飛びそうなくらい衝撃を受けた。なんてなんて素晴らしい。

クエリを通してテーブルを学ぶ...選択クエリ作成問題で登場する式・発注数量 ＝ 最大在庫数（計）ｰ（出庫数（計）-入庫数（計））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

MicrosoftAccessを用いたデータベース作りの学習記録です通常、１から始まるオートナンバー型の数字を自由に指定する方法※レコード未入力のテーブルに限る

MicrosoftAccessを用いたデータベース作りの学習記録です動画で使用中のAccessファイルは個人利用を目的に自身で作成したものです複数レコードの直接入力が必要な場合の工夫Enterキー押下後の移動切替：初期設定でヨコ方向（次のフィールドへジャンプ）で動くカーソルはExcelのようにタテ方向（次のレコードへジャンプ）へと切り替え可能※Accessの「フィールド」とは「列」単位、レコードとは「行」単位※設定した入力順はテーブルだけでなく、フォームにも適用される※同じPC内で使用するほかのAccessファイルにも適用されるため注意が必要レコードのコピー（フィールド単位）：Ctrlキーと数字の7を同時に押すとひとつ上のレコードのデータを引用できる（テーブル・フォーム不問）

Accessを勉強し始めたとき、手始めとしてテーブル、そしてクエリ、フォーム、レポート...と順を追った。テーブルの時点だと機能面において、Excelのほうが圧倒的に上と感じる場面に多く出会う。どうにかテーブルを設計しても、ビューを切り替えるたび「フィールド名」の文字がタテに来たりヨコに来たり、なぜこうも分かりにくいのか。基本が大切なのは分かるけど、最初に学ぶオブジェクトがよりによって面白くない。そして「なんかめんどくさいから、直感的に使えるExcel一択」ってなる。そんなAccessには、テーブル上の各フィールドのデータを結合し、ひとつのフィールドを作ってくれる遊び心があることを知った。「クエリ」というオブジェクトを参加させる。クエリといえばいくつかのテーブルをタコ足でつなぐイメージだけど、便利機能としても使えるらしい。【例】：フィールド名が「A」「B」「C」「D」「E」の各データをひとつの「商品名」として表示させたい場合1.ホーム「作成」→「クエリデザイン」選択クエリ画面2.「テーブルの追加」にて結合させたいフィールド名A～Eが存在するテーブルを選び、デザイン画面にぽいっと置く3.デザイングリッドの「フィールド」欄に下記を記入 商品名:[A] & "-" & [B] & "-" & [C] & "-" & [D] & "-" & [E] ※厳密にいえば、：の左は名づけ（エイリアス）機能、　　　　　　　　：の右は結合機能が活用されている4.「！（実行）」をクリック5.エイリアスによって「商品名」フィールドが作成さ

MicrosoftAccessを用いたデータベース作りの学習記録です Access標準機能にてExcelデータをAccessテーブルへインポートできる。ただ、例題のようなカッコつけたフィールド名はエラーが起きやすくその場合はExcelから直接、データをコピペすることも可能と教わった。※貼付には若干コツが必要データインポートにてすべてのテーブルにデータを格納させたあと、リレーションシップおよび参照整合性を設定。※先にリレーションさせてしまうと、テーブルの内容に修正が必要となった際にあわわってなるので、テーブルを完璧に仕上げるまではやらなくていい。テーブル寸法(フィールドサイズ)の相違など、リレーションさせたいもの同士に何かしら矛盾があると、ここで発覚する。クエリ設計に入る前には済ませておくとたぶんスムーズ。（実務ではフィールド連鎖更新までさせておいた方が手間が少ない。）

テーブルとは？：データ（レコード）の保管庫 ココナラのようなプラットフォーム上において、ユーザーが公開プロフィールに書き込んだ情報は会員情報としてマスタテーブルに登録される。多くの場合、会員番号以外はユーザー自身で自由に変更できる。 一方で、会員同士の商取引がメインの場合、日々更新される取引実績を格納するためのデータ保管場所も必要になる。そんなときに用いられるのが、トランザクションテーブル。Excelのようにすべてのデータを横並びに一覧表示させる方法もあるが、登録したすべての会員が商取引に参加するとは限らないため、会員名簿としてのマスタテーブルと活動記録のためのトランザクションテーブルという風に、目的ごとにテーブルを分けて効率よく管理を行うのが一般的。 それぞれのテーブルの共通項として、たとえば会員番号を配備することで、別々のテーブルで変更が行われても、お互いのテーブルに更新内容を紐づけ（リレーション）することが可能。プロフィール情報の変更や新たな商取引の追加にも混乱することなく、必要なときに関連項目を正しく結びつけ確認できる。 これこそAccessの持つリレーショナルの構造であり、得意分野らしい。 逆に言えば、1枚のシートで完結できるデータ整理にはExcelが向いている。 主キー&外部キー：結合された各々のテーブル上で果たす役割の違い 各テーブルの橋渡し役の「会員番号」は、会員名簿としてのマスタテーブル上では他の番号との重複が認められず、唯一無二かつ一度きりの登場。レコード情報を引率する主役であり「主キー」と呼ばれる。 一方、日々の商取引を記録するためのトランザクショ

MicrosoftAccessを用いたデータベース作りの学習記録です

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で重

事業所リストの「作成済チェック」を外せば、その事業所へ再びメールを作成できる翌月になり、ふたたび先頭の事業所からメールを作り始める必要がある場合は「チェック全解除」コマンドを押下すれば、すべてのレコードについたチェックマークを外すことができるチェック解除前チェック解除後「作成済」チェック用フォームのレコードを事業所の登録順に並び替えフォームのプロパティシート並べ替え：[作成順]読み込み時に並べ替えを適用：はい「作成済チェック」イベントプロシージャPrivate Sub 作成済チェック_Click()DoCmd.OpenForm "F_作成チェック"End Sub「チェック全解除」イベントプロシージャOption Compare DatabasePrivate Sub チェック全解除_Click()  Dim strSQL As String    strSQL = "UPDATE T_送信先 SET [作成済] = False"    If Me.FilterOn = True Then        strSQL = strSQL & " WHERE " & Me.Filter    End If  CurrentDb.Execute strSQL, dbFailOnError  Me.RequeryEnd Subチェックを解除すると、無事にメールが作られる

Accessとメール添付資料、Excel格納フォルダを同一ドライブ上に念のため、「送信先編集」画面にてメール送付先を確認コマンド①をクリックすると校正後のExcel格納「Mail添付用」フォルダはAccessが作ってくれる「Mail添付用」フォルダの内容コマンド②をクリックするとメール下書き実行（5社ずつ）コマンド1回クリックにつき、5社ずつメール作成作業継続するか否かを都度、ユーザーに確認「いいえ」を選択すると中止できますメール下書き保存はOutlookデフォルト機能を使用Accessの送付先事業所リストにない顧客のExcelデータについてはメール送付できないため、コマンド①をクリックしても、Excel編集は行われない（対象事業所はユーザーに通知される）メール送付事業所の追加は「送信先編集」で行う「F_送信先編集」フォームに追加したい事業所の情報を記入メニュー画面に戻り、コマンド②をクリック追加事業所の校正済みExcelデータが「Mail添付用」フォルダに追加されたメニュー画面のコマンド②をクリック（実際の操作手順は、①押下後にそのまま②押下）追加したい「株式会社 a☆事業所」のメールが作成される「送信先編集」コマンドのイベントプロシージャExcel感覚で編集しやすいよう、フォームはデータシート形式で表示されるPrivate Sub 送信先編集_Click()DoCmd.OpenForm "F_送信先編集", View:=acFormDSEnd Sub