Finance | Project Operations, Human Resources, ...

DATABASE VERSION (Microsoft Dynamics 365)

(2) Share

Report

Posted on by RSD

Hello,

I'm working with Dynamics 365 Finance and Operations, version 10.0.43, and I've noticed that the DBVERSION table, which existed in previous versions or legacy environments, is not present in the current database.

In the old version, this table contained the columns VersionType, VersionNumber and VersionString, and was used to control the version of the database.

I looked in standard tables such as SYSINFO, MODELVERSION and SYSVERSION, but I couldn't find any table or entity that contained exactly the same information.

I tried searching the web, but couldn't find any information. I saw this link Database Version (msdyn_databaseversion) table/entity reference (Microsoft Dynamics 365) | Microsoft Learn but it's not updated to a new location for database version information

Example, in version 43 of D365fo in the database I have the schema dbo.nametable but in version 40 of D365fo in the database I have the schema ax.nametable, dbo.nametable. I don't want to know the version of d365fo or sql. I really want to know the version of the database I'm using in dynamics.

I'd like to know:

Why does the DBVERSION table no longer exist in this version?

Is there any other place or standard table that replaces the DBVERSION function in the current D365FO?

Where can I find official documentation or guidance on this subject?

Thank you in advance for any help or advice.

Thank you!

Categories:

Dynamics 365 Finance

Version40.png

Version43.png

I have the same question (0)

All responses (5)

Answers (0)

Suggested answer

Saif Ali Sabri 2,351 Super User 2025 Season 2 on at

Like (1)

Report
In Dynamics 365 Finance and Operations version 10.0.43, the DBVERSION table no longer exists because Microsoft has restructured metadata storage and system versioning as part of the One Version service updates and platform optimizations. Schema changes, including the shift from ax. to dbo., are part of the underlying platform evolution aligning with modern Azure SQL practices.
✅ Replacement for DBVERSION Table:
There is no direct one-to-one replacement table for DBVERSION. However, you can find relevant database versioning information in the following:

ModelVersion table – Contains model-level version info (Layer, Model, VersionBuild, etc.), not the database schema version.

SysDataUpgradeHistory table – Tracks data upgrade runs with timestamps and descriptions, indirectly useful for tracking schema versioning changes.

SQLDatabaseVersion (if present) – In some environments, this custom or internal table tracks the versioning info, but it’s not always available or documented.

📌 Key Notes:

Microsoft does not expose a table with the same structure and purpose as the old DBVERSION in current versions.

Schema version tracking is now internal to the platform and controlled by Microsoft's update mechanisms via LCS and service updates.

📄 Documentation:
There is no official public documentation listing a new location or equivalent of the DBVERSION table. The most relevant sources are:

ModelVersion Table on Microsoft Learn

Servicing Guide for One Version

✔️ Conclusion:
There is no direct replacement for DBVERSION, and version control is now managed via platform-managed updates and LCS tracking. Use ModelVersion, SysDataUpgradeHistory, or LCS logs for indirect insights.

Was this reply helpful? Yes No
Diana Afonso 2 on at

Like (0)

Report

@Saif Ali Sabri Thank you very much for your detailed explanation.

Just to follow up — I checked in a D365FO 10.0.43 development environment, and unfortunately, none of the suggested tables (ModelVersion, SysDataUpgradeHistory, SQLDatabaseVersion) exist in my AXDB database, not even under ax. or dbo. schemas.

I also explored other tables like ModelManifest, but it only contains static model layer data, with no versioning details (all version fields are set to 0).

If there's any recommended best practice from Microsoft for version tracking across AXDBs, or any indirect method to retrieve the kind of version info DBVERSION used to contain, I’d love to hear about it.

Thank you !

Was this reply helpful? Yes No
Suggested answer

Saif Ali Sabri 2,351 Super User 2025 Season 2 on at

Like (0)

Report
In D365FO version 10.0.43, AXDB no longer includes legacy versioning tables like DBVERSION, ModelVersion, or SysDataUpgradeHistory. These were either deprecated or made internal-only due to Microsoft's sealed platform model and shift to cloud-first delivery via One Version.
Here’s a concise summary of the current reality and workarounds:

✅ Why DBVERSION and similar tables are gone

Microsoft no longer uses explicit in-database version tables.

Version tracking is now managed outside AXDB via:

LCS (Lifecycle Services) for build and update history

Metadata XML / Application object metadata in the AOT

Source control (Azure DevOps) for model/package versioning

This aligns with Microsoft's sealed, service-driven platform model, where direct DB versioning by customers is not supported or required.

✅ How to get equivalent version info today
1. Use LCS / Environment Details

Log into LCS > Environment Details

Look under:

Platform version

Application version

Deployed package name

Update history

2. Check via Visual Studio in Dev Environment
In your Dev VM:

Open Visual Studio > Dynamics 365 > Model Management > Model Versions

This shows each model’s metadata version (which would’ve appeared in DBVERSION previously).

Can also inspect the XML inside Descriptor files in PackagesLocalDirectory.

3. Check Model Metadata XML

Look in:

mathematica CopyEdit
K:\AosService\PackagesLocalDirectory\[ModelName]\Descriptor\Descriptor.xml

Contains:

xml CopyEdit
<Version>10.0.12345.0</Version>
4. Database File Metadata (Not Supported but Possible)

If you really need to extract schema-related info:

Use SELECT * FROM sys.objects + schema tracking

Combine with sys.extended_properties (if any internal metadata was applied during deploy)

Caution: Microsoft does not recommend relying on raw DB-level versioning in modern D365FO environments. It’s intentionally abstracted to maintain serviceability and integrity.

❌ No Official DB-based Best Practice
There is no Microsoft-documented practice for reading DB version info from AXDB in One Version. The emphasis is on using:

ALM practices (DevOps + LCS)

Package versioning

Model descriptors

📝 Recommendation
If your goal is to track and compare different AXDBs across environments:

Maintain your own custom audit log of LCS application/platform versions + model descriptor snapshots per deployment.

Optionally, create a custom metadata version table via a deployable package that logs model/package version info to the DB (if needed for automation).

Was this reply helpful? Yes No
Anton Venter 20,345 Super User 2025 Season 2 on at

Like (0)

Report

Hi,

Why do you need this information? What is the business requirement for this?

Was this reply helpful? Yes No
Suggested answer

Jonas "Jones" Melgaard 4,926 Most Valuable Professional on at

Like (1)

Report

@RSD the [AX] schema tables is related to the Commerce Scale Units (CSU), that's part of retail. DBVersion comes from this schema, and is used to keep track of the CSU database version.

In the latest PU, they have been removed from the AX database schema; Possible because it dosen't make much sense in the context of the development machines.

The D365 F&O schema is [DBO]; If you need to find the F&O schema version, select from the [dbo].SchemaVersion table.

If you need the current version of SQL server, select from @@VERSION

@Saif Ali Sabri please kindly avoid posting unverified ChatGPT / AI content on the forum. We have offered you help multiple times.

You are hindering subject matter experts in participating in the conversations, as you are marking your answers after suggested.

At minimum, please remove the formatting from ChatGPT. It does not look good, and this forum is indexed by Google and Bing.

Was this reply helpful? Yes No