すべてのカテゴリ

コンボボックスには「表示専用」パターンと「編集/保存」パターンがある目的はⅠ.値集合ソースの参照（レコードの表示）なのか　　　Ⅱ.値集合ソースの代入（レコードの上書き保存）なのか【例】図書館の利用者登録フォーム利用者の初回利用登録日に応じて利用期限を算出する必要があるためクエリに計算式を持たせ、フォームのレコードソースはクエリとしているⅠ. 照合が目的のフォーム     コンボボックスは、値集合ソースの参照（レコードの表示）のみレコードソースはクエリのまま各テキストボックスのコントロールソースに直接、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)

【例】図書館の利用者登録フォーム学習メモ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回だけ表示）　　　ページフッターが用意されている場合、その上段に表示        

運転免許証（初回グリーン）のように、登録開始日にかかわらず本人の誕生日を基準として(※)、以後の期限満了日を算定するケースがある「登録してから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年後の誕生日が

勤務先にて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定義のあいまいさにより、実態

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

日付の編集方法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

(っσ-σ)و　理数系が苦手でも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(

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

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

ココナラを訪れ、初めて取り組んだのが売上管理システム。【設問】売上日の入力後に売上番号(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ファイルのみに適用できる設定方法いろいろ探して、プロパティシート上にある「全フィールド表示」初期設定の「はい」を「いいえ」にすれば、解決することを学習した。このプロパティシートを表示させるには、クエリ画面の背景であるグレー色の部分をあらかじめクリックしておく必要がある。（誤ってテーブルを選択した状態では、この設定項目を確認できない。）デフォルトのクエリを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から直接、データをコピペすることも可能と教わった。※貼付には若干コツが必要データインポートにてすべてのテーブルにデータを格納させたあと、リレーションシップおよび参照整合性を設定。※先にリレーションさせてしまうと、テーブルの内容に修正が必要となった際にあわわってなるので、テーブルを完璧に仕上げるまではやらなくていい。テーブル寸法(フィールドサイズ)の相違など、リレーションさせたいもの同士に何かしら矛盾があると、ここで発覚する。クエリ設計に入る前には済ませておくとたぶんスムーズ。（実務ではフィールド連鎖更新までさせておいた方が手間が少ない。）

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

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

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

Accessを使って実装できる検索機能なら、コンボボックスより断然、あいまい検索が好き検索窓に任意の文字を打ち込んで候補を探す、昔から馴染み深い検索方法だしいかにも「システム」って感じでワクワクするコンボボックスも便利だけど、図書館クラスの膨大な所蔵資料を一覧で追うのは現実的じゃないし素人の見よう見まねでも、せっかくシステム作りに取り組むのであれば、実用的にしないとねPrivate Sub Cmd_検索_Click()    Me.Filter = "書名 Like '*" & Me.書名検索 & "*'"    Me.FilterOn = TrueEnd Subこんな感じで「あいまい検索」を実装してみたものの、単票フォームだと直感的に次作品(書籍)にたどり着けず、手ごたえイマイチ貸出入力フォームを書籍ごとに分類させることを主目的に、フォームを組んでいるのでほかの様式は選べないし「コンボボックス」なら検出した候補を一覧化できるよねさらに、リスト窓から目当ての入力ページに飛べるようにしたらAccessに慣れないユーザーさんでも直感的に操作できて便利かもそんなわけで、あいまい検索（検索窓）とコンボボックス（検索結果）を協働させてみた注意点検索用テキストボックスと別に、コンボボックスを用意する必要があるプロパティシート上でコンボボックス用の書式設定を行っておくあいまい検索（検索窓『書名検索』テキストボックス）「このフォーム(Me)に表示された112冊の書籍データの中から、検索窓に入力された文字(抽出条件)が含まれるデータのみ抽出する」*（アスタリスク）：ワイルドカード

【例】複数の仕入先に宛てて「発注書」レポートを作成仕入先情報のラベル＆テキストボックスを「集合形式」に仕入商品情報のラベル＆テキストボックスを「表形式」にしたいレポートウィザード（レイアウト形式：ブロック）直後レポートフッターは使わないので閉じる書類タイトルや発行日の情報は全ての仕入先に提供するので仕入先の宛先情報と共に、仕入ＩＤヘッダーに移動ドラッグ＆ドロップして仕入先ＩＤヘッダーに情報を移していく仕入先情報が仕入先IDヘッダーに集まった商品情報をレポートの左端に配置する見出しラベルは各仕入先の発注書に一度ずつ掲載されるので仕入先ヘッダーへ商品情報テキストは全レコードの掲載が必要なため、詳細セクションへラベルとテキストを1組ずつ関連付けてコントロールレイアウトを集合形式に順次ならべていく各コントロールの編集は「配置」タブを使うスペースの調整サイズの調整商品情報コントロールレイアウトを「表形式」でセットしておきたいけど「表形式」をクリックすると何故かこんな風に動くとりあえず元に戻して、編集しやすいようコントロール幅を調整「広いコントロールに合わせる」1組（ラベルとコントロール）ずつ「集合形式」を選択すると「表形式」の状態で固定できる1対ずつ集合形式、終わった時点で「表形式」を選択すると表形式が完成各コントロールの幅を最終調整していくレイアウト固定しているとラベルとコントロールを同時に調整できてラク

1.計算式のコントロールに単位（件、冊、個など）加えたい場合は、直接プロパティシート「書式」欄に記入して条件制御できる例：〇件としたい場合、「0\件」「#\件」と記載　　〇冊としたい場合、「0\冊」「#\冊」と記載2. 印刷プレビュー時の改ページを整える方法各グループの途中でページが終わってしまったり、逆に1ページに1つしかグループが出なかったりする場合、グループヘッダーのプロパティを確認①グループごとに新しいページから始めたい場合:レポートデザインでグループヘッダーを選択プロパティシートの「書式」タブ「改ページ」を「カレントセクションの前」に設定②同一グループのデータがページの途中で切れないようにしたい場合:デザイン画面下部の「グループ化、並べ替え、集計」パネルで「グループ化」「その他」をクリックバー内で「1ページにグループをまとめる」の項目を探し、クリックこれで、グループの途中で改ページが入るのを防げる学習メモ4-2.で、レポートフッターはページフッターの上に来るようなことを書いたが、やはりレポートフッターが最下段だったAccess2019の参考書では、上記のように書いてあったみたいだけど...レポートヘッダーやフッターは通常、一番外側に位置するものではないかなと私は思う...ゴジ図書館のシステムは、これでひと段落あとは、メニューフォームかな

ゴジ図書館の貸出入力簿への記入済データが反映されるよう作ってみましたグラフ機能はAccess2024を使用しています最近のAccessのグラフ機能は、モダンチャートという名称の新機能が搭載されておりだいぶ使いやすくなったが、凡例を設定すると微妙な仕上がりになるのは相変わらずみたいとりあえず、こう押さえておけば何とかなるかなタテ：軸（項目）・・・分類テーマ（今回はジャンル名）ヨコ：値（Y軸）・・・グラフ値の単位（今回は冊数）図書館で本を借りるときは（購入とは違い）同じ日に同じ人が同じ本を複数冊、利用するパターンは想定しにくい1レコードをそのまま貸出1件と想定し、クエリ上でカウントさせたものをレコードソースとしている貸出日1レコードを1冊数とみなす考え方が正解かは分からないでも、図書館管理システムは、Accessの仕組みに適したテーマのように思うグラフといってもレポートであり、メニュー画面から直接プレビュー表示させることが可能だけど少しシステムらしくなるようグラフ出力用フォーム「印刷画面」を経由させユーザーに出力対象期間を選ばせてみる「印刷画面」フォームを開くと、操作時点の当月が自動的に「終了年月」として反映されさらに当月の11か月前を「開始年月」としてカレンダー指定することで今月から遡って1年間を呼び出すことができる仕掛けを施す直接、手入力してももちろんいいけど「おっフォームひらいたら、もう年月が入ってる☆」って方が、なんだかワクワク感があるし「こういうの作りたい」って憧れみたいなものが学習のモチベーションにも繋がっていくプロシージャへの命令式には、学習メモ0-5.へ記入したFo

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

【例題】作成したメインフォーム『仕入先別発注対象商品』に、サブフォーム『入出庫サブフォーム』を組み込みなさい。サブフォーム内に表示されるテーブル『入出庫トラン』のレコードが、メインフォーム側で表示中の[商品ＩＤ]でフィルタリングされていること。＊＊＊＊＊＊＊＊＊＊＊メインとサブのリンク動作確認のためにレコード移動を行ったが、Access標準機能の移動ボタンが使いづらいため、設問にはないボタンを配備。ユーザー向けメッセージを追加したが、上書き保存を押しても実装内容が反映されていないときがある。

【例題】以下仕様に基づき、サブフォーム『入出庫サブフォーム』を作成しなさい。(1) フォーム名は『入出庫サブフォーム』とすること。(2) レコードソースはテーブル『入出庫トラン』とすること。(3) フォームの種類は、表形式にすること。(4) テーブル『入出庫トラン』の[商品ＩＤ] (注)を除く各フィールド([入出庫ＩＤ][入出庫日][入庫数][出庫数][備考])が表示されること。(注) [商品ＩＤ]はメインフォーム側に配置されるため表示不要。(5) テーブル『入出庫トラン』の[商品ＩＤ] [入出庫ＩＤ] (注)を除く各フィールド([入出庫日][入庫数][出庫数][備考])が編集可能であること。(注) [商品ＩＤ] はメインフォーム側に配置されるため編集不要。       [入出庫ＩＤ]は「オートナンバー型」のため編集不要。(6) 下記方法で[理論在庫数]を算出し、テキストボックスに表示すること。     算出においては、適切な集計関数を用いること。●下記（ア）から（イ）を減算した値（ア）サブフォーム内レコードの「入庫数」の合計値（イ）サブフォーム内レコードの「出庫数」の合計値(7) [入出庫ＩＤ]、及び上記(6)のテキストボックスにカーソルが移動、編集できないようにすること。(8) [入出庫ＩＤ]の昇順で、並び替えを設定すること。(9) 各フィールドの文字がすべて表示されるように、サイズを調整すること。(10) 新規入力ができること。

Accessのクエリには、Excelのように列(フィールド)ごとにデータを並び替え(昇順/降順)できる機能がある。デザイングリッドを使ってクエリを設計する場合、Accessは初めに追加されたフィールド（画面左のフィールド）の設定を優先する習性をもつ。並び順を優先させたいフィールドを先頭におけば問題ないのだけれど、一覧の形式上、そうしたくないケースだってある。そんなときは通常のフィールド設計に加え、デザイングリッド上に用意された「フィールド非表示」機能を用いて、水面下で順序操作を行う。並び順を優先させたいフィールドの後ろ（右側）に、次点フィールドを非表示で再掲し、Accessに「左にあるフィールドの設定を優先してね」と、むりやり記憶させる。例：「住民税決定通知書」管理（※eLTAX未運用を前提）特別徴収(給与天引き)対象者へ宛てた、令和8年度(2026年6月～2027年5月)住民税に関する通知。事業所は各自治体から届けられる通知を確認し従業員に配布する役目を負う。日頃は「社員コード」順に管理される職員台帳。この時期だけ、居住地の自治体ごとに情報を整理する必要が生じる。給与データシートの出力は「社員コード」順。全体の並びは替えたくない。居住地コードをグループ化し、その中で「社員コード」順に情報をならべておけば、通知票の配布チェックもスムーズ。先ずはリスト化したい項目(フィールド)の順に、デザイングリッドにフィールドを追加していく。「社員コード」が先に追加され、「居住地コード」は最後のほう。このとき、「社員コード」の並び替えはまだおこなわない。一方で、優先させたい「居住地コード」の並

リンクテーブルへのチャレンジから始まって、何とか形にできたでも、バカなので手順をすぐに忘れてしまいそうココナラさんのスペースを備忘録代わりに使って申し訳ない

MicrosoftAccessを用いたデータベース作りの学習記録ですデータ改ざんなどの不正対策としてはありなのかもだけど、欠番によって生じる生活感が実務上は微妙。利用を極力控えていたが、オートナンバーのフィールドごといったん削除し、そのあと復活させることで、実レコード数に応じたオートナンバーの再発行ができなくはないと知る。注意点：・ビュー切替を伴う作業であり、編集内容の保存を余儀なくされるため、必ず開始前に元テーブルのバックアップをとっておくこと・デザインビューにてオートナンバーのフィールドを復活させた後、再び主キーを設定し直す際のマウスポインターとしては、オートナンバーのフィールド全体を選択すること※「フィールド名」のみ選択でも主キーは設定できるが、デザインビューからデータシートビューに切り替えて確認してみると、レコードの先頭に復元されるべきオートナンバーのフィールドが末尾(画面右端)にくっついてたりする

ExcelデータをAccessにインポートできることは分かったけど、Excelデータが大量かつ頻繁に更新される場合、都度Excelを読み込むのは非効率。ExcelはExcelで自由に動いてもらい、Accessがそれを参照できれば絶対ラク！参考書で調べてみたら、そういう方法もあるらしい。リンクテーブル（てか、いつものインポート画面にしっかり用意されてた）リンクテーブルのもととなるExcel下地作りExcelの情報をそのまま取り込むとデータ量が膨大となるため、取引種類ごとに1レコードずつ反映できるよう、データ整理をAIに手伝ってもらった。（職場認定AI。AIは学習能力があるがゆえ契約外AIの職場利用は情報漏えいの懸念から禁じられている）リンクテーブルで出来ること・Excelを開く代わりに、Access(リンクテーブル)からいつでも一覧を照合できる。・Excelを編集すれば、Access(リンクテーブル)も自動で更新される。・取引先から提供されるExcelデータが変更、追加、キャンセルされた場合、その情報をリンク用Excelに追加すればAccess(リンクテーブル)にも反映できる。・ExcelのデータをAccessのフォームやレポートに適した形にアレンジできる。たとえばセルごとに独立した情報を、Accessのクエリ機能によりひとつの名称として形成できる。（Access学習メモ1-5記録）リンクテーブルで出来ないこと・テーブルデザイン編集はできない（デザインビューへの切替はできない）。・フィールドプロパティ、テーブルプロパティはリンク時にAccessが自動設定しており、手動による変更は

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

4時起きなので、ほんとうは横になりたかったけど採点のあいだ、ぼーっと待っていても仕方ないので持参したノートPCで思い出せる限り、課題を再現したテーブルは今回、4つあったたしかこんな作りだった貸出テーブルには最初から「返却予定日」が反映された前提自作のゴジ図書館システムより、ずいぶんアッサリした仕様の課題だったこれまでブログに書き出した内容をすべて出し切れたなら、完璧に近いものを完成させられたはずだったでも実際には、解けなかった結果を残せなかったのなら、何もしなかったことと同じだと、自分に対しては思うそして、挽回のチャンスはもう訪れない今まで何をしてきたんだろう【問】「貸出日」＞「返却予定日」の場合は登録できないようにしエラーメッセージを表示させなさいテーブルプロパティ(※フィールドプロパティではない)入力規則：([返却予定日]>=[貸出日]) Null対策を行うなら([返却予定日]>=[貸出日]) Or ([返却予定日] Is Null)但し今回は該当しないエラーメッセージ：返却予定日を過ぎているので貸出できません複雑なコードを組まなくても、ボタンを置かなくても、プロパティシートへの記入だけで実装できるたったこれだけのことが出来なかった

AIに当ブログを読ませてみたらひとこと多い(笑)得意な人になりたかったなっ٩(⁰▿⁰)و昨年6月、MicrosoftAccessを学習するためにココナラへ入会した。どうしても7月中旬までに、売上管理システムをひと通り作れるようになる必要があった。最初は時給の6倍ぐらい支払って、1時間レッスンを受けた。ビデオチャットの接続に時間を要し、所要時間の中でAccessを始めた目的など説明する必要があり、さらに終了時刻を5分ばかり早めに切り上げることになったから、実際のレッスンは正味45～50分程度だったかも知れない。心配した夫がこっそり傍らで操作をサポートしてくれたけど、それでもあっという間に過ぎてしまった。この調子では予算がいくらあっても足らない。だから、売上管理システム販売を依頼することにした。既製品から不要な機能を少し取り外した内容にてご提供いただいた。それをデザインビューで確認しながら、作り方をおぼえようとした。でもAccessの動きが独特で、分からないことがどんどん浮上、時間ばかり過ぎていく。7月に入った。今度は時給の2.5倍ほどの値段で1ヶ月レッスンを受けた。目標の期日まで、圧倒的に時間が足りない。料金は格安。正直、期待しない＆あきらめの気持ちが強かった。開始されたサービスに驚いた。Access操作手順をまとめた動画の束だった。「ここまでしてくれるんだ」と感激した。私が現在、学習メモとして動画を利用する背景には、その影響が確実にある。トークルームへメッセージが届いた際の通知は、1日に複数回だと「ココナラ2」「ココナラ3」...と、末尾に数字が表示された。それが連日のように、

誰も教えてくれなかった...1年かけて勉強してきたのかけた費用は10万円ほど（＋2年ローンで購入したNECのLAVIEフェアリーパープルちゃん30万円弱 笑）「フォームはひとつのテーブルからしか作れない」という事実に今さらがく然そんな大切なことなぜ今まで誰からも明かされることがなかったのだろう世界の常識だから？知らない私がバカなんだろうな情けない限り＊°˖✧˖ゴジ図書館　利用者登録フォーム作り˖✧˖°＊3-9.でリレーションシップによる衝突は避けられるようになったが、新規情報を登録しようとすると同じエラーメッセージが出る。親子リンクを解除しても、メイン(利用者検索用)とサブ(新規登録用)の参照先(レコードソース)が同じクエリであることから、結局は競合してしまうのだろう。そこで、サブ(新規登録用)のレコードソースをクエリからマスタテーブルへ切り替えてみたが、今度は「レコードの追加や編集ができないから、双方を親子リンクさせてくれ」と苦情が出る。また、1フォーム1テーブルの課題がある。～修正(੭ु;・∀・)੭ु⁾⁾～1.サブフォームの各コントロールをメインフォームに集約し、サブを撤去2.クエリで結合させていた「利用者マスタ」と「図書利用券マスタ」を「利用者マスタ」に一本化し、メインのレコードソースとする3.コンボボックスの値集合ソースをテーブルに変更4.テーブル改編による列数変更に伴い、コンボボックス(書式)の列数および列幅の見直し5.テーブル改編による列数変更に伴い、コンボボックス(データ)の連結列を[1]に戻す6.テーブル改編による列数変更に伴い、各コントロールのcolumn関数

メイン/サブフォームを繋ぎとめてくれていた「利用者ID」親子リンク学習メモ3-8でサブフォームが機能しなくなった理由は、Accessの解釈と私の意図が相反していたことが原因だった。学習メモ3-8.で実装済の構成利用者登録（親）⇔ 利用者IDでリンク ⇔SF_新規登録（子） Accessの解釈（検索対象者　＝　登録対象者）メインフォームのコンボボックス上で利用者を表示↓その利用者に属するデータをサブフォームへ登録私が目指していたもの（検索対象者　≠　登録対象者）「新規利用者がすでに登録されていないか」を確認するためにメインフォームのコンボボックス上で利用者を表示 ↓登録がないと判明した場合はサブフォーム上で新規利用者として登録・・・だから、メインのコンボボックスで利用者を選択しつつサブのテキストボックスに(メイン不在の)新規利用者を登録した瞬間に親子リンクの思想とぶつかってしまい、Accessがフリーズした。そもそもメイン/サブとして各フォームをリレーションさせる目的は、メインに関係する詳細情報をサブに反映させることにある。リンクさせるフィールドには「1対多」の関係性が成立していることが前提。設計の意図：「新規利用者がすでに登録されていないか」を確認するためにメインのコンボボックス上で利用者を表示し、登録がなければサブフォーム上で新規利用者として登録その設計思想をAccessに伝えるためには、①リンク親フィールド・リンク子フィールドを消す②①の代わりにサブフォームへ飛ぶためのボタン「新規登録」をメインに新設Private Sub 新規登録_Click()DoCmd.OpenFor

【例題】メインフォームにてテーブル『商品マスタ』の商品情報を入力し、サブフォームにてテーブル『入出庫トラン』の商品ごとの入出庫情報を入力するフォームを作成しなさい。メインフォーム『入出庫情報登録』の作成以下仕様に基づき、メインフォーム『入出庫情報登録』を作成しなさい。(1) フォーム名は『入出庫情報登録』とすること。(2) レコードソースは下記①～⑦による選択クエリ『商品情報一覧』とする。　① [商品ＩＤ]　② [商品名]　③ [仕入先ＩＤ]　④ [仕入先名]　⑤ [仕入単価（税抜）]　⑥ [最大在庫数]　⑦ [最小在庫数](3) フォームの種類は、単票形式にすること。(4) テーブル『商品マスタ』の全フィールドの表示・編集が可能であること。(5) [仕入先ＩＤ]については、テーブル『仕入先マスタ』に登録されている[仕入先ＩＤ]の一覧の中から、コンボボックスで選択できること。(6) 上記(5)のコンボボックスで[仕入先ＩＤ]を選択すると、対応した [仕入先名]がテキストボックスに表示されること。(7) 上記(6)のテキストボックスに、カーソルが移動・編集できないようにすること。(8) 各フィールドの文字がすべて表示されるように、サイズを調整すること。(9) 新規入力ができること。

選択クエリのデザイングリッド「フィールド」にReplace関数を入力→「昇順」で並び替えReplace関数クエリ実行後のフィールド名:Replace([Replace対象となるフィールド名],Replace前の文字列,Replace後の文字列)※Replace関数の基本構造は　Replace(文字列,検索文字列,置換文字列)Replace関数「:」の左に来るフィールド名は、クエリ実行後に設定されるフィールド名となる。クエリ実行前の元フィールド名と同じにはできない（循環参照）ので注意。元フィールド名としてテーブル設定済の名称は、Replace()内の「文字列」すなわち「Replace対象となるフィールド名」の位置へ[]で囲んで記入。Replace前の文字列として、省略したい文字列を""で囲んで記入。フリガナから一定の文字を省くための関数なので、Replace後の文字列は""のみとする。この場合の""のことは「長さ0の文字列」と表現される。例１：キャクメイ列のカブシキガイシャ文字列を除いた顧客フリガナを、「フリガナ」フィールドとして誕生させるフリガナ:Replace([コキャクメイ],"カブシキガイシャ","")例２：「株式会社」だけでなく「有限会社」「合同会社」「協同組合」など複数名称を省略対象とするフリガナ: Replace(Replace(Replace(Replace([コキャクメイ],"カブシキガイシャ",""),"ユウゲンガイシャ",""),"ゴウドウガイシャ",""),"キョウドウクミアイ","")例２では、省略したい名称の数だけReplace()で包む動作を繰り返す

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

職場では毎月、社内システムから自動抽出したExcel資料を顧客あてにメールでお届けする必要がある。150社分ほどあるそのExcelは、何故か1ファイルずつフォルダに格納。タイトルもコード表記のみでわかりにくい。Accessを用いて作業１：フォルダに格納されたExcelをひとつひとつ取り出し、「Mail添付用」フォルダに全部を集約作業２：各顧客に失礼なく、かつ間違いなく安全にメールをお届けできるよう、添付ファイルであるExcelに、適切なファイル名をつけていく・・・そもそもエンジニアが手がけたシステムがお客さま目線でキチンと機能してくれれば、本来ここまで手を焼かなくていいはずなんですけどね。大金かけて専門家とアプリ開発契約して、そのシステム不備のために従業員の実働時間も結局、増えちゃって。「Accessを使った業務効率化」って、ほんとうに素晴らしいことなのかな。不完全なシステムの後始末に追われ、現場の負荷が増えてしまう状況は、会社にとって健全と言えるのかな。作業１：システムからダウンロードされた各顧客向けExcelファイルは「事業所コード」別の個別フォルダに格納され、そのままではメール送信できないため、ひとつひとつフォルダから取り出して、ひとつのフォルダ内にまとめて保管作業2：システムデフォルトのExcelタイトルが「事業所コード」のみの表記であり、一見どの顧客に宛てたExcelかわかりにくく誤送信の恐れがあるため、Accessのマスタテーブルを用いて、顧客の「コード」と「名称」を紐づけて、正式な事業所名がついた適切なファイル名に変換するExcelでリスト化したものをAccess