We are facing something strange with the transportation of models. Within one layer we have two models. A standard AX form was first modified in "model 1". Changes were lay-out and a change on a method on the datasource.
Now in "model 2" we have only changed an existing method (in the datasource) which was not affected by a the changes in "model 1".
We transported the model to a next environment in our DTAP. All changes in "model 2" except for this change on the datasource is visible.
Why is this change not transported? When we look at the model elements the method is visible as change in "model 2". That makes it even more strange....
I hope someone can answer this question.
You will not be able to differentiate the Datasource node using models in the same application layer. The entire Datasources node is one and overshadowed as one.
You can either differentiate over layers, or you will have to merge your models into one for the forms.
Thanks for your quick answer. In this case it is possible to create a mismatch between the model elements and the real contents of a model.
The model elements tells me there is a object present (method of the datasource) in "model 2", but the real change is stored in "model 1".
How can we correct this?
The method of datasource is not the model element and you cannot see it in the ModelElement table in the model store. You can only see the Datasources node and this node (including all data sources, fields, methods, etc.) can be only in "model 1" or "model 2'.
Thanks for your reply. There is a little misunderstanding between a FormMethod name and a FormControl. Look at the next printscreen of the model elements:
The first element with MODEL 2 is a general form method. This change is transferred.
The Type FormDataSources is present in Model 1. The highlighted row is has a Name 'correctedTaxAmount'. The name of the method and the name of the form control is the same. It appears to be the FormControl. So, indeed only the Datasource Node is present in Model 1.
Thanks Tommy and Petr for your feedback.
Glad you found it. :-)
Just to throw some more into the discussion; have a look at this recent post:
We should strive to move our business logic out of the forms, if feasible.
I read the blog from Martin... I agree, but in this case we needed to change a standard method because of performance issues. This was a little present from Microsoft :-(
Have a look at the contents of the highlighted method. Due to not having "if (_set)...." around the last call; for each line even if there was no change this code was executed. The journal contained about 10.000 lines with accounttype 'Project'.
This issue is known at Microsoft and will be solved in CU5 for AX2012/AX2012 FP.
Great catch, Andre! :D