Encountered a strange issue when dealing with labels in DAX2012 using the TFS. The normal process is to create the labels as normal, the system will allocate a temporary label id. When you check in the labels the system will create the actual labels and update your code replacing the temporary label with the new label. This all sounds great, but what happens when things go wrong?
There are often times that we write a method within a method to reduce the amount of code we have to write and often to allow for recursive code. This would look something like:
When compiling your code you might encounter the following warning: Parameters in the validtimestate clause must match the type that is specified in the ValidTimeStateFieldType property of table <table name>.
Some tables use the time state control, if they do there are two modes for this time state; date and datetime.
There are a number of methods in DAX2012 that need the input of Datetime. While they will work by sending a date value, they will generate a warning message during a compile.
To handle the value correctly, and to eliminate the warning message, you need to convert the Date to a DateTime. This can be done using the following command:
DateTimeUtil::newDateTime(<date variable>, 0, DateTimeUtil::getCompanyTimeZone());
Sometimes it is necessary to know what type of tracking is active for an item. From the Product (EcoResProduct) you can get this information a follows:
When you move a database from one system to another, or install a new AOS you might get the following errors when starting the AOS:
Cannot create another system semaphore
The internal time zone version number stored in the database is higher than the version supported by the kernel (x/y). Use a newer Microsoft Dynamics AX kernel.
If you use task recorder on AX2012 R2 CU7 you may experience a problem when you end the recording, where the system will not create the word document to store the information gathered.