C++ アプリケーションをフロントエンドとしてのみ使用する予定で、ユーザーが Access 自体でデータベースを開くことを想定していないAttachment
場合は、フィールド タイプの使用を避けることをお勧めします。代わりに、[Attachments] テーブルと親テーブル (フィールドの使用を検討していた場所) の間に一対多のリレーションシップ (外部キー制約) を持つ [Attachments] という名前の別の子テーブルを使用しAttachment
ます。OLE Object
次に、ドキュメントを生のバイナリ データとして子テーブルの (ロング バイナリ) フィールドに保存します。
フィールド型には、Access UI を使用するアプリケーションにいくつかのAttachment
利点があります。Attachment
1 つのデータベース レコードへの複数の添付ファイルのサポートは、コントロールを Access フォームにドロップするのと同じくらい簡単です。添付ファイルにはデータシート ビューからもアクセスできますが、表示されるのは「ペーパー クリップ」アイコンだけです。
添付フィールドはコードから操作できますが、ACE DAORecordset2
オブジェクトを使用する必要があります (例はこちら)。レコードごとに複数の添付ファイルを保存できるようにするために、Access データベース エンジンは非表示の子テーブルを使用します。「魔法の」フィールド名修飾子 (例: ) を使用して一部の情報を SELECT クエリに取り込むことは可能ですField1.FileName
が、ADO も ODBC も添付ファイル フィールド エントリを INSERT または UPDATE できません。
アプリケーションで Access UI を使用しないため
- 添付ファイル フィールドが提供する利点の多くを使用することができなくなります。
- C++ アプリから ACE DAO を介して Attachment フィールドを操作することはできますが、面倒です。
フィールドを使用しないことで見逃す可能性のある (おそらく) 重要な利点の 1 つAttachment
は、Access データベース エンジンがフィールド内のファイルを自動的に圧縮しますが、Attachment
フィールド内の未加工のバイナリ データはOLE Object
圧縮されずに保存されることです。保存しようとしているファイルがすべて圧縮形式 (JPEG、.docx、.xlsx など) である場合、これは問題になりません。ただし、大量の大きなドキュメントを圧縮されていない形式 (.txt、.rtf など) で保存する場合は、ファイルの肥大化が問題になる可能性があります。その場合、C++ アプリでそれらのドキュメントを保存する前に (おそらくGZipStreamを使用して) 自動的に圧縮し、取得時に圧縮解除することができます。