BC 22 to BC 25 Upgrade Issue: Orphaned Tables (IDs 5371 & 5372) – Best Fix?

(2) Share

Report

Posted on by ivanrjlg

Hello everyone,

I'm upgrading a Business Central On-Premises environment from BC 22 to BC 25 following the standard upgrade path. However, during the Sync-NAVApp step for the Base Application, I encountered the following error:

pgsql

CopyEdit

Sync-NAVApp: Table 5371 Service Connection Error :: The table 'Service Connection Error' cannot be located. Removing tables is not allowed unless they are temporary or are being moved by migration to another app. Table 5372 Service Connection Status :: The table 'Service Connection Status' cannot be located. Removing tables is not allowed unless they are temporary or are being moved by migration to another app.

Background & What I Tried:

In BC 22, these tables (Service Connection Error & Service Connection Status) existed in the database, but in BC 25, they are no longer present.
I manually deleted these tables from all companies and also removed their metadata from the Object Metadata Snapshot table in SQL. This allowed the upgrade process to continue successfully.
However, I am unsure if this manual approach is safe or if it could lead to long-term issues with the database integrity.

Questions & Alternative Approaches:

Is manually deleting the tables and their metadata a safe approach? Could this cause problems later?
If I create an AL extension to recreate these tables (IDs 5371 and 5372), what details should I include in the app.json file? Is it indifferent what values I set, or are there best practices?
Could this be fixed using an Upgrade Codeunit? If so, what would be the best way to structure it?
What approach would you recommend? Would an extension with ClearSchema be better, or is there another preferred method?

I found a similar case regarding orphaned tables from NAV 2009 - NAV 2013, where users faced similar issues due to tables left behind after multiple upgrades. That discussion can be found here:
🔗 Yammer Discussion

Final Thoughts:

I'm looking for guidance on the safest and most effective way to handle this issue. I appreciate any insights or experiences from anyone who has faced this situation before.

Thank you in advance!

Categories:

Dynamics 365 Business Central migration

I have the same question (0)

All responses (5)

Answers (1)

Dr Gomathi MVP, MCT... 395 Super User 2025 Season 2 on at

Like (1)

Report

When upgrading a Business Central On-Premises environment from BC 22 to BC 25, encountering orphaned tables like Table 5371 (Service Connection Error) and Table 5372 (Service Connection Status) during the Sync-NAVApp step is a common issue. Since these tables existed in BC 22 but were removed in BC 25, the upgrade process may fail because the system does not allow direct removal of tables unless they are temporary or properly migrated.

One of the first steps many try, as you did, is manually deleting these tables from all companies and removing their metadata from the Object Metadata Snapshot table in SQL. While this allows the upgrade to continue, it’s not the safest long-term approach. Direct SQL deletions bypass Business Central’s internal mechanisms, which could lead to reference issues or unexpected behavior if Microsoft modifies the upgrade logic in future versions.

A safer approach is to handle this issue within AL using either an Upgrade Codeunit or a temporary AL extension that retains the tables for a controlled cleanup. If you want to maintain these tables temporarily while ensuring a smooth upgrade, you can create a small AL extension that reintroduces these tables but marks them as ObsoleteState = Removed. This method ensures Business Central recognizes them during the sync process while allowing a controlled deprecation in a later update.

However, a better long-term solution is to use an Upgrade Codeunit to properly check for these tables and remove their data programmatically. This method is much safer than direct SQL deletions, as it ensures Business Central’s upgrade process handles the cleanup properly without leaving behind metadata references that could cause issues. The Upgrade Codeunit should include logic to check if the tables exist and delete their data before allowing the upgrade to proceed.

Another alternative is modifying the schemaUpdateMode in app.json to "Recreate" to clear outdated tables. However, this approach is quite aggressive since it resets the schema for the entire extension and should only be used if you're confident that no dependencies exist on the removed tables.

According to me the best approach is to handle orphaned tables using an Upgrade Codeunit, as it ensures a structured and safe removal process without risking database integrity. If needed, a temporary extension can be used to retain these tables with an obsolete state before removing them in a later update. Avoiding direct SQL modifications is crucial to prevent issues with future Business Central upgrades.

Regards,

Dr. Gomathi S

Was this reply helpful? Yes No
ivanrjlg 40 on at

Like (1)

Report
Hi @Dr Gomathi MVP, MCT Community lead, MLE

Thank you for your detailed explanation. I appreciate the insights on handling orphaned tables safely during the upgrade process. However, I have a few concerns and questions regarding the implementation:

1️⃣ How should the Upgrade Codeunit be created?

Should it be placed in a new app, or should it be part of the Base Application?

If the Upgrade Codeunit is in a new app, wouldn't it fail because I don’t have access to use object IDs 5371 and 5372?

I have no idea how to structure this Upgrade Codeunit, and the main issue is that symbols do not load in Visual Studio Code for these tables. Even though they exist in the database, they do not appear in the available symbols, making it impossible to reference them.

2️⃣ I cannot create a new app using IDs 5371 and 5372.

I do not have permissions or a license to use these object IDs in a new extension.

If I were to create an app for this fix, should I use a special app.json?

Do I need to reference the Base Application's metadata somehow to make this work?

3️⃣ Similar to point 2, I cannot create an extension with these object IDs.

Since Business Central does not allow me to use IDs outside the 50000-99999 range, I am unsure how I should approach this.

If an extension is not possible, should I consider another approach, such as a script or some modification in the upgrade process?

I would appreciate any guidance on how to proceed given these limitations.

Thanks again for your help!

Was this reply helpful? Yes No
Suggested answer

Dr Gomathi MVP, MCT... 395 Super User 2025 Season 2 on at

Like (1)

Report
Hi @ivanrjlg,

This is a common issue when upgrading Business Central (BC) from version 22 to 25, especially when dealing with orphaned tables (IDs 5371 & 5372). Since these tables are part of the Base Application, you don’t have direct access to them in an extension. Here’s how you can tackle this issue effectively:

Upgrade Codeunit: Where to Place It?

Since you cannot directly modify the Base Application, you should place the Upgrade Codeunit in a separate extension.

However, the challenge is that tables 5371 & 5372 are not accessible in a custom app because symbols do not load for them.

Workaround: Using SQL or Data Transfer Mechanisms

You can use an Upgrade Codeunit to fetch data from these orphaned tables without directly referencing them.

If symbols are not loading, an alternative is to use SQL Server scripts before upgrading.

Handling Tables Without Object Access

Since IDs 5371 and 5372 belong to the Base App, they are restricted. You cannot reference them directly in an extension.

Potential Fix: Use the UpgradeTableSyncSetup function to map data from these tables to a custom table.

Example of Upgrade Codeunit

codeunit 50100 UpgradeTablesFix { Subtype = Upgrade; trigger OnUpgradePerCompany() var TempTable: Record 50000; // Custom table to store data temporarily RecRef: RecordRef; FieldRef: FieldRef; SourceTableId: Integer; begin SourceTableId := 5371; // The orphaned table if RecRef.Open(SourceTableId) then begin RecRef.FindFirst(); repeat TempTable.Init(); FieldRef := RecRef.Field(1); // Assuming field 1 exists TempTable.MyField := FieldRef.Value(); TempTable.Insert(); until RecRef.Next() = 0; end; end; }

This approach retrieves data dynamically without requiring direct symbol loading.

SQL-Based Alternative for Data Migration

If the extension approach does not work, use SQL before upgrading:

SELECT * INTO [CustomTableBackup] FROM [dbo].[BaseApp$OrphanedTable_5371];

This allows you to back up the data, remove the orphaned tables, and reinsert them post-upgrade.

Best Practices for Your Scenario

Check if BC 25 still references these tables in the new schema.

Use RecordRef instead of direct table references to avoid symbol loading issues.

Backup orphaned table data before upgrading via SQL or AL code.

Consider using an ISV or Partner AppSource solution if Microsoft has an official migration path for this upgrade.

Hope this helps.

Have a great day.

Regards,

Dr. Gomathi S

Was this reply helpful? Yes No
Suggested answer

Suresh Kulla 50,243 Super User 2025 Season 2 on at

Like (1)

Report

Those tables are removed in the new version, so you just need to use Sync-NAVAPP command with ForceSync parameter.

Was this reply helpful? Yes No
Verified answer

ivanrjlg 40 on at

Like (0)

Report
Thank you @Dr Gomathi MVP, MCT Community lead, MLE @Suresh Kulla for the detailed insights and recommendations. After extensive testing, I found two solutions that allowed me to complete the upgrade from BC 22 to BC 25.3 successfully:

Solution 1: Temporary AL Extension Approach

I created an AL extension containing the missing tables (5371 – Service Connection Error and 5372 – Service Connection Status).

I published, synchronized, and installed the extension, confirming that it was properly registered in the database.

I then republished the extension, marking the tables as ObsoleteState = Removed. (Not entirely sure if this step was necessary.)

Finally, I uninstalled and unpublished the extension using the following commands:
Uninstall-NAVApp -ServerInstance $NewBcServerInstance -Name "FIX" -Version $version -ClearSchema Unpublish-NAVApp -ServerInstance $NewBcServerInstance -Name "FIX" -Version $version

After verifying the database, the tables were successfully removed.

I proceeded with the upgrade, and the Sync-NAVApp error related to the missing tables disappeared.

✅ This method worked, but I received a warning stating that installing an object with IDs 5371 or 5372 conflicts with the Universal Code initiative. Since I completely removed the extension and did not modify the base system, I assume this should not cause any long-term issues.

Solution 2: Manual Database Cleanup Approach

I manually deleted the tables from all companies.

Since the upgrade still raised errors related to the missing tables, I cleaned up the metadata using:
DELETE FROM [dbo].[Object Metadata Snapshot] WHERE ObjectType = 'Table' AND ObjectID IN (5371, 5372)

After this, the upgrade proceeded without issues.

Why the Upgrade Codeunit Approach Didn't Work

Initially, I attempted to handle this using an Upgrade Codeunit, but this approach was not viable due to the following reasons:

The tables were empty and had no data to migrate.

The tables were orphaned in the database and did not exist in the available symbols, making them inaccessible in AL.

I tried using the following approach:
trigger OnUpgradePerCompany() begin if not UpgradeTag.HasUpgradeTag(GetServiceConnectionUpgradeTag()) then begin DataUpgradeMgt.SetTableSyncSetup(5371, 0, TableUpgradeMode::Force); DataUpgradeMgt.SetTableSyncSetup(5372, 0, TableUpgradeMode::Force); UpgradeTag.SetUpgradeTag(GetServiceConnectionUpgradeTag()); end; end;
However, this did not work in this scenario.

Final Concerns & Uncertainty

Although I have successfully upgraded to BC 25.3, I still have some uncertainty regarding:

Which approach was the best practice?

Did I unintentionally commit a change that could cause issues later?

I would appreciate any insights or confirmation on whether these approaches are safe long-term or if there are better recommendations for handling similar situations in the future.

Thank you for your time and expertise!

Was this reply helpful? Yes No