Storing Files in Access: Attachments vs. OLE Objects vs. File Paths

At some point, almost every Access database needs to associate files with records — a PDF contract linked to a customer, a photo attached to a product, a scanned document tied to an invoice. Access gives you three approaches, and choosing the wrong one can cause serious problems down the road.

Option 1: OLE Object Fields (Avoid)

OLE (Object Linking and Embedding) Object fields were the original way to store files in Access. They embed the file directly in the database using Windows OLE technology.

Why you should avoid OLE Object fields:

• Massive file size inflation — OLE embeds files with significant overhead. A 100KB image stored as OLE can consume 500KB or more in the database.
• Requires the source application — to view an OLE object, Windows must launch the application that created it. A Word document requires Word; a PDF requires a registered PDF viewer.
• Corruption risk — OLE objects are a common source of database corruption, especially in multi-user environments.
• No thumbnail preview — you cannot display OLE images directly in forms without complex workarounds.
• 32-bit limitation — OLE objects do not work reliably in 64-bit Access.

The only reason to use OLE today: maintaining an existing database that already uses OLE objects and cannot be migrated.

Option 2: Attachment Fields (Use with Caution)

The Attachment data type was introduced in Access 2007 as a replacement for OLE Objects. It stores files directly in the database without OLE overhead.

Advantages:

• More efficient storage than OLE (files are compressed)
• Can store multiple files per record
• Images can be displayed directly in Image controls on forms
• No dependency on external applications for storage (only for viewing)

Disadvantages:

• Still bloats the database file — a database with thousands of attachments can grow to gigabytes
• Attachments are not accessible outside of Access — you cannot browse to the file in Windows Explorer
• Difficult to back up individual files — you must export them through Access
• Cannot be indexed or searched by content
• The 2GB Access file size limit applies to the entire database including attachments

When Attachment fields are appropriate:

• Small databases with a modest number of small files
• Files that are truly inseparable from the record (e.g., a signed form that belongs to exactly one record)
• Situations where the database is the only place the file needs to be accessible

Option 3: File Path References (Recommended)

The most scalable approach is to store files on the file system (a network share, SharePoint, or cloud storage) and store only the file path in the database.

Advantages:

• Database stays small — only a text path is stored
• Files are accessible outside of Access — users can browse to them in Windows Explorer
• Files can be backed up independently of the database
• No file size limitations (beyond the storage system)
• Files can be opened by any application, not just Access
• Easy to migrate to a different storage system by updating the paths

Disadvantages:

• Files can be moved or deleted independently of the database, breaking the link
• Requires a consistent, stable file share path
• No built-in file management — you must manage the files yourself

Implementation:

Add a text field to your table (e.g., DocumentPath, PhotoPath) and store the full file path:

\\server\documents\contracts\contract_12345.pdf
C:\Users\Shared\Photos\product_001.jpg

To open the file from a form button:

Private Sub btnOpenDocument_Click()
    If Not IsNull(Me.DocumentPath) Then
        Application.FollowHyperlink Me.DocumentPath
    Else
        MsgBox "No document attached to this record."
    End If
End Sub

To display an image in an Image control:

Private Sub Form_Current()
    If Not IsNull(Me.PhotoPath) Then
        Me.imgPhoto.Picture = Me.PhotoPath
    Else
        Me.imgPhoto.Picture = ""
    End If
End Sub

Hybrid Approach: SharePoint or Cloud Storage

For modern deployments, consider storing files in SharePoint or OneDrive and storing the SharePoint URL in the database:

https://company.sharepoint.com/sites/contracts/Documents/contract_12345.pdf

This gives you:

• Cloud accessibility (files available from anywhere)
• Version history (SharePoint tracks file versions)
• Permissions (SharePoint controls who can access files)
• Integration with Power Apps and Power Automate

Choosing the Right Approach

Scenario	Recommended Approach
Small number of small files, simple database	Attachment field
Many files or large files	File path reference
Multi-user, network database	File path reference (network share)
Cloud/mobile access needed	SharePoint URL reference
Legacy database with OLE objects	Migrate to file paths

Migrating from OLE to File Paths

If you have an existing database with OLE Object fields, migrating to file paths is worth the effort:

1. Add a new Text field for the file path
2. Write VBA to export each OLE object to a file and save the path
3. Verify the exported files
4. Remove the OLE Object field

The export process requires VBA and varies by the type of OLE object. For images, the process is relatively straightforward; for other file types, it can be more complex.

Conclusion

File path references are the right choice for the vast majority of Access databases. They keep the database small, files accessible, and the system maintainable. Reserve Attachment fields for small-scale use cases where the simplicity outweighs the limitations, and avoid OLE Object fields entirely in new development.