This article introduces SQLVantage, a lightweight web-based reporting system (v1.0.2) that ties together SQL queries, parameter forms, and result presentation into a single standard workflow, so the entire report lifecycle stays manageable and traceable. It walks through the deployment experience, the administrator and end-user workflows, and the three modules of the report designer (SQL/FORM/HTML), along with licensing, permission isolation, and other design details, before concluding with suitable use cases and caveats.
An out-of-the-box web reporting tool that covers the full pipeline of data query, parameter forms, and result presentation.
In day-to-day enterprise operations, data reports are indispensable. Whether it is financial reconciliation, sales analysis, or operations monitoring, almost every department relies on some form of report output.
In practice, however, we often run into these problems:
That is why a lightweight reporting system that centrally manages report definitions, supports parameterized queries, automatically generates results in multiple formats, and provides permission isolation becomes essential.
I recently came across a reporting system called SQLVantage (version v1.0.2, released 2026-07-15) that addresses exactly these pain points. Its design philosophy is clear: a standard process ties together the three tasks of SQL query, parameter form, and result presentation, making the entire report lifecycle traceable.
In this article, based on its official documentation, I will walk through its core design and usage paths to help you quickly determine whether it fits your team.
SQLVantage is a purely web-based reporting system. Its key characteristics are:
| Concept | Description |
|---|---|
| Report | One report = SQL query + parameter form (FORM) + result presentation (HTML) + three format JSON configurations, attached to a “responsibility” |
| Responsibility | A report catalog corresponding to the responsibility concept in Oracle EBS, used to group reports by module for users |
| Parameter | Query conditions (date, customer, organization, etc.); once submitted by the user, they are bound to the SQL as named parameters |
| Request | A single report execution task submitted by a user; the system executes it asynchronously and generates result files |
| License | The License file controls the report count limit and the validity period |
The system defines two roles with completely separate entry points and permissions:
SQLVantage's deployment approach is remarkably pragmatic.
Extract the release package to any directory (e.g., D:\SQLVantage) and double-click SQLVantage.exe to start it. It listens on 127.0.0.1:8080 by default — just open it in a browser.
Extract to /opt/sqlvantage, grant execute permission, and run it in the background with nohup or systemd. The default port is likewise 8080.
On first startup, the system automatically performs the following actions, which is very friendly for ops staff:
This design minimizes the cost of trying it out from scratch.
Administrators can create regular users (the normal role) and set their status to active or inactive (disable on departure — no need to delete the account).
Responsibility management mirrors the responsibility concept in Oracle EBS and can also be created manually. Every report must be attached to a responsibility, so that on the regular user side, the report menu is automatically grouped by responsibility — a clean experience.
Reports have three states:
A released report cannot be deleted directly; it must first be switched to Draft or Discard — a design that effectively prevents accidental deletion of production reports.
The list page supports double-clicking a cell to edit the name, description, or status directly — a small detail that improves efficiency.
The license file conf/license.dat controls the report count limit and the validity period. When unlicensed or expired, the system allows at most 3 reports; beyond that, no new reports can be created and no requests can be submitted.
This mechanism is practical for commercial or internal trial scenarios — full functionality is preserved while a reasonable threshold is enforced.
If there is one feature of SQLVantage worth spending time on, it is the report designer.
It breaks report development into three independent yet interlocking modules, all completed in a single interface.
From the report list, click the “Code” button (purple) in a report row, and a large designer occupying about 98% of the screen pops up. The interface consists of:
This “code on the left + configuration on the right + live preview” layout is very intuitive for developers.
Uses Oracle syntax; query conditions are expressed as named parameter placeholders of the form :param_name:
SELECT company_name, ou_id, amount FROM fnd_ou_tl WHERE ou_id = :P_OU_ID
Here, P_OU_ID must match the parameter name defined in the FORM module.
The right-hand panel lets you configure, for each column:
This configuration directly determines how professional the Excel export looks — localized headers, right-aligned numbers, thousands separators, and percentage formats can all be set here in one pass.
In other words, once the column metadata is configured here, the quality of the Excel export no longer depends on additional back-end code.
This is the entry point for report interaction. Each row of the parameter configuration table on the right defines one query parameter:
| Field | Description |
|---|---|
| Parameter name field | must exactly match the :param_name in the SQL |
| Display label label | the text shown on the form |
| Widget type type | text / number / select / radio / date / month / datetime / hidden / temp |
| Static options static_options | format key:value,key:value |
| Dynamic API / SQL | supports {variable} placeholders to implement parameter cascading |
This is a very practical feature of the FORM module: when a downstream dropdown depends on an upstream parameter (e.g., the department list can only be loaded after selecting an organization), you can reference placeholders such as {P_OU_ID} in api_url or query_sql.
Once the user changes the upstream value, the system automatically refreshes the downstream options — no additional JavaScript code required.
Below the right-hand panel there is also a live preview area; as soon as the parameter configuration is done, you can see the actual rendering, and with one click you can “copy and apply” the generated HTML code into the editor.
Once a report finishes executing, in what form are the results presented to users? The HTML module defines this layer.
The HTML view widget configuration on the right supports multiple display blocks, each including:
In the end, when the user downloads the HTML result, the system dynamically renders a complete page with tables, charts, and KPI cards, and the query parameters are echoed above the results.
This design gives the presentation layer of reports configurable capability as well — no separate front-end page needs to be written for each report.
The whole process runs in a single line:
The regular user's path is very simple:
Queued → Processing → Success → Error → Terminated (timed out)
The backend polls queued tasks every 3 seconds; the concurrency is adjustable, with a default of up to 3 tasks running simultaneously. The default timeout is 30 minutes and can be adjusted in the configuration.
SQL, FORM, and HTML each have both “code” and “format JSON” data, leaving room for future version management and template reuse.
This is not “export first, post-process later” — the Excel styling is decided at design time. This means report designers have full control over output quality, without relying on extra post-processing scripts.
Parameter dependencies are implemented via the placeholder mechanism, which lowers the front-end development barrier.
Regular users can only see their own request records; administrators can see everything. When an ERP-authenticated user submits a request, the system also validates OU/ORG organization permissions to prevent unauthorized access.
All business data is stored in conf/data.dat, and result files are generated under the data/ directory. Migration only requires copying the conf/ and data/ directories — very clean.
My overall impression of SQLVantage: pragmatic, restrained, and easy to use.
It does not blindly chase an all-in-one, feature-everything product. Instead, centered on the core scenario of “reporting,” it strings together SQL management, parameter interaction, result presentation, and permission isolation into one clear, complete pipeline.
For teams struggling with report management, it offers a solid reference solution — usable directly as a production tool, and also valuable as a learning sample for understanding how a lightweight web reporting system is designed.
If you are also looking for a simple, easy-to-use, self-deployable reporting system, give SQLVantage a try.
This article is based on the official user documentation of SQLVantage v1.0.2 (released 2026-07-15). For more details, see the multilingual documentation bundled with the project (docs/ directory).