Upgrading Blitz Report™ for Oracle APEX from the classic application

Introduction

This guide is for the database administrators and Blitz Report administrators of an installation that runs the classic Blitz Report application, application 131, and moves to Blitz Report for Oracle APEX 2.0, application 140. Application 131 is removed from the workspace, application 140 is imported into it, and the upgrade converts the Blitz Report objects of the parsing schema in place. Everything this upgrade shares with any other installation is in the Installation Guide, which this guide links to.

To see which application you run, connect as the parsing schema:

select aa.application_id, aa.alias, aa.application_name, aa.owner, aa.workspace
from apex_applications aa
where aa.application_id in (131,140);

Result	What to do
Application 131, no application 140	Follow this guide. `owner` is the parsing schema and `workspace` the workspace of every step below.
Application 140 with the alias `BLITZ_REPORT`	Follow chapter 11 of the Installation Guide.
No row	Blitz Report is not installed here, or the schema is not the parsing schema.

In the App Builder, application 131 also lists a page numbered 600 or higher for each report that has been run.

1 What stays and what the upgrade changes

Removing application 131 as chapter 4 describes leaves the database objects as they are. The upgrade then converts them in place.

1.1 What stays

Item	Detail
Reports, lists of values, categories, assignments	Kept, with the changes of 1.2.
Templates	Kept, including those users created on delivered reports.
Runs	Kept, with their outputs and logs.
Schedules	Kept. Each is a scheduler job of the schema that names the schedule, not the application, so it keeps its times and runs under application 140.
Users and access	Blitz Report users, their access levels and template access are kept. APEX accounts belong to the workspace and are not touched.
Profile option values	Kept, except those named in 1.2.
License	Company and key are kept. The upgrade records only the version and build date and installs no trial key.

1.2 What the upgrade changes

Item	Change
Delivered reports	The reports and delivered templates of the categories Enginatics and DBA Diagnostics Pack are replaced by the shipped versions (Installation Guide, chapter 11). The delivered report DBA Objects 11g is deleted. The delivered report Blitz Apex Parameter Page Mapping stays in the list and has no use in 2.0.
Generated parameter pages	They are removed with application 131.
Profile options deleted with their values	The settings for the XLSX font, font size, orientation, sheet header and footer, minimum column width, cell borders and tooltips; parameter dialog width and modal page; download all files; home page row count; history page refresh interval; and Blitz Report Fusion Password.
User preference profile options	Show all templates, show hidden parameters, show log instead of output, disable the run button after submission, the SQL editor double-click, list of values history days and start tab: site-level values are deleted, user values stay.
Default password and sender address	The site values of Blitz User Default Password and Blitz Report From Email Address are deleted where they still equal the shipped ones. A value you set stays.
Assignments	Level codes are stored as words. On an installation that still stores the Enabled flag of assignments, an assignment without a value becomes active: review any you have switched off.
Report settings	A report’s application server output directory is dropped, since no run of 2.0 reads it. Its Server Output Directory stays.
Database objects	The package `XXEN_BIP_CATALOG` is dropped: the BI Publisher catalog browser is not part of 2.0. The plug-in package `APEX_ENHANCED_LOV_ITEM` is dropped, unless another application of the workspace uses the plug-in; then it stays. Columns, tables, profile options, the report search indexes where they are missing, the Excel add-in builds and its webservices are added.

2 What changes for users

Topic	What users get
Application and address	Application 140 carries the alias `BLITZ_REPORT`, the alias application 131 is delivered with, so the address ending in `/blitz_report` stays (Installation Guide 6.1). If your application 131 carries another alias, the address changes to that form.
Bookmarks	A bookmark that names application 131 (`f?p=131:...`) or one of its pages (`.../blitz_report/home`) stops working. Users bookmark the address above.
Interface	One page holds the Reports page, the run screen, Runs, Schedules, Setup, the template editor and Administration. The User Guide describes them.
Parameters	A report’s parameters show on the run screen. Application 140 generates no parameter pages.
Sign-in	The same APEX accounts sign in through the delivered scheme Oracle APEX Accounts. If application 131 uses Oracle DB Accounts or the Google Authentication Scheme, make that scheme current in application 140 after the upgrade, and after every later upgrade: Shared Components, Authentication Schemes, open the scheme, Make Current Scheme.
Changes made in the App Builder	Anything you changed in application 131 itself, such as session limits, Embed in Frames or pages of your own, is not carried over. The export of 3.2 is the record of it.
Excel add-in	The upgrade installs the add-in builds and its webservices (Installation Guide 8.1). An administrator adds an environment in Administration > Excel Add-in (8.2), then users download the add-in and their connection file on the run screen (8.3). An OAuth client `xxen_webservices` that already exists keeps its id and secret, so its connection files keep working.
Oracle Fusion	The values of Blitz Report Fusion Integration, Fusion URL, Fusion Username and Fusion Object XDM Path stay. Blitz Report Fusion Password is deleted: ERP (Fusion) reports sign in to BI Publisher with the user’s Fusion token or, in a scheduled run, with a signing key, and they fail until chapter 9 of the Installation Guide is done. Application 140 can also be opened from Fusion (9.3), which application 131 does not offer. Showing it inside a Fusion page needs the framing script after every upgrade (9.4).

3 Before the upgrade

3.1 Prerequisites

The database and APEX meet chapter 1 of the Installation Guide: Oracle Database 19c or higher, character set AL32UTF8, UTF8 or WE8MSWIN1252, APEX 22.2.3 or higher.
The release zip from https://www.enginatics.com/blitz-report-apex-download/ is unzipped on your own computer.
A DBA has run scripts/check_apex_grants.sql of the zip, with the schema of application 131 set at its top (Installation Guide 3.1). It must end with 0 missing: run the grants it lists. Section 5 must list no invalid object: the upgrade fails on any invalid object of the schema, your own included.
select uos.pattern, uos.status from user_ords_schemas uos;, as the parsing schema, returns no row, or the base path xxen and ENABLED. Another mapping stops the upgrade (Installation Guide, chapter 13).
You have a workspace administrator’s sign-in.
Nobody works in Blitz Report and no schedule is due. From the removal of application 131 until the upgrade ends, users cannot sign in, and a schedule due in that time may fail; its next run is not affected.

3.2 Backups

Take both after users have stopped. You need both to go back (chapter 8).

The export of application 131. In the App Builder, open application 131 and choose Export / Import, then Export. On the page Export Application, set Export Supporting Object Definitions to Yes, click Export and keep the file f131.sql.
A backup of the database. Once the upgrade has started, nothing else brings back the tables as application 131 needs them.

4 Removing application 131

Warning: remove the application only. Do not deinstall its Supporting Objects. The deinstall script of application 131 drops every XXEN_ table, view, package, sequence, type and synonym it finds, which destroys the reports, templates, runs, schedules, users, profile option values and the license. It is not limited to the parsing schema: XXEN_ objects of other schemas go as well. It purges the tables from the recycle bin, drops the scheduler jobs, the program and the job class, and removes the PDF directory and Java permission. Nothing is left to upgrade, and only the backup of 3.2 brings the data back. For the same reason, never run Supporting Objects > Deinstall Supporting Objects on this installation.

In the App Builder, open application 131 and choose Delete this Application.
On the page Deinstall Application, check that Application shows 131.
Under Deinstallation Options, tick Remove Application Definition only. Leave Deinstall Supporting Objects unticked.
Click Deinstall.
On the page Confirm Delete, check that it names application 131 and click Permanently Delete Now.

Then confirm, as the parsing schema:

select aa.application_id, aa.alias
from apex_applications aa
where aa.application_id=131 or aa.alias='BLITZ_REPORT';  -- expect no rows
select count(*) "Blitz Reports" from xxen_reports xr;    -- expect your report count

Application 140 cannot be imported while another application of the workspace holds the alias BLITZ_REPORT. If the first statement returns a row, change that application’s alias or remove it.

5 The upgrade

Sign in to the workspace of application 131 as a workspace administrator.
Open App Builder > Import and select app_export/f140.sql from the unzipped release.
After the upload, click Next on the confirmation of the file.
Review the settings: the workspace, Parsing Schema the schema of application 131, and Install As Application set to Reuse Application ID 140 From Export File. The wizard preselects Auto Assign, so this setting must be changed.
Click Install Application. This takes several minutes.
If a Credentials page follows, click Next.
On the Supporting Objects step the wizard finds the existing objects and asks Upgrade Supporting Objects. Choose Yes. If it asks Install Supporting Objects instead, it has not found them: cancel, and check the parsing schema and the privilege check of 3.1.
Continue through the validations and click Install.

The upgrade scripts run, including the refresh of the delivered reports (Installation Guide, chapter 11). Leave the browser window open until the wizard’s last page. The wizard does not show the messages of the scripts or report their errors. Open application 140 in the App Builder, choose Supporting Objects and, under Tasks, View Install Summary: Statements with Errors must be 0 on the Report Total line at the end of the report. The checks of chapter 6 are the proof that the upgrade worked.

If you use PDF output, install the release’s converter by hand (Installation Guide 10.4). It needs a Linux or Unix database server.

6 Checks afterwards

Result. Run the statements of Installation Guide 6.2. The report count differs from yours only by the delivered reports of 1.2.
Version and build date. The footer of every page reads Blitz Report 2.0 with the build date, for example Blitz Report 2.0 (2026-11-10). The Reports page shows Blitz Report 2.0 under the greeting, and Setup > Tools > License Key shows Version and Build. If they differ, the upgrade did not finish (6.3 and chapter 7).
A report. Sign in at the address (6.1). Run one of your own reports and a delivered one to Excel, and open one of your templates.
License. Setup > Tools > License Key shows the status. A trial key keeps its expiry date, and a later key comes from Enginatics (7.2).
A schedule. The Schedules page lists your schedules with their next run. After that run, its output is on the Runs page.
Housekeeping. Administration > Housekeeping shows the monitor’s schedule and the retention days. Set what is missing (7.5).
Profile options. In Administration > Profile Options, set Blitz User Default Password (7.1), Blitz Report From Email Address (7.3) and Blitz Report Server Time Zone (7.4) if they are empty.
What you use. The authentication scheme, the Excel add-in and Oracle Fusion, as chapter 2 describes.

7 If the upgrade stops

Do not import application 131 again into a schema the upgrade has changed (chapter 8). Users cannot sign in until the upgrade has finished. The version and build date are recorded last, so the Reports page and the footer differ until it has finished.

When the upgrade fails, the wizard ends with Installation of database objects and seed data has failed. The scripts can run again, so import again and answer Yes.

8 Going back

The two backups of 3.2 restore application 131. The export alone is enough only until the upgrade starts. After that the tables are converted, the packages are replaced and the plug-in package may be gone, so application 131 cannot run on them.

The upgrade has not started (the wizard has not run the Supporting Objects):

If application 140 was imported, open it in the App Builder, choose Delete this Application and tick Remove Application Definition only.
Open App Builder > Import and select f131.sql, with the same parsing schema and Install As Application set to Reuse Application ID 131 From Export File. On the Supporting Objects step choose No.

The upgrade has started or finished:

Make sure nobody works in Blitz Report, then delete application 140 as above.
Restore the parsing schema to the state of the backup. Runs and changes made after the backup are lost.
Import f131.sql as above, then sign in and run a report.

9 Getting help

Write to [email protected] and say that you are upgrading from the classic application. Send the wizard’s last message and the result of the statements of 6.2.