Rebuild a report without Enterprise Architect

Goal

Rebuild a separate reporting database, or the rows behind Parquet files, from the extract kept by the last build, with no EA connection. This is for a data steward defending a disputed figure, someone retesting a result against the exact rows that produced it, or someone rebuilding a reporting database that was lost without disturbing a shared repository. You end with the reporting data as it stood at the instant of that build, rebuilt from its own rows, and the as-of time of the kept extract it came from.

Where it runs

This scenario needs the MCP server. EA does not need to be running and is not connected. Rewriting Parquet files from the rebuilt rows needs local code execution.

How it works

A build of a separate reporting database, or of Parquet files, reads EA's tables through Enterprise Architect. That is the slowest and least repeatable step, and it is the only record of what the repository held at that instant. So every such build keeps what it loaded: one file beside the reporting profile, the kept extract. It holds:

• the rows the build loaded, after the left-out packages were cut, "(excluded)" stand-ins included;
• the scope and the counts, the links that crossed into left-out areas, and the reporting-preflight flags you continued past;
• the queries issued to EA, with their row counts and timings;
• a run id and the time the extract was taken;
• the technology's definition, so a replay needs no installed technology.

Each build replaces the kept extract, so only the last run is kept. Left-out content is never written to disk.

Replay (replay_reporting_database, Reporting business layer) rebuilds the reporting database, or the Parquet rows and the definition file, from the kept extract, with the same writes as a build and no EA connection. It reproduces that build's instant. It is not a refresh: to bring the data up to date, run a build or a refresh (Build a reporting database). The kept extract itself is not replaced by a replay.

Three problems this solves. A disputed figure cannot be settled a month later by "re-run it and see", because the repository is different now, and the difference is exactly what is in dispute. A fix can be retested against the rows that exposed the fault. And a lost reporting database can be rebuilt without touching a shared repository.

Views in the EA database have no kept extract: they read EA's tables as they stand, so there is nothing to replay. To regenerate them, rebuild the layer. The kept extract is not an EA baseline either: a baseline is EA's own package-level snapshot inside the repository (Protect a change with a baseline); the kept extract is a file of a scope's rows at an instant.

Before you start

• A reporting profile whose last build was a separate reporting database or Parquet files, with the kept extract still beside the profile. A profile that has never been built has none, and replay says so.
• For a separate reporting database: SQL Server and the rights described in Build a reporting database. The target must not be a database that holds an EA repository.
• For Parquet files: local code execution to write the files again, as in Build a Power BI model.
• No EA connection and no installed technology are needed.

Steps

1. AI ea-reporting-database identifies the profile, and the build whose figure is in question. You say which profile.
2. AI ea-reporting-database states the as-of time recorded in the kept extract, and checks that it is the build you mean. You confirm. If a later build has replaced it, the earlier rows are gone and that figure cannot be rebuilt from its own rows.
3. AI Power Tools ea-reporting-database replays the build from the kept extract (replay_reporting_database). The result names the kept extract it used and gives the row counts per table and the alignment result.
4. Engine For Parquet files, ea-power-bi writes the files again from the rebuilt rows (Build a Power BI model).
5. AI ea-reporting-database answers the disputed question from the rebuilt data, with the as-of time and the populated count behind the figure. You decide whether the figure holds.

Step 2, the as-of time. Every figure from a replay is a figure as of the time the kept extract was taken, not as of today. Say that time whenever the figure is quoted back.

Step 3, checking a replay. The alignment result comes with the replay. Do not use the value check to confirm a replay: it compares the layer with the repository as it is now, so every change made in EA since the build shows up as a difference.

Prompts to use

Opening:

Follow-ups:

• Evidence: "When was the kept extract taken, what scope did it cover, and how many rows did it keep per table?"
• Parquet: "Rebuild the Parquet rows from the kept extract and write the files again."
• Compare: "How does that figure compare with the live repository today? Tell me which number is which."

Recommended models

Ratings are guidance based on the kind of reasoning the scenario needs, not measured benchmarks.

Checking the result

• Correct. The replay result names the kept extract beside the profile you meant, and its as-of time is that of the build in question. The alignment result is aligned, as it was for the original build. Red flag: a replayed figure reported without its as-of time.
• Complete. The row counts per table equal those the original build reported. For Parquet files, every table has its file again.
• Nothing unintended changed. EA is not connected, so the repository cannot be affected. The kept extract is unchanged. The reporting database or the rows were rewritten, which is what you asked for.

Variations

• Prove a figure. Replay, then run the disputed question against the rebuilt data.
• Rebuild a lost reporting database from the last build, without touching a busy shared repository.
• Hand the evidence over. The kept extract records the scope, the counts, the queries issued and the time. It holds the content you chose to include, so share it only as you would the reporting data.

Limitations

• Only the last build is kept. Each build replaces the kept extract, so a figure from an earlier build cannot be rebuilt from its own rows.
• A build that fails after its extract may already have replaced the kept extract, while the reporting data still holds the previous build. Check the as-of time in the kept extract before relying on a replay after a failed build.
• Not for views in the EA database, which have no extract.
• The kept extract holds included content (names, notes and tagged values of every kept package). Treat it with the same care as the reporting data. Deleting it loses only the ability to replay.