Small and medium business | Business Central, N...

Splitting shared tables (DataPerCompany = No) in Dynamics NAV 2017

(4) Share

Report

Posted on by Milos1612

Hi everyone,

Client works with Microsoft Dynamics NAV 2017 and they have two companies in the same database. Currently, there are around 100 shared tables (DataPerCompany = No) and the client would like to separate them so that each company has its own data.

Our goal is to change these tables to DataPerCompany = Yes.

We tested this on a test environment with the Contact table and simply changed the DataPerCompany property from No to Yes. After synchronization, the data was not deleted and remained available in both companies (each company now sees its own data).

My question is:

Is changing the DataPerCompany property enough, or are there additional steps we should consider (data migration, SQL considerations, etc.)?

Has anyone done a similar separation of shared tables in NAV 2017 or similar version in a production environment?

Any advice or best practices would be appreciated.

Thank you.

Categories:

Microsoft Dynamics NAV

I have the same question (0)

All responses (4)

Answers (0)

Suggested answer

YUN ZHU 98,421 Super User 2026 Season 1 on at

Like (0)

Report
Copy link

Link copied!

Hi, Microsoft supports switching this property, but you must use ForceSync mode. Due to the risk of data loss, please export your data beforehand.

https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/developer/properties/devenv-datapercompany-property?wt.mc_id=DX-MVP-5004336

Thanks.

ZHU

Was this reply helpful? Yes No
Suggested answer

OussamaSabbouh 11,612 Super User 2026 Season 1 on at

Like (1)

Report
Copy link

Link copied!

Hello,

Changing DataPerCompany/SaveDataPerCompany from No → Yes is only the schema switch; it typically results in the existing shared rows being available per company (often effectively duplicated across companies) after sync, so it won’t magically “split” records into the correct company for you. In production, treat this as a data migration project: decide ownership rules per table, run a controlled migration/cleanup (copy what belongs to each company, delete what doesn’t), and regression-test anything that assumed global masters (lookups, validations, integrations, numbering, cross-company reporting). Expect heavy SQL/schema work and downtime when doing this across ~100 tables.

Regards,
Oussama Sabbouh

Was this reply helpful? Yes No
Suggested answer

Dhiren Nagar 2,880 Super User 2026 Season 1 on at

Like (1)

Report
Copy link

Link copied!

Hi,

Yes you can do that and changing the property would require ForeSync.

However what you need to check is if it is master tables, it is fine, but if it is transaction tables, you might need to delete the unnecessary data related to other company.

Was this reply helpful? Yes No
Suggested answer

Touil Yahya 220 on at

Like (1)

Report
Copy link

Link copied!

Changing DataPerCompany/SaveDataPerCompany from No to Yes involves a schema update, so ForceSync is necessary. This should not demand additional work, but to minimize the chance of data loss, it's advised to export your data in advance.

Was this reply helpful? Yes No