When importing data into a table the programmer should be aware of any modifiedfield controls that are present on that table. These controls might be used to update other fields, or even other tables, and rather than recreating the code in your import scripts, it is much simpler to use the system code to perform these functions for you.
After your field is updated you can call:
Using this method will mean if over time, between the development of the import code, and the actual use date, if the system code is changed, your code will still function in alignment with how the system now works.
Following on from my recent blog Linking purchase orders with sales order using x++, you might also want to link a purchase order with a sales order that is intercompany.
If you know the sales order number of the end sales order you need to link with, then you can use the sales table field, InterCompanyOriginalSalesId, to find the sales order number from the end sales order of the intercompany order.
When developing code that will be running in CIL mode, for example Batch jobs, it is important that after changes are made to code that the system is CIL compiled, incremental or full.
If you do not CIL compile then the old code will be running, not the new code, as only compiled CIL code is processed.
Found a strange occurrence in the system today when moving between the main system and the development environment. The status bar shows the company that is active. However when doing some testing I noticed that if the companies in the two environments are different, when I change from the development environment to the client, the system will report the change of company.
However if I change from the client the development environment, assuming it is already open, it will not do the same, keeping the active company as the one from the client, even through the status bar in the development environment states otherwise.
So be careful if you are running classes or jobs that update data in a multi company environment. You should always code the required company into the class or job to ensure it cannot be accidentally run from the wrong company.
When data importing, sometimes we need to import a CSV file. To make the code flexible it is best to make the filename a variable and allow the user to select the file they want to import. This can be done in a class or a job using the Dialog control.
A code example is as follows:
If you are using direct SQL to access data in another SQL system, you will typically be using the ResultSet data handler. To extract of the different fields contained in the ResultSet uses the appropriate get commands depending on the variable type. If you are trying to get a string you might encounter a problem were the limit of the data returned will be 999 characters.
Beware of the getstring limit of 999 characters, and if your field might be longer than this, you will need to handle this in the SQL statement and merge the data together after.
When programming batch jobs you might encounter the following error message log from a failed to execute batch job:
System.InvalidCastException: Unable to cast object of type ‘<class name>’ to type ‘Dynamics.Ax.Application.Batchable’.