Database Maintenance

The Database Maintenance page shows storage information for the WebReports application database. It also provides tools to reclaim unused database space and import application data from another WebReports database.

Use this page to investigate database growth or prepare a planned migration. It manages the application database; it is not the page for editing the reporting connections used by individual reports.

Open Database

1. Sign in to WebReports with an administrator account.
2. Expand Configuration in the left navigation.
3. Select Database.

Screenshots use fictional demo data. Example settings are not recommended values or a statement of the defaults. Select an image to view its full size.

Database Maintenance showing fictional DemoWebReports storage information and the two manual maintenance actions.

Understand the storage values

Before choosing a maintenance action, review Managing Report and Scheduler Retention in WebReports, statistics retention, and logging cleanup in Configuring Application Settings in WebReports. Retaining less history can reduce ongoing growth; shrinking does not replace a retention policy.

Automatic SQL Server index maintenance

Starting with WebReports 2026.10.12, daily database maintenance reorganizes or rebuilds fragmented indexes for Microsoft SQL Server databases only. This is separate from the manual Shrink Database action.

Shrink the database

Shrinking may reclaim unused space after substantial data removal. It should be a planned action reviewed with the database administrator, rather than a routine response to normal growth.

1. Create a current database backup and confirm that no other database maintenance is running.
2. Choose a period of low application activity.
3. Select Shrink Database only when ready. The operation starts immediately without a confirmation prompt.
4. Review the completion message and database size. Investigate repeated growth with the database administrator.

Import WebReports data

Use import to bring selected application data from another WebReports database into the current installation. Opening the dialog does not start the import.

For an import, the source is the existing WebReports environment whose data you are migrating. The destination is the WebReports environment receiving that data. Plan the migration with the administrators responsible for both environments and back up the destination database before starting.

Locate the Source Database Unique ID

1. Sign in to the source WebReports environment with an administrator account.
2. Open Configuration → Registration.
3. Scroll to the ID section at the bottom of the page and copy the value in the ID field.
4. Keep this value for the Source Database Unique ID field in the destination's import dialog. Use the source environment's ID, rather than the destination installation's ID or the Company ID.

Configuration → Registration: the ID field is at the bottom of the page. Use your source installation's ID; the screenshot contains fictional demonstration values.

Locate the Source Connection String

1. On the source WebReports server, open the production WebReports installation directory using authorized access.
2. Open appsettings.json and locate ConnectionStrings, then the active DefaultConnection entry for the WebReports application database.
3. Copy the complete connection-string value. Do not include the JSON property name, its surrounding quotation marks, or comments. For a SQL Server source, the documented example begins with Server=; keep the full connection string required by your deployment.
4. Keep the value for the Source Connection String field in the destination's import dialog. Use the source application database connection, rather than an individual report's connection profile.

The following is an illustrative fragment, not a complete appsettings.json file or a usable connection string. <SOURCE_VALUE> represents your complete source connection-string value:

{
  "ConnectionStrings": {
    "DefaultConnection": "<SOURCE_VALUE>"
  }
}

If DefaultConnection contains an encrypted value, ask the deployment administrator or BridgeWorks Support for the appropriate usable import connection string. Do not assume the encrypted value can be pasted directly into the import dialog. See Encrypting Your WebReports Connection String in VDM for the related configuration. Keep credentials private and do not change the source configuration just to copy the value.

Open and configure the import in the destination

After collecting the source values, sign in to the destination WebReports environment and open Configuration → Database. Use the source database platform when selecting the database type. For example, a migration from SQL Server to MySQL uses MSSQL as the source type.

Import WebReports Data with source fields and data-category dependencies; source credentials are intentionally blank.

1. Back up the destination database and plan the migration with the administrator responsible for both databases.
2. Select Import WebReports Data.
3. Enter the Source Database Unique ID copied from the source Registration page, select the Source Database Type (MSSQL, MySQL, or Oracle), and enter the complete Source Connection String obtained from the source installation.
4. Select the required data categories. Grayed, selected items are dependencies of other selections; change the related selections if you need to change the dependency set.
5. Review the source, destination backup, selected data, and compatibility before starting.
6. Select Import WebReports Data inside the dialog to start the operation. Do not interrupt application or database connectivity while it runs.
7. Review the result and test the imported reports, assignments, connections, schedules, and other affected features.

The dialog offers connection profiles, API keys, email, roles, reports, schedules, logs, configuration settings, tenants, UDFs, users, report assignments, completed reports, and statistics history. Dependencies protect relationships between the selected records.

In WebReports 2026.10.12 and later, importing configuration settings also migrates the configured Bridgit API key. Review and test the Bridgit configuration after an import.

Connection strings can contain credentials. Keep source credentials out of screenshots and public support material. If import fails, record the error and investigate before retrying.

For a complete SQL Server-to-MySQL walkthrough, see Migrating WebReports from Microsoft SQL Server to MySQL.