The Sparx .qea round trip
What a .qea file actually is, what survives a trip out of one tool and into Enterprise Architect, and the parts that never make it.
6 min readXMI 2.5.12 of 3
01A database, not a document
The single most useful fact about a .qea file is that it is a SQLite database. Not a zip of XML, not a proprietary binary blob - a file you can open with any SQLite client and query. Inside it is Enterprise Architect's repository schema, the same schema Sparx uses when a team puts its repository on a shared SQL Server instead of a file.
That is why the format exists at all. The older .eap and .eapx files were Jet and Access databases, which tied the whole tool to Windows and to a database engine Microsoft stopped caring about. SQLite runs everywhere, which is what makes it possible for a browser-based tool to write a file Enterprise Architect will open.
02What a round trip preserves
| Element | Notation | What it means |
|---|---|---|
| Elements | Preserved | Name, type, stereotype, notes and package placement, in t_object. |
| Attributes and operations | Preserved | Their own tables, keyed to the owning object. Types and multiplicity included. |
| Connectors | Preserved | Both ends, the relationship kind, and the role and cardinality on each end. |
| Diagram layout | Preserved | The reason to prefer .qea over XMI: coordinates are first-class rows rather than an extension. |
| GUIDs | Preserved | Every element keeps its identifier, which is what lets a later re-import update rather than duplicate. |
| Baselines and version history | Lost | A generated file is a first version. Nothing outside the tool can reconstruct a history it never had. |
The GUID row is the one worth dwelling on. Because element identifiers survive, a genuine round trip is possible in principle: export, edit elsewhere, re-import, and the tool can match the incoming elements to the ones it already has rather than creating a second copy of everything. Whether it does is a property of the importing tool, not of the file.
03Doing it without losing a Friday
Open the exported file in a SQLite browser before you open it in Sparx. Count the rows in t_object and compare against the number of elements you expected. A file that is missing elements is obvious in five seconds there and takes half an hour to notice in a modelling tool.
Keep the package structure shallow on the way out. Deep nesting is where foreign-key mistakes hide, and a flat set of packages that you re-organise inside Enterprise Architect afterwards is faster than debugging a hierarchy that arrived half-attached.
Do not expect the file to carry a process. Baselines, review comments, requirement traceability and project-management data are all real parts of an Enterprise Architect repository and none of them exists in a model that was built somewhere else. A generated .qea gives you the model; the process starts over.
In one line each
- 01A .qea file is a SQLite database holding Enterprise Architect's repository schema.
- 02It replaced .eap and .eapx to escape Access, which is why non-Windows tools can write it.
- 03Layout is preserved because coordinates are rows in the schema, not an optional extension.
- 04GUIDs survive, which is what makes a genuine round trip possible rather than a duplicate import.
- 05Baselines, reviews and requirement links are repository process, and no generated file has them.
04Common questions
What is a .qea file?
A SQLite database carrying Enterprise Architect's repository schema. It replaced the Access-based .eap and .eapx files as Sparx's default local format, which is why it opens on macOS and Linux tooling where the older ones did not.
What is the difference between .eap and .qea?
The container, not the contents. Both hold the same repository schema; .eap and .eapx are Jet or Access databases tied to Windows, while .qea is SQLite and portable. Sparx can convert between them, and the model inside is unchanged by the conversion.
Does a .qea round trip preserve diagram layout?
Yes, unlike XMI, because layout is part of the schema rather than an optional extension. Diagram objects carry their coordinates in the same database as the elements they show, so a file written correctly opens with its views intact.
Related reading