こんにちは。ビーグルソフトの真鍋です。
最近はシステム開発現場でもマイクロソフトAccessを利用する機会が減ってきたように思います。以前は、ExcelやAccessで作られたシステムに関する相談が多く、ドキドキしながらお話しをお伺いしていました。
というのも、ExcelやAccessで構築されたシステムは、何となくできることが多く、何を行っているか調査を行うことが大変なためです。意外なところで、想定と異なる使い方をしていて、調査にヌケ・モレが発生する可能性が高くなります。そして、想定と異なる使い方がいちばん重要な利用シーンだったりするのです…。
Accessで同時入力したい
Accessはデータベースであり、入力フォームであり、帳票であり…と多機能です。設定や構成によっては、同時入力も基本的に実施できます。マイクロソフトのドキュメントによると、以下の5つの方法が定義されています。
| 共有方法 | フロントエンド | バックエンド | データの場所 | シナリオ | ユーザー数 |
|---|---|---|---|---|---|
| 単一データベース | --- | --- | ホームネットワーク | ホーム/小規模のビジネス | 少数 |
| SharePoint | Access | SharePoint リスト | SharePoint サイト | エンタープライズチーム | 多数 |
| データベースの分割 | Access | Access | ネットワークフォルダー | エンタープライズチーム | 多数 |
| クライアント/サーバー | Access | SQL Server | データベースサーバー | エンタープライズ全体 | 多い |
| ハイブリッド クライアント/サーバー | Access | Azure AD | Azure Cloud | エンタープライズ全体 | 多い |
構成を考えると、単一データベースでは同時入力は行えません。SharePoint、データベースの分割、クライアント/サーバー、ハイブリッド クライアント/サーバーが同時入力に適した構成となります。
Accessデータベースが壊れる
これは経験値でしかないのですが、Accessをデータベースとして利用したとき制約が多く、データベースファイルが破損することが多くありました。(最近のAccessでこの方法を試したことがないため、改善されているかも知れません。その点はご注意ください。)
例えば、以下のようなことを経験したことがあります。
- データ容量は2GBに制限されており、容量が大きくなるにつれてエラーが発生することがありました。
- データベースを分割して、データベースファイルは共有フォルダに保存し、リンクテーブル経由で入力フォームから多人数で入力を行うと、エラーになってしまいデータベースが開けなくなることがありました。
クライアント/サーバーを利用することが多かった
Accessはデータベースが壊れるということから、仕事で携わる案件では、Accessはデータベースではなく入力フォーム＋帳票出力環境となっていました。そして、バックエンドのデータベースにはSQL ServerやOracleを利用することが多かったです。
ただ、お気づきの方も多いかも知れませんが、バックエンドのデータベースにSQL ServerやOracleを利用するは、もともとあるシステムがSQL ServerやOracleで構築されていて、そのデータベース内にテーブルを追加して簡単な仕組みを構築するための用途が多かったわけです。
つまり、基本的なシステムが構築されているけれども、ユーザー部門としてはもう少しカスタマイズしたい。そのときに、システムのデータを参照しつつ自分たちでテーブルを追加して帳票出したりするときに活用することが多かったのです。
Accessからシステムへ
もちろん、Accessを利用したシステムが構築されていることもありました。ただ、AccessではなくVB等でシステム化してほしいという要望が多くありました。
主な理由としては以下の通りでした。
- データの整合性がとれないことがある。
- 入力がもたついてしまう。
- 対応できる人がいなくなってしまった。
実際のところはAccessが悪い訳ではなく、Accessが簡単にいろいろできるためシステムとして必要な事項を理解しなくても作れてしまうことが問題だったのではないかと思います。
SharePointをバックエンドにする
さて、むかしばなしが長くなってしまいました。システム開発者からすると、Accessで構築されたシステムというのは構えてしまう案件でした。
ということで、個人的にはAccessを利用するのであれば、データベースはRDBを利用することが望ましいと考えています。保守を行うのであれば、なおさらです。
一方で、最近のAccessはSharePointのリストをバックエンドとして活用することができます。このことは最近知ったのですが、ちょっとビックリしました。
SharePointとは
SharePointとは、マイクロソフト製のドキュメント管理プラットフォームです。昔はWindows SharePoint Services (WSS)と呼ばれており、Small Business Serverに付属していたものを自宅サーバーで運用したことがあります。
SharePointはSQL Serverをベースに構築されており、OneDrive for Businessのバックエンドでもあります。
AccessのテーブルをSharePointへ移行する
このうち、AccessのテーブルをSharePointのリスト(SharePointリスト)に対応させることが可能となっています。AccessのデータベースツールにあるSharePointボタンをクリックすることで、対応するSharePointのサイトへテーブルを移行することが可能となります。
SharePointで対応するテーブルを確認すると以下の通りとなります。
SharePointリストは、Webシステムのため同時入力も問題ありません。(入力は後勝ち方式での入力となるようです。)
Accessのリンクテーブルからも入力は可能で、同時入力も問題ありません。(こちらは楽観制御されているようで、変種モードに入ってから確定するまでに内部のタイムスタンプが更新されると入力を確定できませんでした。)
SharePointリスト活用時の注意点
AccessのテーブルがSharePointリストへ移行すると、SharePointで編集できてWebシステムとして外部からも参照できるのでいいことづくめのように感じられるかも知れません。
しかし、そう単純な話でもありません。以下の点については考慮が必要だと感じました。
- ID列やタイトル列、更新日時等のSharePointリストで必須となる列が自動的に追加される。
- Accessのテーブルで利用していた主キーは_OldID列にマッピングされる。ただし、主キーが数値以外のとき？は、列名がそのままとなりID列が追加される。また、主キーが数値が他以外でidという命名の場合は、SharePointリストのID列が_idという名称に変更される。
- テーブル間のリレーションシップが設定できないため、参照整合性を担保することができない。
- 入力の検証処理をSharePointリストで設定する必要がある。
ひとことでいうと、仕様がよくわからないこともあり、挙動に不安を感じます。ルールはあるのですが不明瞭に感じました。(ドキュメントを探しても見つからずでした。)
表示して確認することや、単一テーブルに閉じている場合はこれでよいのでしょうが、入力内容を他テーブルで設定する場合などは、このままでは整合性の担保ができないのではないかと思います。
結局どうすればいい？
AccessのテーブルからSharePointリストへ移行すると上記のような問題点はありますが、SharePointリストへ手動で設定する場合には、テーブルの関連等も設定できます。そのため、入力も含めて考えるなら、SharePointリストへ手動で設定を行う方が良いのかもしれません。
しかし、Azure SQL Databaseを活用すればパフォーマンスにもよりますが比較的安価にRDBを利用することができます。こちらの方がよいのではないかと思います。(小さく始めるならDTUモデルで始めればよいと思います。)
さいごに
Accessで同時入力したいときに、どのような構成を取ることが望ましい(と私が考えるか)についてまとめてみました。
Accessを利用しているケースは、データの不整合やデータベースの破損などの事象が見られることから、同時入力やデータの整合性担保のためにもRDBを活用した方が良いのではないかと考えます。
手軽に機能を実現できることは素晴らしいことですが、徐々にそのことが負担となることもあります。そのようなときには、ご相談いただければ次のステップをご案内できますので弊社をご活用いただけると幸いです。