Notifications
Announcements
No record found.
Hi,
Since in D365FO, the system does not maintain table ID and field ID. Is there still a SQLDictionary table, and how the DB sync work in D365FO now? I remember in AX 2012, there are some interim tables during the DB sync.
Thanks,
SQLDictionary still exists but is only left there for a few legacy purposes. Most of the IDs (including class IDs, enum IDs, etc. which no longer are in the metadata itself) are maintained in separate tables in the database.
There's TABLEIDTABLE, TABLEFIELDIDTABLE but also CLASSIDTABLE, ENUMIDTABLE, etc, etc.
As usual, be careful manipulating any of these tables as the consequences could be disastrous.
SqlDictionary still there with Table ids and fieldIds.
Hi Yuji,
Does the reply from Joris answered your question or do you have an issue related to this question?
Recently, I did something stupid myself and broke the sync process in one environment. I dropped one table from the SQL itself. Thereafter, I had also found the tables mentioned by Joris and cleaned all data in the SQLDictionary and TableID... tables. Note that also the table TABLEINDEXIDTABLE exists. These tables are only visible on the SQL database itself and are not visible in the AOT (Also not in the system documentation node).
Hi André,
So never try to drop any table/field from SQL?
It's never recommended to delete table / field from SQL. With D365 cloud version, we no longer have access to SQL @ production environment. In previous versions also it was never recommended to update from SQL.
Like Satish mentioned, we don't have access to the SQL on the production environment. The TABLEID... tables can also have different values per environment. My experience was a really stupid mistake, but I learned a lot from it. Luckily it was an own playground environment on my private tenant; not work related. When you are accessing the VMs of a DEV or Staging environment, consider it like it is a production environment and try to solve issues in the way, you should do it on such environment.
FYI: I changed a table definition for testing purpose. In a new table, I changed a Date field. Removed the field and replaced it directly by a datetime field with exactly the same name. The sync process did stop on the column change which was not possible. Then I had a look at the SQL table directly and by accident dropped the table. The correct procedure would be (1) using another field name or (2) first delete the field; then sync; then add the new field and sync again. The option number 2 would be impossible on a production environment because you don't know if a customer would skip an update.
Under review
Thank you for your reply! To ensure a great experience for everyone, your content is awaiting approval by our Community Managers. Please check back later.
As AI tools become more common, we’re introducing a Responsible AI Use…
We are honored to recognize Neeraj Kumar as our Community Spotlight honoree for…
These are the community rock stars!
Stay up to date on forum activity by subscribing.
Martin Dráb 611 Most Valuable Professional
André Arnaud de Cal... 529 Super User 2025 Season 2
Sohaib Cheema 285 User Group Leader
