Microsoft Access data recovery support.

[pplupo]

Description

This PR introduces native support for importing and reading database and data-warehouse files directly into the spreadsheet editor. It adds unified data-extraction pipelines for:

• Microsoft Access Databases (.mdb)
• SQLite Databases (.sqlite, .db)
• DuckDB Databases (.duckdb)
• Parquet Files (.parquet)

Motivation

For a sovereign and independent office suite, true data sovereignty means ensuring users are never locked out of their historical data. Legacy Microsoft Access (.mdb) databases hold decades of critical public, enterprise, and personal records. Relying on proprietary or Windows-exclusive software to open them poses a severe risk to long-term data accessibility. By natively supporting .mdb file reading, Euro-Office guarantees that users can independently recover and migrate their historical data at any time.

Furthermore, once the unified database-to-spreadsheet conversion pipeline was built to support .mdb recovery, it was a natural and low-overhead extension to include support for modern embedded databases like SQLite, as well as analytics-heavy formats like DuckDB and Parquet. This empowers data analysts and researchers to quickly inspect massive datasets directly from the comfort of their office suite, bridging the gap between legacy data recovery and modern data science.

Technical Details

• Vendored libmdb (from mdbtools) directly into the source tree to ensure consistent cross-platform builds without relying on fragmented system packages (resolves iconv and locale struct mismatches).
• Integrated libduckdb for reading DuckDB files and efficiently querying .parquet files via DuckDB's view functionality.
• Added standard SQLite file parsing.
• Built a unified translation layer that iterates through database tables and seamlessly converts them into individual worksheet tabs within the spreadsheet engine.

[chrip]

Thanks for putting this together, @pplupo and for the care that clearly went into it. The mdbtools LGPL handling and the engine abstraction are solid pieces of work.

But my personal read is that this isn't a fit for core. Pulling database recovery into core means a bigger shipped build, a new parser of untrusted binary input in our default attack surface, and ongoing maintenance of the DB engines for something we don't currently have a use case for. That's a real cost, and I don't think it's one we should take on right now.

I'll raise this PR at our next team meeting and put the scope question to everyone. I'll follow up here once we've talked it through.

[pplupo]

@chrip Thanks for taking the time to review this.

Regarding the attack surface, the risk is heavily mitigated by how the abstraction works. The parser strictly extracts raw data from these files; it does not execute any embedded logic or binaries. The extracted information is purely treated as a data source and fed directly into the spreadsheet engine.

On the question of the use case, this feature directly addresses the core philosophy of Euro-Office: true data sovereignty. For users with decades of critical records locked in MS Office Access mdb files, we need to provide an independent recovery path to break that vendor lock-in. There is a demonstrated market need for this, which is why alternatives like LibreOffice already support it. It is a powerful enabler for users migrating to our ecosystem.

IMHO, this is a must-have.

I appreciate you bringing this to the team meeting, and I look forward to hearing the team's thoughts.

[chrip]

@pplupo This PR prompted a discussion about what Euro-Office stands for and the direction we want to take it in. As the outcome, I was convinced that we shouldn't reject a feature this valuable. Freeing data from formats like Access is exactly what it is about, and we build with the community, so a useful feature that someone is willing to implement belongs here.

The one issue is timing. We're mid-stabilization on the project right now and don't want to land a change this size on an unstable trunk, so we're putting it on hold rather than merging now. We'll keep the PR open and pick it back up once things are stable.