Ignition Database Deletion Fails on Alert Profile References

The Ignition Gateway rejected deletion because an alert storage profile still referenced the database connection, and the profile change intended to remove that reference had not been saved.

Where does the delete request stop?

The log follows the operation from the Gateway configuration action to the local configuration database. The first stack trace names the attempted delete; later entries show that the command is sent through Ignition’s clustered-datasource layer; the final database exception identifies why the delete is rejected.

This path distinguishes a rejected configuration change from a failed connection to the database configured in the datasource. The operation reaches the Gateway’s local database, where referential integrity prevents deletion. Changing a remote database host, credentials, or network route does not remove that local dependency.

What does the foreign-key error identify?

The specific constraint is FK_ALERTSTORAGEPROFILEPROPERTIES_DATASOURCE_DATASOURCE, and the reported table is ALERTSTORAGEPROFILEPROPERTIES_DATASOURCE. The constraint name and table point to an alert-storage-profile relationship with the datasource record being deleted. The Gateway is enforcing a foreign key with no delete action: it will not automatically remove or rewrite the dependent reference when the datasource row is deleted.

That is a configuration dependency, not evidence of damaged database contents. The correct resolution is to change or remove the configuration that owns the reference, save that change, and then retry deletion. Do not treat the `DATASOURCES` delete statement as a direction to remove rows manually from the Gateway’s internal database; direct edits can bypass application-level validation and leave configuration inconsistent.

Which log line should determine the next check?

Read the deepest cause in the exception chain. The outer frames identify the web action and the clustered-datasource call, but they do not explain the rejection. Use this decision sequence:

1. If the trace ends at Executing DELETE FROM DATASOURCES without a database cause, collect the full exception and Gateway logs around the failed attempt; the SQL line alone does not identify why deletion stopped.
2. If it reports a cluster response error, follow the nested cause rather than troubleshooting the address alone. In this trace, the next cause is an HSQLDB foreign-key violation.
3. If the cause names FK_ALERTSTORAGEPROFILEPROPERTIES_DATASOURCE_DATASOURCE and ALERTSTORAGEPROFILEPROPERTIES_DATASOURCE, inspect alert storage profile configuration for a reference to the datasource being removed.
4. If the deepest error instead names a different constraint or table, follow that dependency. Do not assume every datasource deletion failure comes from an alert profile.

The cluster-related frames explain how the command was dispatched, while the foreign-key violation explains why the database rejected it. This separation keeps diagnosis focused on the resource that must change: the saved dependent configuration.

How can you confirm the alert profile still points to the old datasource?

Open the Gateway configuration for alert storage profiles and inspect the database connection selected by the profile. Compare that saved selection with the datasource you are trying to delete and with the replacement connection, if one was created. The constraint is tied to the referenced datasource record, so the meaningful check is the profile’s persisted selection, not whether other project settings have already been migrated.

If the profile still selects the old connection, the foreign-key error has a direct explanation: deleting the datasource would leave a dependent profile reference. Change the selection to the intended replacement or otherwise remove the dependency through the supported configuration interface, then save the profile. If you edit a profile but leave without saving, the stored reference remains and the database will continue to reject deletion.

Check every relevant alert storage profile, not only the first profile you remember editing. A different profile can retain the same datasource reference. The named table identifies the configuration area to inspect; it does not expose the profile name or the datasource’s human-readable name in the stack trace.

Why did restarting the Gateway leave the error unchanged?

Restarting the Gateway does not change a saved foreign-key relationship. The datasource record and its dependent alert-profile configuration are persisted in the Gateway configuration database. When the Gateway starts again and deletion is attempted, the same stored relationship still prevents the delete.

In this incident, the operator had changed the alert profile’s database selection but had not pressed Save. The Gateway therefore continued to store the old selection. A restart could not commit the unsaved edit or infer the intended replacement. Treat a restart as a service lifecycle action, not as a way to clear a referential-integrity dependency.

What if the profile appears to use the replacement already?

First verify that the profile change was actually saved. Reopen the profile configuration or otherwise read its persisted setting after saving; an unsaved form value is not proof that the stored reference changed. Confirm that the selection names the replacement datasource rather than the record you intend to delete, then retry the deletion.

If the saved profile configuration shows the replacement but the same named foreign-key constraint still blocks deletion, inspect the other alert storage profiles and re-read the current Gateway logs to verify that the failure is still from the same datasource delete. If no matching dependency is visible, preserve a Gateway backup and the complete exception for vendor investigation. The trace does not reveal a supported manual database repair procedure, so avoid editing internal tables to force deletion.

How should you remove the unused datasource?

Use the following sequence so that the dependent reference is removed before the datasource record:

1. Record the exact datasource you intend to delete and identify its replacement, if applicable. The SQL trace uses a bound identifier and does not show a readable datasource name.
2. Open the alert storage profile configuration and inspect its saved database selection. If it points to the datasource being removed, select the intended replacement or remove that dependency through the Gateway configuration interface.
3. Save the profile change. Reopen or re-read the saved configuration to verify that the old datasource is no longer selected.
4. Retry deletion of the old datasource from the Gateway configuration interface.
5. If deletion still fails, inspect the new deepest database error. Follow its constraint and table rather than repeating the same change or restarting without a configuration change.

Saving first matters because the Gateway’s local database enforces the reference at the moment it processes the delete. Once the saved dependent configuration no longer points to the datasource, that particular foreign-key relationship no longer blocks its removal.

How do you verify that the reference is gone?

Verify both sides of the change. First, read the alert storage profile’s saved configuration and confirm it selects the replacement or has no dependency on the old datasource. Then retry the delete and confirm the Gateway removes the datasource without the named foreign-key violation. If the attempt fails, use the latest innermost exception to choose the next check; a different constraint indicates a different dependent record.

FAQ