Accessの実装は整理整頓が大事(自己反省と雑記)

雑記です。

最近、ちょっとしたツールの作成にAccessを使いだしています。Accessといえば開発入門の時によく使っていましたが、仕事として業務システムを開発するには危なっかしいイメージがあり採用することはほとんどありませんでした。

今回、利用者１名でExcel管理に毛の生えたようなレベルのツールを作るためにAccess採用。作っていくうえでオブジェクトが増えすぎて煩雑になってきたので自戒の意味も込めてAccessを使う上での整理ポイントについて個人的な考え方をまとめておきます。

なお、ちゃんとしたシステムであれば、画面遷移図やら各種オブジェクトの一覧、設計書なども作るでしょうし、各種命名規約もきちんとしていると思いますので、今回のケースはそんなきっちりしないで「ざっと」作るときにでも注意しておいた方がいいですよ。というレベルの情報です。

【登場人物】
Access データベースファイル
フォーム、レポート、テーブル、VBAプログラム、マクロ

【これをやっておけば何とかなる】
命名はきちんとね。

【整理せずに進めて困る可能性がある事例(やらかしたこと含め)】
・テーブルの分類が不明
　マスタなのか、トランザクションなのか、ワークなのか
・フォームの用途が不明
　入力フォームなのか、処理フォームなのか、サブなのか
・レポートの呼び出し元が不明
　単体で呼び出せるが
・活きているオブジェクトなのか、試作なのか不明
・そもそもソース管理が

【これだけはやっておこう】

テーブル

接頭語くらいはつけましょう。必ず「作るときに実施」
後で変えてもAccessが良きに計らってリファクタしてくれるようですが、してくれない箇所もあります。（ソースへの記載は当然ながら変えてくれません）

フォーム

ある程度のカテゴライズは事前にしておきましょう。
考えられるカテゴリとしては
メニュー：画面遷移だけするもの
入力フォーム：データの登録、修正するもの
サブフォーム：入力フォームの中に組み込むもの
サブ画面：入力フォームのサブ機能をもつもの、処理指示など
個人的にはいわゆる「接頭語」と連番でまとまるのが良いと考えてます。

例) xxxxはわかりやすい日本語名
メニュー：FM連番xxxxxxx
入力：FI連番xxxxxx
サブフォーム：FI連番SUB連番xxxxxx
サブ画面：FS連番xxxxx

クエリ

作成する数も多いのでこれが一番散らかります。
【決めごと】
画面、レポートなどのオブジェクトに対応するものは同じ接頭語をつける。その後に詳細用途
例)
FI連番SxxxxxxForm
FI連番Sxxxxxxcboxxx ※セレクトボックス
FI連番SxxxxxxListxxx
FI連番Ixxxxxxx (Insertクエリとか)
FI連番SxxxxxxXXXXQuery

長くなっても、用途がわかった方が良い

共通はCOMxxxとかでいいんじゃないかな。
間違っても、日本語名だけではやらないこと。絶対にあとでわからなくなります。

クエリのネスト
クエリでクエリを参照することはあると思いますが、その時に命名をどうするかは悩ましい。私の場合には１処理でネストする場合のみSub1,Sub2とかで命名します。
既にあるフォームで作成しているクエリを参照したい場合、面倒であっても
作成済みクエリを直接参照するのではなく、新規クエリで作成済みクエリを参照するようにしています。

レポート

ID命名と、メインかサブかがわかればよいのではないでしょうか。
フォームから呼ぶのであればフォームと同じ連番をつけておけばOK

マクロ

個人的にはあまりなじみがありませんが、連番が合っていれば間違えないかと。

VBA

いわゆる個別処理か、共通処理かでモジュールは分けると思いますので
あとは一般的なコーディング規約でいいのではと思います。

まとめ

だらだらと列挙しましたが、結局のところ「命名」に尽きると思っています。

後で見た時、またはほかの人が見た時に相関性がわかるのが重要ですね。

余談

私の場合、ある程度作り込んだ後はデータとプログラムのファイルを分けてます。
プログラムのファイルからデータのファイルへリンクを張ることで実現。
プログラム改修などの際にはプログラムファイルだけを更新すればよいため利便性が高いです。

Accessにてレコード超過によりデータが作成できなかった件 (未完結)

原因究明できていないため、参考までとしてください。

Accessの2GB制限と実際に投入できるデータサイズに対する実証および考察です。

ことの経緯

社内SE作業で、10,000件×10,000件の組み合わせデータを作成する必要があり、Excelではできず、Accessに頼ることにしました。

Excelにある2つのシート(各10,000件)をAccessへインポート

その後、クエリで2つのテーブルをCROSS JOINで新テーブルへINTO(1億件INSERT)

すると、謎のエラー。

accdbファイルを見ると、2GBを超えていました。Accessは2GBまでしかサポートしていないため、エラーとなったようです。

「ま～データ多いからな～」と思いつつ、今はMySQLへリンクテーブル張ってそこへ流し込んでいる段階なのですが、時間があるのでこの記事を書く事にしました。

2GBって何バイト？

改めて計算したところ、20億バイト。

これがテーブル定義なので、20Byte × 1億 件 でざっくり計算しても超えてしまいますね。

なので、母数を減らすことにしました。

10,000件 × 2,500件

これであれば、500MBに収まる試算です

でも同じエラーが出るよ？？？

レコードの容量計算を行うための情報収集。
ディスクのブロックサイズによって利用されるディスク領域が異なる。と。NTFSの情報を参照します。

fsutil fsinfo ntfsinfo c:

4096と出ました。つまり、4KB
今回の直接の原因にはならなそうです。

ここまでで一旦まとめ

今回の作業の目的はマトリックスデータを作って利用することであり、Accessを使ってどうこうという事ではなかったため、これ以上の深追いはしないことにしました。

考えられることとしては
１）Access内部で一時領域にディスクを利用していてそれでオーバーする
２）テーブルのインデックスなど、付加情報も容量見積に入れる必要あり
３）SELECT INTO (つまり手抜き)なので、結果作成されるテーブルのフィールド型が想定と違う？　→その後データ件数を減らして実証しましたが、想定通り、元のテーブルの型を引き継いでいました

あたりが考えられますが、その詳細については今後必要に応じて調べていこうと思います

Microsoft AccessのモジュールをVSS管理している場合のTips

VBA系のプログラムを利用して開発する場合、ソース資産等の管理にひと手間必要ですが
Accessの場合、追加ソフトを入れることでVisualSourceSafeへの接続ができるのでメモ。

今回は、Access2010です。Access2007でもできるようです。

【Access2010で使う場合に必要なソフトのインストール】

Microsoft Access 2010 ソースコード管理　をインストールするとリボンに機能が現れます
https://www.microsoft.com/ja-jp/download/details.aspx?id=6840

【VSSからデータを取得する場合】

1) Accessを起動
2) 「ソース管理」リボンにある「SourceSafeから作成」を選択するとVSSが起動する
3) VSSにてパスを指定すると、関連ファイルおよびデータベースファイルが作成される

【データをVSSから切り離す場合】

1)  リボン「ファイル」を選択「情報」から、「データベースの最適化/修復」を選択
2)  「最適化したデータベースをSource Code Controlから削除しますか？」と聞かれたら「はい」を選択