You’re offline. This is a read only version of the page.
Announcements
4,125
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,
Hi Yuji,
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.
Hi Yuji,
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.
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).
[/quote]Hi André,
So never try to drop any table/field from SQL?
Thanks,
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).
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.
#1
André Arnaud de Cal...
294,157
Super User 2025 Season 1
#2
Martin Dráb
232,938
Most Valuable Professional
#3
nmaenpaa
101,158
Moderator
Share
Report
All responses (
Answers (
