Источник:
http://www.agermark.com/2015/05/fix-...th-fields.html
==============
Recently I was called in to help on an issue after installation of a third party module, where fields were in the AOT but wasn't synchronized to SQL Server. The fields also looked as they should in the SQLDictionary table.
New attempts to synchronize the database didn't create the fields on SQL. AX must have been under the impression that the fields were synchronized.
If I tried to delete any of the fields, I'd get an error from AX about it not being able to drop the fields on SQL Server, so I was kind of stuck.
Here is what I did to fix the situation:
- I looked up the SQL field names in SQLDictionary and created the fields manually on SQL Server. I was not too concerned with datatypes and other properties, as these fields were just created to be able to drop them from AX again.
- In the AOT I changed the SaveContents property of each field to No. This will make AX drop the fields from SQL Server.
- I synchronized.
- I changed SaveContents properties back to Yes. This will make AX create the fields again on SQL Server through the right synchronization process.
- I synchronized.
In the old days, this was something you could fix with SQL administration from the System administration menu, but the features to fix such issues have been broken since version 4.0 of AX.
I never did figure out how the third party vendor brought themselves into this situation though. That would have been interesting enough to know.
Источник:
http://www.agermark.com/2015/05/fix-...th-fields.html