Microsoft Access 掲示板

共有時の帳票フォームの作り方

5 コメント
views
4 フォロー

お世話になります。
共有時の帳票フォームの作り方について、教えていただきたい次第です。

Access データベースを共有する方法について、調べて、私もだいたいは理解しているつもりです
(連結、非連結、ワークテーブル、ホイールを転がすのが好ましくない等等……)。
ただ、共有時の帳票フォームの作り方が、よく分からないでいます。
帳票フォームで実現したい仕様は、以下のような感じです。

1 データを一覧として閲覧(のみ。CRUD の R のみ)
2 例外的に、各行が持つチェックボックスのチェック。このチェックボックスには 2 タイプあって、
 a 論理削除のように、バックエンドにも要るもの。
 b 各ユーザが自分が印刷したいレコード(複数)を指定する時に使うフィールドのように、バックエンドには要らないもの。

これは、どのように実装すべきでしょうか。
あるいは、仕様を見直すべきでしょうか。私は社外の事情に疎いのですが、どういう仕様が一般的・普通なのでしょうか。

ご助言をいただきたく、よろしくお願い致します。

rs
作成: 2019/06/14 (金) 05:53:14
通報 ...
1

1 データを一覧として閲覧(のみ。CRUD の R のみ)

共有する人数、更新の頻度、ネットワーク環境(有線/無線など)によって異なるので、一概には言えません。
共有人数が一桁で閲覧のみなら、データベース分割、連結フォームでたいていは問題なく運用できると思います。

2 例外的に、各行が持つチェックボックスのチェック。このチェックボックスには 2 タイプあって、
 a 論理削除のように、バックエンドにも要るもの。
 b 各ユーザが自分が印刷したいレコード(複数)を指定する時に使うフィールドのように、バックエンドには要らないもの。

b に関しては下記で紹介している方法が使えます。

非連結のチェックボックスでレコードを選択する
帳票フォームでチェックボックスを配置して、チェックしたレコードのみ選択して印刷したいのですが、一つのレコードをチェックするとすべてのレコードが選択されてしまいます。 掲示板でたまにみかける質問です。気持ちは分かりますが、非連結コントロールでの更新はすべてのレコードに反映されてしまいます。一つのコントロールにプロパティ値は一つしかもてませんので。各レコード毎にプロパティ値を持つような設計にしたら大量...
fc2

a に関しては、1で示した条件内なら普通に連結で問題ないと思います。
実際運用してみて、頻繁に破損したり不具合が出るなら、上の非連結チェックボックスでチェックして、更新クエリでまとめて更新するという運用にするといいでしょう。その場合は、トランザクションをかけておくとより安全です。

共有人数か何十人もいるなら、そもそもAccdbでは無理なので、SQL Server等の本格的なRDBMSへの移行を検討すべきでしょう。

2

ご回答ありがとうございます。
いわゆるひとり情シスなもので、助言があるだけでありがたいのですが、
hatena さんのような Access 界の有名人からは特別な感じがします。

書き損なってすみませんでしたが、
有線 LAN・共有人数一桁でした。
バックエンド非連結くずしは、
正規化に対する正規化くずしのように加減が分かりにくい世界だと
認識しておりまして、
TOP 句と外部結合を使った SQL から
2, 30 レコードぐらいのワークテーブルを作って、
帳票フォームでページを切り替えていかないといけないのかどうか、
ずっと悩んでおりました。
がしかしそこは、おかげさまで解決です。

ところで、上記 "2b" につき、リンク先拝読しました。
ただ、テーブルに 8,000 件ぐらいはあって今後も増え続けるので、
十分な速度が出(続け)るか分からないところはあります。
「テーブルに Yea/No型のフィールドを追加して、チェックボックスをそれと連結させましょう」の場合、
ユーザ人数分のフィールドをバックエンドに持つか、
ローカルで生成してリンクテーブルと結合になりそうですが、
個人的にはベストが明らかだという感じがしません。
ご意見を伺えれば幸いです。

3

自己レスです。

「ベストが明らかだという感じがしない」と書きましたが、
考えてみれば特別な業務以外で True の数が大きくなることはないので、
やはり hatena さんの方法で行けそうな気がします。

そちらで納得したいと思います。
ありがとうございました。

4
hatena 2019/06/14 (金) 19:53:56 修正

2Bの方法は件数か多いと重いかもしれません。選択リストをテキストで保存してますので、検索や削除処理が重くなりそうです。リストをDictionaryオブジェクトに格納すると、検索/削除は高速になるので8000件ぐらいならいいかも知れません。
テーブルに格納するなら、フロントエンド側のワークテーブルにする設計にするのが楽だし、速度的にも有利かと。
バックエンドに格納してしまうと複数ユーザーの更新の衝突の危険性が増してしまいます。

※投稿してから、上の投稿に気が付きました。

5

お返事書かせてしまってすみません。
書いて下さった情報は貴重なので覚えておきます。
たびたびのご助言、本当にありがとうござました。