Access (VBA)

Access VBAに関するフォーラムです。
  • 解決済みのトピックにはコメントできません。
このトピックは解決済みです。
質問

 
(Windows 10 Pro : 指定なし)
SQLを実行してフォームを開く
投稿日時: 21/10/24 14:53:20
投稿者: Manabukunn

いつもお世話になっております。
 
テーブル名   受診日
フィールド名  受診日ID 患者ID 受診日
 
テーブル名   検査値
フィールド名  受診日ID 患者ID 検査1 検査2 など
 
の二つのテーブルが存在しております。
この二つのテーブルは受診日IDで1対1のリレーションが組まれております。
 
今回テーブル:受診日をレコードソースにしてありフォーム:受診日上に
存在する同じくテーブル:検査値をレコードソースにしてあるフォーム:検査値 を
開く動作に関して質問です。
 
現在のフォーム:受診日上の”患者ID”に対応している”受診日ID”のみでフォーム:検査値 を
開きたいということがやりたいことです。
 
クエリを参考にしたのですが
 
SELECT 受診日.受診日ID
FROM 受診日 INNER JOIN 血清学的評価 ON 受診日.受診日ID = 血清学的評価.受診日ID
WHERE (((受診日.患者ID)=1));
 
のWHERE (((受診日.患者ID)=1))の部分の患者IDに関してですが
 
こちらを受診日.患者ID = patientID
などと変数にして DoCmd.OpenForm を用いてこれを行うことは可能なのでしょうか。
よろしくお願いいたします。
 

回答
投稿日時: 21/10/25 08:43:21
投稿者: Suzu

VBAを使用すれば変数を使えない事は無いですが、
今回の場合であれば、フォーム 受診日 上の コントロール 受信日ID を 参照する様にした方が楽だと思います。
 
その場合の フォーム 検査値 のレコードソースは
 
SELECT 検査値.受診日ID, 検査値.患者ID, 検査値.検査1, 検査値.検査2
FROM 検査値
WHERE 検査値.患者ID= [FORMS]![受診日]![受信日IDを表示するコントロール名];
 
で良いかと思います。
 
 
直接、ご質問とは関係ありませんが
各テーブルの フィールド数が提示 のみであるなら
テーブル 受信日/検査値 を別にする意図は何でしょうか?
 
メインテーブル 受信日 側 において、テーブル 検査値 とフィールドの違いが、「受信日」のみであり
別にするメリットが無いと思われます。

投稿日時: 21/10/25 19:04:40
投稿者: Manabukunn

Suzuさん
コメントありがとうございます。
 
まず、こちらの記載ミスですみません。
 
テーブル名   受診日
フィールド名  受診日ID 患者ID 受診日
  
テーブル名   検査値
フィールド名  受診日ID 検査1 検査2 など
 
が正しいテーブル構成です。
こちらにしても受診日テーブルにすべて加えればよいのでは
という感じもして最初そのような構成も考えてたのですが
検査値テーブルと同じようなものの数が非常に多いため
(全部一つにすると100以上になってしまうため)
カテゴリー別にテーブルを分けたほうがわかりやすいという
結論に至りこのような構成にしました。
 
それにしてもクエリでテーブル:受診日とテーブル:検査値を
結合してそれを基にしたフォームを作ればよいという話になると
思いますが、
フォームの中には約90個のチェックボックスを図の正しい位置に
配置しているようなものもあり再度これを作るのはミスにも
つながるので現在使用している入力用のフォームに
同じ患者IDの別の日のデータも見れるように作りたい!!というのが
今回の質問させていただいたそもそもの理由です。
したがって、何とかVBAで何とかならないでしょうか。
お知恵をお願いいたします。

回答
投稿日時: 21/10/27 10:28:14
投稿者: Suzu

引用:
同じ患者IDの別の日のデータも見れるように作りたい!!というのが
今回の質問させていただいたそもそもの理由です。

 
そういう事なのですね。
 
であれば
SELECT 受診日.受診日, 検査値.検査1, 検査値.検査2
FROM 受診日 INNER JOIN 検査値 ON 受診日.受診日ID = 検査値.受診日ID
WHERE 受信日.患者ID = [FORMS]![受診日]![患者IDを表示するコントロール名];
を参考にしてみてください。
 
 
 
引用:
検査値テーブルと同じようなものの数が非常に多いため
(全部一つにすると100以上になってしまうため)
カテゴリー別にテーブルを分けたほうがわかりやすいという
結論に至りこのような構成にしました。
テーブル構成として、同じような構造のテーブルを複数持つのが 好ましいのか好ましくないのか があります。
に関しては、どうなんでしょうね。
 
同じような構造のテーブルを複数持った場合、何か 仕様変更があった場合に
その全てのテーブルに対し、構造の変更を行う必要があります。
検査の種類が増えた際には、テーブルを増やす事で対応できます。
 
対し、同じような構造のテーブルは一つに纏めてしまう方法
この場合、先の分けた場合のデータ群を得るにあたり、クエリを使うことになりますが
テーブル構造の変更に際しては、1テーブルの変更で済みます。
(複数のクエリオブジェクトとして保存はせず、
  1つの クエリのSQLを書き換えてる[下記のフォーム/レポート を同一ソースにする場合は若干有利]
  フォーム/レポートのレコードソースのSQLを都度書き換える
 等の方法を採ることもあります)
 
【同じよう】と言うのが
支店A
ID 客先 売上
 
支店B
ID 客先 売上
の様な話なのであれば
 
ID 支店ID 客先 売上
としてしまえば良いと言うことです。
 
【同じような】の内容が判らないですし、
検査内容により、フォームのデザイン等も変わる可能性もあるでしょうから
その辺りは、Manabukunn さんがお決めになる話でしょう。

投稿日時: 21/10/28 00:20:21
投稿者: Manabukunn

Suzuさん
 
いろいろとありがとうございます。
結局、クエリで結合して
それを基にフォームを作って対処しています。
なぜはうまくいかないものもあるのですが
いろろと格闘してみます。
有難うございました。
今後ともよろしくお願いいたします。