BC 17.4 - ForceSync does not work

[matthiasbier]

• AL Extension Version: v6.5.413786

• Server Version: DE Business Central 17.4 (Plattform 17.0.21485.21516 + Anwendung 17.4.21491.21531)

When using ForceSync Mode for synchronizing an extension from VS Code it seems as if schema changes are not synchronized. The output shows, that the extension was successfully published, but the changes are not applied in the database. Only when incrementing the extension version and using ForceSync the changes are applied.

When using Synchronize or Recreate, the table changes are applied without the need to increment the version no.

Tested on a CRONUS BC 17,4 container and several extensions.

Publishing to a BC 16.4 container works as expected: Without incrementing the extension version, the changes are applied when using ForceSync.

Any idea?

[kalberes]

We have had ForceSync broken, but we have released a hotfix and the latest 17.4 should contain it. Can you try using the latest platform version available for container?

[matthiasbier]

I'm using the latest. I'm creating the container with this:

$artifacturl = Get-BCArtifactUrl -country de -type OnPrem -version 17.4 -storageAccount bcartifacts
...
New-BCContainer -accept_eula -containerName devBC174 -multitenant=$false -artifactUrl $artifacturl -alwaysPull -updateHosts -credential $credential -auth NavUserPassword -licenseFile $license

And the artifact looks also good to me:

{
    "licenseFile":  "database\\Cronus.flf",
    "database":  "database\\Demo Database NAV (17-0).bak",
    "version":  "17.4.21491.21531",
    "platform":  "17.0.21485.21516",
    "country":  "de"
}

This should be the latest version, right?

The service also shows this version:

ServerInstance : MicrosoftDynamicsNavServer$BC
DisplayName    : Dynamics 365 Business Central Server [BC]
State          : Running
ServiceAccount : NT AUTHORITY\SYSTEM
Version        : 17.0.21485.21516
Default        : True

[kalberes]

This version as far as I know does not contain the fix.

[matthiasbier]

Well, that's the latest 17.4 version which is accessible:

When will there be an updated version with the fix?

[krregg]

We have the same issue but with the OnPrem version, which was downloaded yesterday from MS. ForceSync definitely doesn't work as it was working before (before that we used 17.0 and it worked fine). Platform and Application Build versions are the same as mentioned above. Also, our AL compiler version is the same as mentioned in the first post.

We noticed the same behavior when publishing from VSC or using PowerShell cmdlets.

ForceSync works only when you increase the app version, but that is not the solution.

Here are some cases of mentioned behaviour:

#### publishing from VSC ####

# case #1
# 1. Publish app (v 1.0.0.0) for the first time with schemaUpdateMode=ForceSync in launch.json. Table check in DB is ok.
# 2. Publish updated app (v 1.0.0.0) where new field is added in table, schemaUpdateMode=ForceSync in launch.json. Table check in DB is not ok, new field is not created.
# 3. Publish updated app (v 1.0.0.0) where new field is added in table, schemaUpdateMode is not defined in launch.json. Table check in DB is ok, both fields are created.

# case #2
# 1. Publish app (v 1.0.0.0) for the first time with schemaUpdateMode=ForceSync in launch.json. Table check in DB is ok.
# 2. Publish updated app (v 1.0.0.0) where new field is added in table, schemaUpdateMode=Synchronize in launch.json. Table check in DB is ok, both fields are created.

# case #3
# 1. Publish app (v 1.0.0.0) wth two fields for the first time with schemaUpdateMode=ForceSync in launch.json. Table check in DB is ok.
# 2. Publish updated app (v 1.0.0.0) where one field is removed from table, schemaUpdateMode=ForceSync in launch.json. Table check in DB is not ok. The removed field is still visible in DB.

# case #4
# 1. Publish app (v 1.0.0.0) wth two fields for the first time with schemaUpdateMode=ForceSync in launch.json. Table check in DB is ok.
# 2. Publish updated app (v 1.0.0.0) where one of the fields is updated (renamed) in table, schemaUpdateMode=ForceSync in launch.json. Table check in DB is not ok. The renamed field is not visible, there is still the field with first publishing.

# case #5
# 1. Publish app (v 1.0.0.0) for the first time with schemaUpdateMode=ForceSync in launch.json. Table check in DB is ok.
# 2. Publish updated app (v 1.0.0.1) where new field is added in table, schemaUpdateMode=ForceSync in launch.json. Table check in DB is ok. Previously installed app (v 1.0.0.0) is removed from installed apps.

# Conclusion: schemaUpdateMode=ForceSync in launch.json is not working as expected. The published app is not synchronized in DB and newly added fields are not created in DB. 
#             the same is for publishing app from PowerShell, ForceSync does not work as it worked in previous versions (17.0). 

#### publishing with powershell ####

# case #1
# 1. Publish app (v 1.0.0.0) for the first time with PowerShell with one field in the table, Sync-NavApp Mode=ForceSync. Table check in DB is ok.
# 2. Publish updated app (v 1.0.0.0) where new field is added in table, Sync-NavApp Mode=ForceSync. Table check in DB is not ok, new field is no created in DB.

# case #2
# 1. Publish app (v 1.0.0.0) for the first time with PowerShell with one field in the table, Sync-NavApp Mode=Development. Table check in DB is ok.
# 2. Publish updated app (v 1.0.0.0) where new field is added in table, Sync-NavApp Mode=Development. Table check in DB is ok, a new field is created in DB.

# case #2
# 1. Publish app (v 1.0.0.0) for the first time with PowerShell with two fields in table, Sync-NavApp Mode=Development. Table check in DB is ok.
# 2. Publish updated app (v 1.0.0.0) where one field is removed from table, Sync-NavApp Mode=ForceSync. Table check in DB is not ok, removed filed is still visible in DB.

[matthiasbier]

@kalberes Can you confirm that this is a bug?

I would at least expect a error message when trying to ForceSync with the same version no.

[krregg]

My opinion is that this is a bug, and before this will be fixed I suggest that you just increase the version in app.json when deploying locally. The same solution will work in CI/CD pipeline. It's not really a friendly solution but it works. :)

[pro4dynamix]

After a few hours of struggle with an upgrade to 17.4 from 16.X OnPrem, we came to the same conclusion. ForceSync cannot update the schema on the SQL Server. It is even not possible to create new tables with ForceSync. It only works when the version number is increased. From my point of view, this is a serious bug.

[kalberes]

You can only force sync from vscode until 17.5 is released. Powershell publishing with force sync is broken.

[atoader]

The issue will be resolved in the 17.5 version of the product. I will close this issue.

[arnthorm]

We are still able to replicate the issue with the PowerShell module in 17.5. It's working in VS Code.

Version: W1 17.5 (Platform 17.0.22463.0 + Application 17.5.22499.0)

When we publish an app with the same version and schema changes, the new schema isn't applied:

> Publish-NAVApp -ServerInstance $BcServer.Info.ServerInstance -Path "C:\dev\LSCentral\ls-central-al\AL\LSCentral\LS Retail_LS Central_17.4.0.0.app" -SkipVerification -Force
> $App = Get-NAVAppInfo -Id '5ecfc871-5d82-43f1-9c54-59685e82318d' -ServerInstance $BcServer.Info.ServerInstance -TenantSpecificProperties -Tenant default
> $App | Sync-NAVApp -ServerInstance $BcServer.Info.ServerInstance -Mode ForceSync -Force
WARNING: Cannot synchronize the extension LS Central because it is already synchronized.

If we try to install the app, we get the following error:

> $App | Install-NAVApp -ServerInstance $BcServer.Info.ServerInstance -Tenant default
This could be caused by an error processing your message or a receive timeout being exceeded by the remote host, or an underlying network resource issue. Local socket timeout was '10675199.02:48:05.4775807'.

The same script works in 17.3.

[kalberes]

The fix only works if you have a non SAAS server that is configured as a local server. Thus if you have a local server that has been configured with SAAS parameters it will still not work.

[arnthorm]

@kalberes, can you please point out what parameters you are referring to? I just tried to set ExtensionAllowedTargetLevel = OnPrem (from internal) without luck. We are running an install from the DVD, not from a container. Most settings are default.

[kalberes]

What is the DefaultApplicationId in your customesttings.config ? It should be "NAV"

[JohanStenberg100]

Hi, I would suggest that you bump the build (or revision) component each time you deploy instead. Add it as part of your scripts and you are good to go. There are technical reasons for this change (necessary for our SaaS infrastructure) and it would be best if we avoid diverging SaaS behavior from OnPrem behavior as much as we can.

[arnthorm]

There was no DefaultApplicationId entry in our CustomSettings.config file. I did add it as following, but no luck.

<add key="DefaultApplicationId" value="NAV" />

Since this works in VS Code, we assume it would work for the PowerShell module as well.

We have invested a lot in our dev infrastructure, CI/CD, QA,... which relies on this behavior, so it's not as simple as suggested.

Will this be fixed or is this the new behavior?

Thanks, guys!

[JohanStenberg100]

Hi @arnthorm we are looking into this. Here's an update. We'll "revert" on-prem to allow you to get the behaviour you want starting 17.6 and 18.0. In the meantime you can try insider builds with docker if possible.

[JohanStenberg100]

Update: It will be 18.1 (and 17.6) and not 18.0 that will have the fix. @arnthorm fyi