Error BC14 | Another user has changed the definition of the Server Instance table after the activity

Jonh_Milky

Hi all,

How are you?
I have BC14 CU52 with 4 databases (currently working on the transition to AL) , that up until now was ok. As of this weekend for one of the databases i can no longer run objects directly from the development environment or debug.
Below the error message



The same happens if i try to add a breakpoint on the code, then the error is the same but the table name changes.

With the other 3 databases (and same binary installation) everything is still fine.

Does anyone have an idea of that this might be?

Thanks in advance for your expertise

vaprog

I suggest you you stop all BC services on that database, then truncate the Debugger Breakpoint, and the Server Instance table, before restarting the services.

We had issues with the Breakpoint table on this platform version, inexplicable malfunctions, which were solved by restarting the services, and general issues with table synchronizations.

vaprog

I suggest you you stop all BC services on that database, then truncate the Debugger Breakpoint, and the Server Instance table, before restarting the services.

We had issues with the Breakpoint table on this platform version, inexplicable malfunctions, which were solved by restarting the services, and general issues with table synchronizations.

Jonh_Milky

Hi vaprog,

Thanks for your help. I've tried it but i still have the same problem
Probably the issue is on a different system table...

tmadsen

I am running into the same issue. Also BC14, CU 29. Have one serverinstance on the machine that it works fine for, another instance on the same machine that has the problem. Same C/SIDE client, just different databases. Server is running in VM on azure, SQL DB is Azure SQL. Also just runing File, Database Information from C/SIDE will generate the same error. I have tried restore 2 months old database, still have the same problem. So I am thinking maybe not data related. Since more people just encountered it, maybe a Windows update of sorts. I reinstalled the backup to a new server instance, didn't help. Tried resetting the C/SIDE ZUP file, just in case. Didn't help. I was thinking of creating a bacpac file and see if I could get around it, but now I am not so sure it is data.

tmadsen

Is your database also on Azure SQL ?

Jonh_Milky

Yes, the databases are all in Azure SQL. But only one has a problem, i think this is probably related with the schema sync on this database... i just don't know how to fix it.
I've tried to clear some tables, rebuild indexes... so far no luck.

tmadsen

Since you and I both encounter this, on Azure SQL now within the same week cannot be data related. Like you I have multiple databases, only one with the problem for now. I even restored old versions and all ended up with the same issue. I tried un-install some windows updates, but that didn't help. Maybe some Azure update.

vaprog

Have you tried running Sync-NAVTenant from Powershell instead of "Sync. Schema ..." from development environment?

Jonh_Milky

@vaprog I've already tried it... but the process does not go though or retrieve any error message.

I was able to get a different error if i try to do the same process opening the development environment from a different server.

tmadsen

Just a second data point. I can run the Synch from Powershell and I get the same "Definition is changed" error when running from a different client.

Duizy

We are experiencing the exact same problems. First earlier this month with BC14CU23 ACC and now with PROD too. Both databases are on Azure. Anybody having more information on this subject?

Jonh_Milky

I'm still facing the same issues, but only in one database. Also since the beginning of the month.

Duizy

We have another database BC140_Budget that still works that we are trying to break. So far no luck. Next is attaching this working Budget database on the BC14_ACC that is not working. You got to try something.

Jonh_Milky

I've just did a dummy test and changed the compatibility level to SQL Server 2012 and it solved the error, i'm going to dig a bit more on this.

Duizy

I have not been able to replicate the error on our BC140_Budget database. Even putting it under the BC140_ACC NST. I reverted everything back to how it was this morning.

Using the finsql.exe in elevated or non-elevated mode, I cannot view the Database Information, I cannot run any object. Always giving me the 'Another user has changed the definition of the Server Instance table after the activity was started.' error.
I can however import a .fob file with 'Later' and use powershell to
Sync-NAVTenant –ServerInstance 'BC140_ACC' -Mode Sync (or Force if needed).
Running then 'Microsoft.Dynamics.Nav.Client.exe' seems to be working flawlessly still.
I give it a rest for now.

Jonh_Milky

@Duizy Did you try the Azure SQL Compatiblity?

Duizy

@Jonh_Milky: The compatibility mode were the same on all three databases. Still at fault the ACC and PROD databases but the BUDGET database is behaving as it should. Three 25+ experienced NAV/BC guys and we still didn't find a solution as yet.

leftfield

Hi everyone,
I have the same problem but with NAV 2018 (11.0.48302.0) and Azure SQL.
Out of 3 databases (PROD/TEST/DEV) only one database PROD is affected by the same problem.
I then exported the bacpac from Azure SQL and imported it onto a Virtual Machine with the same version of Nav 2018 installed. The error seems to have disappeared (on-premises). I thought it was a compatibility problem. From the new Virtual Machine, with the same version of Nav 2018 but connected to the Azure SQL database, nothing changes, therefore it doesn't make me think of an installation problem / Tls / .net framework.
Meanwhile downgrading the compatibility level from 120 to 110, it works.
We are also investigating the same mysterious problem

Duizy

@leftfield: Stupid enough we thought we did also change the SQL database compatibility mode previously but I guess after so many months not correctly. We also changed from 120 to 100 and everything is working again as it should.