Breaking news from around the world
Get the Bing + MSN extension
Now Available in Community - MBAS 2019 Presentation Videos
Catch the most popular sessions on demand and learn how Dynamics 365, Power BI, Power Apps, Power Automate, and Excel are powering major transformations around the globe. | View Gallery
2019 release wave 2 Discover the latest updates and new features to Dynamics 365 planned through March 2020
Release overview guides and videos Release Plan | View virtual launch event
Ace your Dynamics 365 deployment with packaged services delivered by expert consultants. | Explore service offerings
Connect with the ISV success team on the latest roadmap, developer tool for AppSource certification, and ISV community engagements | ISV self-service portal
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance TechTalks | Customer Engagement TechTalks | Talent TechTalks | Upcoming TechTalks
Hello dear comunity members.
We are currently implementing an online store integration with a third party solution on D365FO Application Version 8, Platform Release 15.
During the full data sync we've entcountered multiple SQL error, which look like this:
A similar issue has been described here: dynamics 365 for operations can not sync database after upgrade from 1611 to platform update 4
So there are following schema mistmatches in the channel database: (to be read as [<schema>].[<table>].[<field>] /*<string size in channel database schema> --> <string size in D365FO database>*/
[ax].[TAXDATA].[TAXCODE] /*10 --> 20*/
[ax].[TAXGROUPDATA].[TAXGROUP] /*10 --> 20*/
[ax].[TAXGROUPHEADING].[TAXGROUP] /*10 --> 20*/
[ax].[TAXONITEM].[TAXCODE] /*10 --> 20*/
[ax].[TAXONITEM].[TAXITEMGROUP] /*10 --> 20*/
[ax].[TAXPARMETRES].[TAXGROUP] /*10 --> 20*/
[ax].[TAXPARMETRES].[TAXITEMGROUP] /*10 --> 20*/
[ax].[TAXTABLE].[TAXCODE] /*10 --> 20*/
[ax].[TAXTABLE].[PAYMENTTAXCODE] /*10 --> 20*/
[ax].[TAXTABLE].[PRINTCODE] /*10 --> 20*/
[ax].[TAXTABLE].[TAXACCOUNTGROUP] /*10 --> 20*/
[ax].[TAXTABLE].[TAXJURISDICTIONCODE] /*10 --> 20*/
[ax].[TAXTABLE].[TAXONTAX] /*10 --> 20*/
[ax].[TAXTABLE].[TAXPERIOD] /*10 --> 20*/
[ax].[ECORESPRODUCT].[SEARCHNAME] /*20 --> 200*/
[ax].[INVENTTABLE].[ITEMBUYERGROUP] /*10 --> 20*/
[ax].[INVENTTABLE].[NAMEALIAS] /*20 --> 200*/
[ax].[INVENTTABLE].[PROPERTYID] /*10 --> 20*/
[ax].[INVENTTABLE].[SERIALNUMGROUPID] /*10 --> 20*/
I have applied changes to the schema, but done it with DROP TABLE + CREATE TABLE (scripting tables as CREATE in management studio) for every listed table, except of the InventTable. And that was a mistake :)
After that the data sync has been executed without any errors, however I dont' get the data in fixed tables in the retail channel database. Even though the disctribution schedule generates a package with all the data needed, the batch job pushes this package for processing, but the SQL Server doesn't apply changes from the package to those tables (for instance, EcoResProduct stays empty).
I have debugged the data sync process and the batch job (RetailCdxChannelDbDirectAccess) and stuck on the call to the .NET code, which processes the package:
I have compared schema differences on channel database with another environment, but haven't found anithing. There is no change tracking for AX schema tables and there were no dependencies on dropped tables.
Does anyone know, what exectly SQLTargetRequestHandler.processDataPackage() does?
Thanks in advance
Sorry, relevant link community.dynamics.com/.../error-when-pushing-catalog-data-to-the-retail-server
Sorry for misleading post, the discrapancy happened, because the DBO schema has been changed by an ISV solution, which I realized pretty late.
Here is also the link for extension of Channel Database which has a resolution for the issue, that those dropped tables are not getting staged. Adding extensions It states: "Grant DataSyncUsersRole permission if your table is going to send receive data from HQ."
So after granting need permissions to recreated tables the batch job was able to process data package for all the tables.
Now the question is, how did we get standard fields with extended length in the new environment in the version 8 (as we know overlayering is not possible). Investigating it in Visual Studio shown, that the data types and fields are not extended. So the field length in Visual Studio was 20 and in the SQL server 200. This situation was caused by the database restore process. We have restored an old database in the new DevBox. The synchronization went well, because SQLDictionary also contains 200 for this field.
Business Applications communities