すべてのブログから「#データベース」タグの検索結果

データベースにおいてはマスタ管理がとても重要です。 都道府県マスタなどが分かり易いと思いますが、データ入力の候補群をマスタと呼びます。 データ入力の度に「東京都」「大阪府」とキーボードを打つのは面倒ですが、それ以上に問題となるのは誤入力の発生を許してしまうことです。 データの意味としては「東京」も「東京都」も同じですが、集計の条件として「東京都」を指定した場合には「東京」は含まれません。 「自民党」と入力する人がいて「自由民主党」と入力する人もいたのでは正確な集計が出来なくなります。 そのため入力候補として決まったデータ群はマスタ化しておき、そのリストから入力する仕組みを作るのが大切です。 リストから入力するのは便利ですが、ポイントは誤った情報が入力できないという点です。 取引先の社員名や顧客なども当然マスタ化する必要があります。 顧客名簿はきちんと管理されているのに、書籍を郵送する際の宛名ラベルの作成を間違えたということが無いように、宛名ラベル印刷と顧客管理は連動していることも重要です。 数量の項目は数字しか入力できない。 生年月日の空欄は許可しない。 年齢は生年月日から計算できるので入力しない。 などの条件を指定することで正確なデータしか入力できなくなります。 入力し易くなる上に、データの精度が上がる。 これこそがマスタ管理のメリットであり、データベース処理の特徴でもあります。 自分の仕事をよく見ればマスタ管理できそうなものは沢山あると思います。 即ちデータベース化した方が良いということです。 データベース化すれば発生した取引を１件ずつ入力する仕組みができあがるので、正確な

以前経理を担当していた時の話です。 医療機関では医薬品や医療機器をはじめ清掃や設備、事務用品に至るまで非常に多くの取引先があります。 月末締の請求書が届いたら翌月に支払いをするのですが、取引先によって２か月後支払いとか３か月後支払いなどと個別に支払いサイトを設けていました。 当時の上司は、数千万円の医薬品の支払いを先延ばすことで金利負担だけでも大分得しているんだと豪語していましたが、請求月と支払月が取引先ごとに異なるため管理が大変でした。 同じ月の請求書を２か月続けて振り込んだりして、期末の残高確認が合わず決算前に慌てたこともありました。 これを前任者から引き継いだExcelで処理していたのですが、シートには５０社近い取引先が縦に並べてあり、延々と右に向かって請求月と金額が足されていくという代物で、金額を間違えたり、振込先を間違えたり、毎月のように後処理に追われていました。 今思えば多額の現金を扱うにも関わらず、何ともいい加減な仕事をしていたのかとは思いますが当時はそれが精一杯で、一般企業であれば到底許されなかったでしょう。 他にも多くの業務を担当しており、限られた時間の中で仕事の精度を上げる必要に迫られ追い詰められていました。もっと効率的に処理が出来ないか日々考えていました。 当時のPCにはOffice２００３がインストールされており、その中にAccess２００３が入っていました。データベースソフトがどのような働きをするのかは分からず、どう使用するのかも全く知らない状態でしたが、なんとか現状を打破出来る術は無いかと試行錯誤し、何となく雰囲気を掴むことが出来ました。 そして取引

YouTubeでも紹介しています。　是非ご覧くださいBIGデータを、上手に利用するには、データベースの作成が必須です。 これは、PowerQuery　や、Excelがいかに優れていても、ACCESSには勝てません。 その説明をしたいと思います。 データベースを作成するには？ こんにちは。伊川です。 ACCESSって、わからない、難しい、そんなことを、よく耳にします。 もっとも、ACCESSではなく、お金があるなら、他のデータベースを利用すればいいと思います。 Excelや、PowerQueryは、整形されたデータベースを前提にしなければなりません。 例えば、PowerQueryを利用すると、文字の分割等は、Excelよりもはるかにカンタンです。 しかし、それは、データベースを設計するときに、分割をしておけばいいだけの話です。 伊川直助⇒これは、絶対にやってはいけません。 伊川　直助⇒これは、まだマシです。しかし、スペースが全角なのか、半角なのかで、SQL文が変わってきますし、入力する人が、半角、全角は気にしないと思います。 このような場合に、PowerQueryなどを利用すると、楽になるというだけです。 伊川 直助 このように、姓と名は、絶対に分けるべきです。 伊川　直助を、分解するのは難しいですが、合体させるのはカンタンだからです。 このようなことを念頭において、データベースを作成すれば、その時点で、月の処理時間は、10時間は変わります。 余談ですが、私は、競馬はで、市販されている、4つの指数と、血統と、異常オッズ、その他の指数、約12種類を、毎週ACCSSに入力しています。

定期的にブログを更新しようとは考えているのですが、ありがたいことにシステム構築の依頼も増えて、なかなか記事が書けていませんでした。 うららかな春の日、久しぶりに窓を開けて爽やかな風とともに音楽など聴きながら少し時間ができたので子供の頃の話を書いてみようと思います。私が小学校高学年の頃に家庭用パソコンが普及し始めました。 普及とは言っても電気屋さんに置いてあるという意味で、非常に高価な代物でどこの家にでもあるというものではありません。当時、友達に誘われて近所のPCショップに入り浸っていました。そのお店はNECの販売店で主に企業や学校にパソコンを納入するショールームの様な所でした。 お店の人達とも仲良くなり、とても居心地の良い場所でした。 当時まだWindowsなどは無く、画面も白黒がメインでした。 今時の人には信じられないと思いますが、漢字すら表示することは出来ず、増設スロットに漢字ROMという部品を差し込んで漢字を表示するのですが、その部品が５万円近くするのです。 最上位機種になると本体３０万円、モニタ２０万円、外付けディスク２０万円、ドットプリンタ２０万円、フルセットで１００万円近くしました。 私の月の小遣いが１０００円程度の頃です。そんな時代ですから、自由にパソコンを触れる環境というのは非常に魅力的でした。 では、パソコンで何をするかと言えば、主にはゲームなのですが既製品のゲームソフトは非常に高額なためとても小中学生に購入できるレベルではありません。 ではどうするか？というと、パソコン雑誌にプログラムが紹介してあるのでそれを自分たちで入力するのです。 機種別にプログラム言語

本日も、自分用に作成している献立・レシピ管理アプリの続きを進めました。今回は、レシピ追加フォームから送信した内容をMySQLへ保存する処理に挑戦しました。データベースを作成MAMPのphpMyAdminを使って、my_recipeというデータベースを作成しました。その中にrecipesテーブルを作り、料理名カテゴリー元サイト名URL画像材料メモ登録日時などを保存できるようにしました。PHPからMySQLへ接続db.phpを作成し、PHPからMySQLへ接続できるようにしました。その後、save.phpでフォームから送信された内容を受け取り、MySQLへ保存する処理を追加。実際にレシピを登録して、phpMyAdminを確認すると、入力した内容がきちんとデータベースに保存されていました。画像も保存できるように料理写真については、画像そのものをMySQLへ保存するのではなく、画像ファイル → uploadsフォルダへ保存画像のパス → MySQLへ保存という形にしました。実際に写真付きでレシピを登録し、uploadsフォルダへ画像が保存されるところまで確認できました。次回やりたいこと次回は、同じファイル名の画像が上書きされないように、画像名を自動で変更する処理を追加したいと思います。その後は、現在HTMLに直接書いているレシピ一覧を、MySQLに登録したレシピから自動表示する仕組みへ変更していく予定です。少しずつですが、「入力したデータを保存して使う」というWebアプリらしい動きができるようになってきました。

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

Accessで介護支援記録システムを作った理由－9 私が介護支援記録管理システムの開発において重視したことは、パソコン操作に慣れていない職員でも、簡単で分かりやすく効率的にデータを入力できるということでした。 ポイントとして、Accessアプリでの入力作業は、よくあるスマートフォンアプリのように、いくつもの画面を遷移しながら行うのではなく、広い画面を使い、一画面で入力が完結できるようにしました。 例えば、メインの介護支援記録の入力では、日付と利用者を紐づけたコンテナ情報の中に、時系列的に一つひとつの記録を追記する形で行うようにしています。これは既成の介護業務支援システムに倣ったものです。コンテナ情報、利用者データ、介護支援記録などは複数のテーブルに保管されていますが、リレーションシップにより紐付けられ全体情報は一画面の中に表示されます。 これを具体化する入力フォームは、テーブルごとのいくつかのフォームを親子、兄弟のように組み合わせます。そうすることにより、誰でもぱっと見、わかりやすいインターフェイスが出来上がるという仕掛けです。 また、システムの進行操作は画面上に配置されたボタンをクリックして行うため迷いがなく、さらに介護内容や担当者等の定型的な入力については、ドロップダウンリストを使うことで効率化を図っています。 しかし、完成に至るまでの間、フォームの作成には相当の手間がかかってしまいます。 ひとつのフォームを一から作ろうとすると面倒なので、いったんAccessに備えられたウィザード機能を使うのですが、この出来上がりが凄くショボい！あまりにも最初のデザインが酷いので、どうして

データベースの元になるCSVファイルから情報をまとめてデータベースを作成する際に注意点がありまわりのす。利用者情報の登録情報に抜けがないことはもちろんですが、利用者名を削除したり、上書きしてしまうと全体数の把握が困難となり、データベース化が困難となってしまいます。こんな時には、利用者名を記載する上で一定のルールを作成し、入力する職員が共通認識の上でルールに従ってもらう必要があります。そのためには、データベース化する利点が、ルールを守る手間を上回る必要があります。ここでもプレゼンテーションが必要になり、9割の人が納得する利点を提示しないといけないと考えます。しかし、１割くらいの職員は、どうしても反対されますので…。しかし、データベース化した後にエラーばかりになると賛成してくれた職員に迷惑をかけます。やるなら、徹底的にデータベース化が大事です。

パソコンの購入を許されてからは夢のような毎日でした。 おおまかな構成は決めていたのですが、予算内で最大の満足を得るため色々な会社のパンフレットを集めては、細かい性能を比べて夢を膨らませる日々です。 選択したのは当時おそらくもっともメジャーなＮＥＣのＰＣ－８００１というマシンでした。それにカラーディスプレイとデータを読み書きするカセットレコーダーをセットで買って貰いました。 (画像はWeb上のものです）テレビで「アルト４７万円」なんていうコピーがコマーシャルで流れていた頃ですから、軽自動車１台に近い金額だったのだと思います。 今はもう亡くなった祖母が大きな資金援助をしてくれたことを後で知り、今でもずっと感謝の気持ちを忘れていません。今のPCスキルが身に付いたのは祖母のおかげだと思っています。いつもニコニコして笑顔を絶やさない小柄な優しい祖母でした。私も人の親となり、子供がチャレンジしたいことは出来る限り支援してやりたいという気持ちを持たせてもくれました。 さて、家ではパソコンを触る時間がいくらでもあります。最初の頃はゲームに没頭していましたが、やがてプログラムを作る面白さを知ることになります。当時のパソコンにはBASICというプログラミング言語が標準で搭載されており、NECのパソコンにはMicroSoftのBASICが乗っかっていました。もちろんWindowsが登場する遥か前の話です。 BASICというプログラム言語は非常に分かり易くできていて、少しなれてくると色々なことができるようになってきます。ただし、処理が非常に遅いので上級者になると機械言語という難しい領域に入っていきます

私は医療機関で事務系の仕事をしています。 一時は収まっていたコロナ感染症患者の入院が再び始まりました。今回から少し複雑な統計をとる必要が発生したため、Accessで台帳作成に取り組んでいました。 大まかな構築は済んだのですが、レムデシビル（薬品名）を投与した患者を毎日カウントしていく必要がありました。電子カルテの集計から引っ張っても良いのですが、毎日集計処理をかけて台帳に入力していくのも手間がかかります。そこで薬剤部に相談してＡｃｃｅｓｓの台帳を共有し、レムデシビルを投与した患者にチェック☑をつけてもらうよう依頼しました。薬剤部では薬を準備する段階で患者情報を持っているため簡単な話でした。 このことについては快く承諾してもらえたのですが、逆に相談を受けることになりました。 Excelで一覧表作成聞けば、薬剤部では投与した患者のID、氏名、生年月日、性別、投与開始日等々をノートに書き込み、更にそれを最後にExcelに入力してメールで報告する業務があり、その手書き作業とExcel入力が非常に業務負担になっているというのです。 私の手元にはコロナ入院患者の一覧はあるが、レムデシビルを投与した患者を絞り込むのに手間がかかっている。 薬剤部ではレムデシビルを投与した患者の一覧があり、患者属性を手書きで書き加えてExcelへ入力している。 このように仕事が重複していることが分かりました。 そこで薬剤部のPC端末からAccess台帳を操作できるようにして、レムデシビル投与患者リストに属性を付加してExcelにエクスポートできるようにしました。 お互いが小一時間かけて作業していた仕事が、５分程

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

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

本日も、自分用に作成している献立・レシピ管理アプリの続きを進めました。今回は、一覧画面のレシピカードをクリックしたあとに表示するレシピ詳細ページの作成をスタートしました。レシピIDを使って1件だけ取得一覧画面から詳細ページへ移動するときに、detail.php?id=10のように、レシピごとのIDをURLで渡す形にしています。detail.phpでは、そのIDを受け取り、MySQLのrecipesテーブルから該当するレシピ1件だけ取得する処理を追加しました。今回は確認のためにvar_dump()を使って、料理名・カテゴリー・元サイト名・URL・画像・材料・メモなどが取得できているかチェック。無事に、選択したレシピのデータを取得できました。次回やりたいこと次回は、取得したデータをそのまま表示するのではなく、料理写真カテゴリー料理名元サイト名元レシピURL材料メモを見やすく配置して、レシピ詳細ページのデザインを作っていく予定です。少しずつですが、一覧から詳細へ進めるようになり、よりアプリらしい形になってきました。

本日も、自分用に作成している献立・レシピ管理アプリの続きを進めました。今回は、MySQLに保存してあるレシピデータを、index.php の一覧画面に自動表示する処理に挑戦しました。MySQLからレシピを取得まず、index.php からデータベースに接続し、recipes テーブルに保存されているレシピを取得しました。最初は取得できているか確認するために、PHPで配列の中身を表示してチェック。料理名・カテゴリー・材料・画像パスなどがきちんと取得できていることを確認できました。レシピカードを自動表示これまでは、HTMLにレシピカードを直接書いていましたが、今回はforeachを使って、データベースに登録されているレシピを1件ずつ自動表示できるようにしました。これによって、レシピ追加画面から登録↓MySQLへ保存↓一覧画面へ自動表示という流れがつながりました。カテゴリー表示も調整データベースには、mainsoupriceなどの値を保存していますが、一覧画面では、主菜汁物ご飯・麺のように、日本語で表示できるように調整しました。カテゴリーの絞り込み機能に使う値は英語のまま残して、見た目だけ日本語にしています。レシピカードから詳細画面へさらに、レシピカードをクリックすると、そのレシピの詳細ページへ移動できるようにする準備も進めました。カード全体をリンクにしたことで、クリックするとレシピIDを付けた詳細ページへ移動できる形にしています。次回やりたいこと次回は、一覧画面では材料を短く表示し、詳細ページでは材料やメモ、元レシピURLなどをすべて確認できるようにしていきたいと思います。少しずつ

テーブル上の特定レコードの全フィールドを表示させる案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で介護支援記録システムを作った理由－8前回のブログでは、養護老人ホームという環境下で、マイクロソフトAccessの特徴を生かし、介護支援記録の管理システム開発にとりかかるまでの経緯を書きました。 今回はそのAccessの特徴を語ることにします。 Accessはもともとスタンドアロ―ンのPCソフトとして開発され、個人の能力に合わせ自由に使われることを想定しています。 データベースを簡単かつ自動的に操作するアプリの作成機能は初心者にとってわかりやすく、プログラミング言語を学んだことがなくても、マクロ機能でそこそこのアプリを開発できてしまいます。 解説本も多く、またネットにも情報が溢れているので、勉強するのに苦労はしません。 私がAccessのVBA（Visual Basic for Applications）で介護支援記録用アプリを開発しようと思ったのも、趣味的にVB（Visual Basic）やJavaScript等でプログラミングした経験があることに加えて、VBAの情報を得やすいと考えたからでした。一方、Accessの問題点や短所としてよく挙げられるのは、まず、ネットワークへの対応力が弱く、データベースを複数人で同時操作する場合に制限があることです。大人数で同一のデータベースにアクセスするとファイルが破損しやすいと言われています。またファイルサイズも2GBまでのため、大量のデータを保管し管理することができない点もデメリットとして良く指摘されているようです。 何より、アプリを開発した職員が異動や退職でいなくなってしまうと、業務内容の変更等でアプリを改変するのが難しくな

Accessで介護支援記録システムを作った理由－4 私がAccessのようなソフトを使い始めた理由は、まず自分の仕事にデータベースを使いたいという、純粋に個人的な理由からでした。 1980年代後半にMS-DOSがパソコンOSの主流となり、社会にPCが普及していく中、私は個人でも勉強をすればデータベースが操作できる時代が来たことを知ります。 最初に関心を持ったのはdBASEⅢというソフトでした。 プログラムを書くことは、PCがマイコンと呼ばれていた時代にゲームプログラミングのため習得したBasicで経験しており、その後、ゲームを高速化できるマシン語にも手を染めていました。 なので、dBASEⅢも楽勝！という気分で取り組み始めましたが、実際にやってみると、やはり仕事の合間に独学でデータベースシステムを作ろうとするのは無理がありました。 実務者とSE、両立の試みはすぐに挫折します。 その後に異動した職場で、DOS版表計算ソフトのLotus 1-2-3をデータベース操作に利用するという、楽な方法を覚えます。1991年のことでした。 紙の帳票から必死に手入力したデータでデータベースを作ったあと、検索や抽出ばかりでなく、統計的な分析手法で、今までよく見えなかったものが明確に見えるようになる面白さを知ったことが大きな収穫でした。 そこで次に異動した職場では、Windows版 LotusSuperOfficeにバンドルされていたApproachというソフトを見つけ、これを使ってみることにします。また、自分でデータを打ち込む無駄を省くため、メインフレームからCSVでデータを抽出してもらい、これを

マルチスレッドデータベースサーバで必要なメモリー管理本ブログも5回目となりました。前回のブログでは、マルチスレッドデータベースサーバでCGIと通信するソケットプログラミングについて詳細を書いておきました。今回は、マルチスレッドデータベースサーバで重要なメモリー管理についてお話します。この話は、前々回のブログの内容とかなり関連しますので、一応リンクしておきます。C言語でメモリー領域は、1）関数内で宣言する固定的なメモリー領域のもの（スタック上に確保される）と、2）malloc()などの関数で、動的に確保したメモリー領域があります。1の場合はスタック上に確保されたものだから、そのメモリー領域は、その関数内と、その関数から呼び出される関数の中だけで有効です。そして、関数からreturnで抜けると、そのメモリー領域はスタックから解放されて、以降、参照できなくなります。いや参照してもよいですが、内容はどうなっているか不明です。2の場合は、ヒープ領域にメモリが確保されていますから、プログラム終了までメモリー領域は解放されず、もし、解放する必要があるときは、free()で明示的に解放する必要があります。WEBサーバでCGIは、httpdがリクエストを受けた段階で立ち上げられ、終ると終了しますので、CGIの中でmallocなどによるメモリー確保をしても、それは終了とともに解放されます。しかし、マルチスレッドのデータベースサーバの場合は、スレッド内で確保したメモリー領域は、スレッドが終了してもサーバ自体が動いている間は、解放されません。ですから、スレッドが終了するときに、明示的にメモリーを解放す

┏━━━━━━━━━━━━━━━━━━━━━━━━━━┃ ◆ 興味を持たれた方はDMください。対応します。┗━━━━━━━━━━━━━━━━━━━━━━━━━━不動産屋さん向けに、ちょっと便利なツールを作成しています。郵便番号を入力すると、近隣の施設を自動検索するものです。現在のところ、対象の施設は　　＊小学校　　＊中学校　　＊病院（大きな病院／診療所）　　＊バス停です。ツールの中身は、ゴリゴリに作成しています。検索に使用しているデータは、国土交通省や国土地理院などがXML形式やCSV形式で公開している位置情報データです。アプリケーション起動時に、それらのファイルを解析後、メモリ上に展開しておきます。ツールの基本的な動きとしては、　　＊郵便番号を入力します。（住所に含まれるキーワード入力で、オートコンプリートする機能あり）　　＊郵便番号から緯経度を逆引きします。（国土交通省 位置情報データ）　　＊物件住所の緯経度と各施設（学校／病院など）の緯経度から、緯経度の差を求めます。　　＊緯経度の差から、地表上の距離を計算します。（ヒュベニの公式）　　＊距離が近い順に施設をソートして、画面に表示します。｀｀｀｀｀｀｀｀｀｀｀｀｀｀｀｀｀｀｀｀｀XMLファイルやCSVファイルの読込みは、原理的に どうしても時間がかかるので、アプリケーション起動時にスレッド処理で対応しています。オートコンプリートがとにかく便利です。今後は、以下の自動検索機能も追加できればと思っています。＜データあり（できそうな見通しあり）＞　　＊JR／私鉄 最寄り駅　　＊地価公示情報　　＊避難施設　　＊土砂災害危険箇所／警

始めに書いておきますが、Accessバックアップの考え方を書きます。 実際のコードは探せばいっぱいあると思うのでそちらを参照ください。 バックアップの考え方なのでAccess以外にも当てはまると思います。Accessのファイルってたまに壊れる事があります。データベースだから壊れると困りますよね。なのでAccessでバックアップをとるのは非常に重要になります。 データベースのソフトなので言わずもがななのですが。 でも、Accessは自動でバックアップしてくれないのです。 そこでユーザーが使い易いバックアップの設計が必要になります。 設計なので様々な事情や前提から色々やり方がわかれるのですが、 Accessバックアップにおける私の考えを纏めておきます。 こうしなきゃいけないというものではないので、参考程度にお読み頂けたらと思います。Accessのバックアップの考え方1. バックアップは手動と自動、両方できる方がよい。 　当たり前なので偉そうに言う事でもないですね。 2. 手動でバックアップしたファイルと自動でバックしたファイルはファイル名等で判別できた方が良い。 　判別できなくてもいいけど、できた方がよいですね。 3. Access外部でバックアップを取る手法もあるが、Access上からバックアップできた方がよい。 　これは設計で分かれる所ですが、ユーザにとってソフトは少ない方がいいとの考えからです。 4. バックアップファイル(またはフォルダ)名には、日時を入れた方がよい。 　これも偉そうに言う事じゃないですね。当然の事です。 5. バックアップファイルでそのまま運用させない様な

企業向けのデータベースはユーザー向けのインターフェイスすなわち入力用の画面と、データを蓄積、処理するサーバーを別々に管理、開発する必要があり非常に規模が大きく費用も高額です。 Accessは小規模ながらテーブル、フォーム、レポートをすべて処理してくれるため、単体でシステムを構築することができます。 大規模システムと比べられて酷評されることもあるAccessですが、規模に見合った使い方をすれば非常に強力なツールであることは間違いありません。 紙の時代とはいえ、Accessが利用できるからといって具体的にどんなことが出来るとか、今の業務がどう効率化されるかについてはピンとこない方も多いと思います。 私は医療従事者として仕事をしています。 医療現場は医師を中心として非常に多くの職業がチームとなって仕事をしています。今では電子カルテが当たり前になっており、補助者が素早く診療内容をキーボード入力しますが、ひと昔前は医師がすべて手書きしていたのです。 カルテに検査の内容を書き、検査依頼伝票を書き、処置依頼伝票を書き、やっと検査が実施されます。 今では事前にセット登録された検査項目をクリックするだけでおしまいです。 ２０分かかっていた仕事が１分もかからないようになりました。 その分患者さんを診る時間に費やせます。また多くの患者さんに対応することができます。 Excelを使い慣れた方は、Wordで表を作っている人を見て何でExcelでしないのだろうと不思議に思います。 しないのでは無く、知らないから他に選択肢がないのです。 （すべてでは無いですが）時間をかけてExcelシートを構築することより

混在検索とは？「混在検索」というのは、こういう言葉がすでにあるのかどうかよく知らないで勝手につけた名前ですが・・・。簡単に言えば、レコードのフィールド数などの数やフォーマットが異なるデータを横断的に検索するものです。たとえば、各製品のデータに次のようなそれぞれ異なるフィールドがあるとします。製品A：製品ID,型番,年式,対応モデル,サイズ,・・・製品B：製品ID,容量,サイズ,重量,・・・製品C：製品ID,入力形状,出力形状,容量,年式,終了年・・・通常のサイトでは、次のようなパターンが多くなっています。（もちろん例外もあります）（１）検索システムがある場合は、ユーザーが製品A,製品B,製品Cのどれかを選ぶ→それぞれの中で製品IDを検索する。（２）検索システムがない場合は、製品A,製品B,製品CのそれぞれのカタログPDFが置いてあって、ユーザーがそれぞれ自分で見て、その製品IDの情報を目で追って探す。このようなときに、フィールド数などが異なるどの製品のIDであろうと一発で検索できるのを混在検索と呼んでいます。通常のDBシステムが入ったサイトでももちろんできますが、最初から計画していればともかく、後からこのような混在検索システムを入れるのはちょっと躊躇するかもしれません。簡単に混在検索システムを作る（完全一致検索）DataMarina+ToolBoxは弊社で自社開発したウェブ検索システムです。エクセルなどの表計算ソフトやパソコンDB、はたまたワードで作った表などのように１レコード１行のスタイルでできているデータの検索システムをウェブ上にDBシステムなしに実現するものです。今回は、

今回は、これまでMAMPのローカル環境で作っていた**自分用レシピ管理アプリ「My Recipe」**を、Xserverに公開する作業を進めました。これまではMacの中だけで動かしていましたが、今回はスマホからも使えるようにするため、サーバーへ移行しました。今回進めたことまず、Xserverのpublic_html内にmy-recipeフォルダを作成し、これまで作ってきたPHP・CSS・画像フォルダなどをアップロードしました。アップした主なファイルは、index.phpadd.phpdetail.phpsave.phpdb.phpcssjsuploadsなどです。Xserver側にMySQLを作成レシピデータはMySQLに保存しているため、ファイルをアップロードするだけでは動きません。そこでXserver側に新しく、xs851875_recipeというデータベースを作成しました。さらに、このデータベースを操作するためのMySQLユーザーも作成し、アクセス権を設定しました。MAMPのデータをXserverへ移行次に、これまでMAMPのphpMyAdminで使用していたmy_recipeデータベースをSQLファイルとしてエクスポートしました。そのSQLファイルをXserver側のphpMyAdminからインポート。これによって、今まで登録していたレシピデータもそのままXserverへ移すことができました。db.phpもXserver用に変更ローカル環境では、host=127.0.0.1port=8889などMAMP専用の接続情報を使用していました。公開後は、Xserver用にhos

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

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

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

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

Excelで介護支援記録管理システムを作ってみる～10日目多忙のため、再び間が開いてしまいました。 前回、パワークエリで作成したテーブルを直接加工して、特定の日付でフィルタリングしたデータを日誌に添付するための日誌シートを完成させました。 これと同様に、介護支援記録管理システムの一つの柱である動静記録を、入力済のデータから簡単にわかりやす作成できるようにします。 動静記録とは以前もふれたとおり、利用者の処遇内容を記した介護計画などを作成するさい必要となる文書で、基本的に前回の計画を策定した時点から、今回の策定に至るまでの記録データを時系列順に並べたものとなります。 従って、記録データからデータを抽出するための要素として、まず、特定の「利用者名」と期間（開始の「日付」と終了の「日付」）を必要としますが、他にも、利用者に何か事故や病変等が起きたとき、その後の対応がどうなっているか調べたいときに利用できるよう、「実施内容」でも追加的に絞り込みが行えるようにします。 まず、新たに「動静記録書」シートを作成します。このシート上に下の画像のとおり動静記録書のフォーマットを作りました。その上で、左上部に検索条件として、利用者名、期間を設定する開始日と終了日、そして実施内容を入力する部分を設けます。 一応、動静記録として表示させる記録データの数は20個までとしましたが、基本はそれぞれの施設の特性に合わせ、最大数を超えないよう設定します。 その上で、検索条件を入力する利用者名と実施内容のセルについては、データの入力規則を使い、記録テーブルに入力する方法と同様、リストから選べるよう設定します。 下

Excelで介護支援記録管理システムを作ってみる～4日目 前回までに、介護支援記録データのテーブルへデータを入力するさい、３つのフィールド（項目）である利用者名、実施内容、担当者名については、データの入力規則を用い、リストを使って入力することにしました。施設の規模から、このリストには最大で30行ほどが表示され、探しにくいという欠点はありますが、すべての項目を予め覚えておかなくても良いというメリットのほうを重視しました。 ただし、利用者、職員は利用の開始中止、退職や異動という理由で常に変化するため、これを考慮して入力規則の元となる範囲をしっかり定義しなくてはなりません。 なお、利用者、職員とも、別のExcelブックのワークシート上でテーブルで管理されているため、介護支援記録を管理するブックの中に、リンクしたテーブルの形でデータを取り込んでいます。リンク元テーブルに追加や削除などの変化があっても、このリンク先テーブルの更新を行うことで、最新情報がすぐに反映される仕組みです。 ちなみに、これらのテーブルは、介護支援記録管理システムの基礎を担う意味で、データベース用語で「マスタ」と呼ばれることもあります。前回の投稿では、データの入力規則によるリストの対象範囲を設定するさい、これらのテーブルにフィルターをかけ、該当するものだけ表示させてから設定したとしても、残念ながら無関係なデータも含めすべてリストに出てしまうことにふれました。 下の画像はその説明となりますが、左の図は利用者テーブルにフィルターをかけ、在籍が「利用中」の方に絞ったところ。右の図は記録テーブルにデータを入力するさい、利用者

Excelで介護支援記録管理システムを作ってみる～2日目 前回は、まずメインとなる介護支援記録データのテーブルを作成してみました。毎日の記録データの管理だけだったら、これで十分ではと考える方もいるかも知れません。ですが、入力のさい利用者全員の氏名を正確に覚えておくことは無理ですので、利用者の名簿を別に用意しておく必要があります。また実施内容の項目についても表記を取り決めておかないと、後で記録を検索しようとしたときに困ることとなります。 データベースシステムを構築する一番の目的は、各種情報を連携させ、スタッフ間の情報共有化と各種業務の効率化を図ることにありますから、記録データに関係する各種情報についてもデータベース化し、記録データとリンクしやすい形で管理できるようにすることが理想です。特に異動の多い利用者やスタッフの情報などがこれに該当するでしょう。 しかし実際のところ、一般的にこれらの情報は事業所内で別々に管理されているはずです。 例えば利用者の情報について言えば、氏名や年齢だけでなく、医療保険や介護保険の情報、家族の情報、年金や年収の情報など、サービスの供給や処遇、関係機関との連携に必要な様々な情報を、必要に応じ一括又は分割してデータとして管理しているのが普通です。 これらを全て一元的に管理するとなると、介護支援記録管理システムの範囲を超えてしまいます。 そこで、今回は、利用者の情報など関連する情報が別のExcelブックで管理されていることを前提に話を進めていくことにします。 まず利用者の情報は、利用者DBというExcelブックの中に、下の画像のような利用者テーブルで管理され

Accessのテーブルはこんな感じです。Excelのシートと変わりないですね。でもデータベースは、こんな感じの歯抜けを嫌います。空欄でも情報は情報なので、これだと「I0001のJANコードはNullですよ」ということになっています。Nullというのはなにもない、という意味なのですが、本当になにもないならなにもないはずです（よくわからない笑）。つまり枠をこしらえてしまうとそこにはなにかの情報を入れなくてはならず、Nullというのも立派な情報なので、本来I0001のJANコードは地球上に存在しないのにテーブル上ではI0001のJANコード＝Nullとなってしまうわけです。これはクエリを組む際など、いろいろ問題が出てきます。SQLも複雑になりますね。じゃあどうすりゃいいんだよ、という話ですね。こうします。たとえばI0001のJANコードを入力する場合は、縦に足します。これでJANコードのない商品には枠を設けずに済みます。空欄ができないので無駄なデータなし、速度と安定性も向上します。ただこの形式だと扱いづらいので、2つ上の画像みたいな作業用のテーブルを用意して、ふつう形式に変換するプログラムも合わせて用意します。もちろんぜんぶ必須項目ならふつう形式のテーブルで構わないのですが、なかなかそうはいかないですよね。Accessを学ばれている方は、こういう格納の仕方もあるんだよ、ということを覚えていただければと思います。変換プログラムはやや面倒なので、もし必要であれば安価でご提供いたしますよ～。

Accessで介護支援記録システムを作った理由－5 自宅用のAccessまで手に入れたあと、その後は仕事でも使うことはなく、時は過ぎていきました。しかし、西暦2000年が明けた頃、思いがけず仕事で使う機会がやってきます。仕事上の成り行きで、あるNPO団体の手伝いをすることとなり、その収支関係をデータベースを使って管理するものを作る必要に迫られたのです。 実はこの時の経験が、20年後に介護支援記録管理システムを開発することに至る大きな動機付けとなります。 なお、これからは、データベースシステムを分けて、データベース本体（データ）とは別に、マクロやVBAなどプログラムコードを使い、操作を簡便化、自動化したインターフェイス部分をアプリと呼ぶことにします。 作るべきシステムの機能としては、単式簿記による入金と出金の管理、これに伴う確認や決裁書類の作成のみでした。但し、これを操作するのはパソコンを習いたての中年女性、まだExcelも使えない方でした。もちろんAccessを自力で操作するなんてとんでもありません。もしもExcelでこれを作った場合、不慣れな操作でデータを消してしまったり、最悪、ワークシート上のテーブルや関数を壊してしまい、使えなくしてしまう恐れは十分にありました。そこで、データの入力はキーボードから行い、アプリの操作はボタンをクリックするだけで簡単にできるものをAccessで開発することにしました。 その当時の私は、テーブルとそれらを組み合わせてクエリを作るくらいの知識しかなかったため、解説本でフォームの作り方やマクロを急いで猛勉強します。難しいVBAを使うのは完成まで時間

前回のブログではマイクロソフトAccessとの出会いについてふれましたが、なぜデータベースに惹かれたのかを語りたいと思います。私が就職したのは1978年、地方公務員としてでした。最初に配属されたのは、医療費助成を担当する部署でしたが、非効率的な手作業が多いことに驚いた記憶があります。 このとき始めて具体的に稼働しているコンピューターのことを知ります。いわゆる「メインフレーム」ってやつです。バッチ処理と呼ばれる月1回の処理方法で、業務データの入出力が行われていました。紙の受給者台帳、医療機関名簿、振込リストなどを使って仕事をしながら、このとき、世の中の情報はほとんどデータベースで整理され、それが日々更新されていることを知ります。 現在ではIT化が進み、システムへの入力はオンライン化され、帳票類も随時出力できる進化を遂げていますが、その根本に変わりはありません。 ちなみに、役所も含め、事務作業の生産性が低い理由の一つは、大量の紙文書の存在があるからだと思っています。少しずつでも無くしていくことが、生産性向上につながるはずです。 情報におけるデータベースの存在意義、効果を知った私は、自分のデスクワークにもデータベースを使いたくなります。 それが実現したのは1980年代の末頃、MS-DOSパソコンがようやく職場に普及し、ロータス１-２-３を使い始めてからでした。何百件もあるデータはすべて自分で打ち込み、データの並べ替えやフィルタリング作業は、マクロで自動化して仕事に役立てました。Excelなどの表計算ソフトでデータベースを作り、操作するのは今ではポピュラーとなっていますが、当時としては

本日、私が開発した介護支援記録管理システムの紹介動画をアップしました。これを記念に何か皆さんの参考になればと思い、ブログも始めることにしました。気の向くままに投稿しますので、よかったら読んでください。さて、40代でマイクロソフト Accessを仕事などに使い始めてから既に30年近く経とうとしています。現在までに至る歴史のきっかけは、当時、最も表計算ソフトとして輝きを放っていたロータス 1-2-3を使って個人で仕事に必要なデータベースを作成し、マクロを組み合わせてその便利さに気づき感動したことでした。1991年、ロータス社は個人向けのデータベースソフトとして、Approachというソフトを開発・販売します。私も自分の仕事の中で、本格的な集計や分析などに使用することにしました。しかし、実際使ってみると集計にとても時間がかかり、フォームの作成も非常に面倒くさく、使い勝手はイマイチでした。そうすると間もなく、優秀なデータベースエンジンを持つAccessがマイクロソフト社から発表されます。これがAccessとの必然的な出会いとなりました。このブログでは、ExcelほどメジャーではないマイクロソフトAccessの良さを再確認しながら、私が開発した介護支援記録管理システムについて語っていきたいと思っています。>下の投稿へ続く

職業柄、厚生労働省関連のWebサイトで調べものをする機会が多いです。行政は色々なデータを公開していますが、CSVファイルやExcelファイルなのでデータの絞込みや集計が煩雑になります。今回、医療機関の情報をデータベース（Microsoft　Access)に取り込んでみたところ思いのほか実用的だったのでご紹介してみます。内容は自分のブログで紹介したものです。医療従事者向けのものにはなりますが、他業種でも所轄官公庁が公開している情報は多くあると思いますので応用は出来ると思います。私の住んでいる中国地方の厚生局のサイトから医療機関の届出情報をダウンロードしてみました。保険医療機関には施設基準の届出という仕組みがあり、何をするにも国に申請して許可を得る必要があります。施設基準とは 施設基準とは、医療法で定める医療機関および医師等の基準とは別に、健康保険法等の規定に基づき厚生労働大臣が定めた保険診療の一部について、医療機関の機能や設備、診療体制、安全面やサービス面等を評価するための基準になります。 診療報酬の中には、この施設基準の届出を行うことで算定が可能となるものがあります。 施設基準ごとに対象となる患者さんや算定の要件、届出の要件が定められています。coconalaブログでは他のサイトへリンクを張れないようなので興味のある方は「医療従事者のためのAccess」で検索してみてください。このように医療機関毎に取得している施設基準の一覧表を簡単に入手することができます。ただしExcelはあくまで一覧でしかないので、フィルターを駆使して欲しい情報を検索するしかありません。Accessを利用

最近、組織内でSharePointサーバを導入するケースが増えています。その中で、従来のファイルサーバからSharePointサーバに完全移行した際に、Excelマクロが動作しないなどの問題も発生していると聞きます。　・従来のファイルサーバ（例：￥￥サーバ名￥部署名）　・SharePointサーバ（￥￥テナント名＠SSL￥DavWWWRoot）実際、SharePointサーバに完全移行した後で、従来の作業を、従来通りの感覚で行う対策は難しいです。私達は、購入者様の「こういうことをしたい」を丁寧にヒアリングして、現実的な解決策を 一緒に考えさせて頂く、ということを基本スタンスにしています。｀｀｀｀｀｀｀｀｀｀｀｀｀　私達の感覚では、Microsoft SharePointの位置づけは、チーム作業を支えるデータ共有プラットフォームだと思っています。　表形式データの中身を、WEB上のデータベース（名称：SharePoint List）に置いて、ユーザインターフェースとしてExcelを使用するような形が想定されているのかと。　そうすれば複数人のチーム作業で、リアルタイムでデータが共有される、といった青写真が描かれているようにも思えます。　本質的には、既存のExcelデータ（管理台帳など）をSharePoint List上にアップロードして、クエリを使用して、そのデータと連携するのが対策となるかと思います。　具体的には、クエリで読み出して集計作業を行ったり、Excelマクロを組んで SharePoint List上のデータを追加／編集・更新／削除したり。　一方で、私達は、日常の業務に追わ

相変わらずAccessの使い方は分からないけれど、時間があるときに開いては何かのデータを打ち込んで、どのような動きをするのかを確かめていました。 テーブルの見た目はExcelと同じような感じなので、何となく使えそうな気がしてきました。むしろデータを入力するにはExcelよりも使い勝手が良さそうな気がします。 実際、Accessではフィールド（Excelでいうところの行見出し：一番上の行のデータ名）を定義するだけで、後は１行ずつ入力できるのでExcelよりも簡単だと思いました。 （Accessのテーブル：入力に関してはExcelよりも簡単です。）ところがデータを入力していく内に、内容をコピペするのが意外に面倒でそもそも同じ内容のデータを何回も入力することに疑問を覚えました。 同じ相手に対して複数の取引があり、相手先を何度も入力して取引を入力するような場合です。Excelであれば縦にマウスをドラッグすれば、一斉にコピーできるのにAccessでは１つずつしかコピペできないのです。 他にもテーブルでの入力は何かと制限が多く、不便を感じ始めた頃に次のステップであるフォームの存在を知りました。 （これらはダミーデータ作成サイトで生成した架空の情報です）フォームでは自分がデザインしたレイアウトで、思うように入力欄を配置して自由に入力することが出来ることが分かりました。 コンボボックスで入力対象の候補から選択して入力したり、入力結果を計算して別の欄に入力したり色々と便利に使えるようになりました。 こうしてフォームが使えるようになったことで、「同じ取引先を何度も入力する」というのはそもそも間違い

　Windowsプログラム（VB.netやExcel VBAなど）からデータベースに接続する場合、ADO (ActiveX Data Object)を使用したコーディングが必要となります。　このコードは、外部データとの通信に不慣れなプログラマにとって、やや分りづらいものです。　そこで今回の記事では、中級者の方を対象として、Excel VBAを使用したデータベースアクセスの基本的な動作イメージを紹介したいと思います。　どのようなプログラムを組むにせよ、全体のデータフローがイメージできているか否かは、その後に進めるコード記述作業を、大きく左右すると考えます。　まず、全体の流れです。これは非常にシンプルです。(１) 対象のデータベースに接続する。　　データベースの形式は様々です。ファイル形式のものもあれば、データベースサーバとして独立したPCやサーバを立てている場合もあるでしょう。あるいは、Microsoft Shrepointなど メーカがサービスとして提供しているWEB上のデーがベースサーバもあります。　　まずはじめに、これからクエリを発行したいデータベースを特定できる形で、データベースに接続要求を行うことが、最初に行う作業になります。(２) データベースから接続応答が返ってくる。　　接続要求を受けたデータベースサーバ（対象がファイルの場合はデータベースドライバ）から、接続を受け付けるか／否かの応答が返ってきます。　　(１)項の接続要求にて、そのときに指定したユーザ名やパスワードなどの認証情報を元に、データベースサーバ（あるいはデータベースドライバ）が判断した結果となります。　　

書類作成のための入力をデータベース化して活用できる一例ITのインフラが整った企業であれば、申請書類を手書きして担当者へ提出するような流れは無いのでしょうが、そうでなければ出張や休暇の申請書類を手書きで提出していると思います。私の職場もそうです。手書きでもWordやExcelで清書印刷しても同じことですが、紙の情報しか残りませんから実施したら書類は保管ファイルへ移動されるだけです。 何かしらの台帳に転記されて管理はされるでしょうが、それが利用されることはありません。一方で情報をデータベースに入力した場合を考えてみます。 情報を入力するのは申請者です。出張申請書を例に考えてみます。 所属部署、氏名、出張先、出発日時、帰着日時などの情報を入力して出張申請書を作成します。 どの部署でも同じように出張申請書を入力して印刷できる環境を整えます。 同じ仕組みで休暇届もデータベースに入力して印刷できるようにします。 出張申請書と休暇届の情報を併せてカレンダー式に表示させることで、不在予定者の一覧が完成します。予定表に名前が無ければ、申請書類が出ていないということなので本人の責任です。 行き先が入力されているので、出張費の清算も簡単です。また、休暇管理は勤続年数と関係して管理が複雑になりがちですが、入力された情報を利用すれば容易に管理できます。 部署ごとの有給休暇取得率もすぐに計算できます。 職員は手書きの手間が省力化できて、簡単に申請書類を作成できる。 管理者は入力されたデータを基に予定や実施を管理することが容易になる。 すべての予定は入力されているので、出張報告書が提出されなければ実施されて

はじめに弊社で自社開発したウェブ上の検索技術であるDataMarina(データマリーナ)＋ToolBoxを使ったウェブアプリの開発方法を具体例を使って簡単に紹介します。題材は日本郵便が公開している郵便番号CSVファイル。これを使って、郵便番号・または住所から地図表示（グーグルマップ）のウェブアプリを作ってみます。検索方法の決定検索方法としては次の2通りを予定します。①郵便番号→地図②都道府県名→市町村→その下の町など、を絞り込んで→地図実際の作業(1)日本郵便からCSVファイルをダウンロード「郵便番号データダウンロード」で検索すれば出てきます。(2)CSVファイルの調整今回は、郵便番号と住所だけを使うので、読みなどのフィールドは削除して、文字コードをUTF-8に変換します。レコード数（行数）は12万4433あります。(3)検索方法に基づいて検索データを作成専用のツールを使って検索データを作成します。(4)検索用ホームページの作成簡単のために、すでにあるサンプルからページを拝借して文字を変更して再利用します。(5)ToolBox用の設定プログラム、ユーザープログラムの作成これももまた、すでにあるサンプルから拝借して文字・設定項目を変更して再利用します。ただ、地図の表示に関しては新規に機能を追加します。(6)アップロード以上ででき上がりです。ファイル一式をサーバーにアップロードしてアクセスします。機能の確認、必要であれば表示・スタイル等の修正を行って完了です。これで、約1時間でできました。もちろん、実際に使う場合にはページの新規作成、表示の調整などが必要になりますが、基本的にはこの

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を長年愛用しているユーザーと、こういう小さなストレスの積み重ねで離脱するユーザーの相違って

こんにちは、Dr.WordPressです。WordPressサイトを開いたときに突然、「データベース接続確立エラー」と表示されたことはありませんか？例えば、「昨日まで普通に表示されていた」「サイトも管理画面も開けない」「WordPressを触っていないのに突然表示された」といったケースです。このエラーが表示されると、サイトのデータが消えてしまったのではないかと不安になる方も多いと思います。しかし、データベース接続確立エラーは、必ずしも記事や画像などのデータが消えたことを意味するものではありません。今回は、WordPressで「データベース接続確立エラー」が表示されたときに考えられる原因と確認方法をご紹介します。① データベースの接続情報に問題があるまず確認したいのが、WordPressからデータベースへ接続するための情報です。WordPressでは、・データベース名・ユーザー名・パスワード・データベースの接続先などの情報を使ってデータベースへ接続しています。これらの情報に間違いがあると、WordPressがデータベースへ接続できなくなります。特に、「サーバーを移行した」「データベースを変更した」「WordPressの設定ファイルを編集した」という直後にエラーが出た場合は確認したいポイントです。② データベースサーバーに問題が発生している自分でWordPressを変更していなくても、レンタルサーバー側で一時的な問題が発生している場合があります。例えば、・データベースサーバーの障害・サーバーメンテナンス・一時的な高負荷などです。「何も触っていないのに突然エラーが出た」という場合は、

数値フィールド「超え/以上/未満/以下」　　　　＆昇順/降順の並べ替え☆ポイント※以上/以下：≧や≦の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