Refreshing code changes in reports objects in SSRS

When working with the reports' objects (be that one of the controller, contract, data provider classes, the query, or the table, temp or regular) sometimes it happens that the changes done are not properly reflected in SSRS.

The first item that I want to make clear is that for the reports you do not need to run the generate CIL (be that full or incremental) when doing changes in the above objects. It is a misconception that doing this will fix any problems with the SSRS, and not doing this will save you the time of waiting for it. Of course, there is the time when the reports are not running all together, but that is when the system services are not properly running to serve information regarding the session, query, or metadata.

With that in mind, you have the following items to perform:
1. if you are on R3, you have the Tools -> Caches -> Refresh report server;
2. also, do a Tools -> Caches -> Refresh elements and Tools -> Caches -> Refresh dictionary;
3. if you have an AOT query, you can do a Restore on the query;
4. open the report in Visual Studio, and perform a Refresh on your dataset in the Datasets node;
5. also in Visual Studio perform a rebuild and a deploy of the report;
6. before step 5. you can check that the parameters you have for your report are the proper ones (if you've changed the data contract or the query);
7. depending on the decision to load the last values (controller.parmLoadFromSysLastValue) you want to do a Reset usage data;
8. and last but not least, you want to do a Restore and then also a Deploy element on the report in the AOT.

You should view your new changes now (in the dialog prompt or the report).

AX2012: Error when downgrading the AX server kernel

Description:

 It can happen that you need to downgrade the AOS kernel in a system. Depending on the build you are going back to, you might get an error message.

Error message:

Object Server 01:  Fatal SQL condition during
login. Error message: “The internal time zone version number stored in the
database is higher than the version supported by the kernel (4/1). Use a newer
Microsoft Dynamics AX kernel.”

Solution:

You need to change the value for the column value SYSTIMEZONESVERSION in the table SQLSystemVariables. If you look in
the event viewer you can see that it finds the value 4, but expected 1 (4/1).
So the solution is to change the value to 1.

Create a Simple Batch Job

In this post we’ll learn how to create a very basic custom Batch job using SysOperation framework. We’ll use the base controller class SysOperationServiceController and develop a custom service operation class to achieve the goal.

Requirement:

To create a Batch job to mark all the records as processed in a custom table MAKSalesTable.

Project overview:

The project shows how simple yet powerful the SysOperation framework is for developing custom batch jobs as opposed to RunBase framework since the minimum development needed to create a fully functional batch job is to create a custom service operation class defining a single method giving the implementation for the batch operation to be performed.

Development steps:

1. Create a service operation class MAKSalesTableService having the following class declaration:

class MAKSalesTableService
{
}

2. Create a new method in the class giving a suitable name like processRecords having the following definition:

[SysEntryPointAttribute(false)]
public void processRecords()
{
    MAKSalesTable   makSalesTable;
    int             counter = 0;

    //Determines the runtime
    if (xSession::isCLRSession())
    {
        info('Running in a CLR session.');
    }
    else
    {
        info('Running in an interpreter session.');

        //Determines the tier
        if (isRunningOnServer())
        {
            info('Running on the AOS.');
        }
        else
        {
            info('Running on the Client.');
        }
    }

    //Actual operation performed
    while select forUpdate makSalesTable
    {
        ttsBegin;
        makSalesTable.Processed = NoYes::Yes;
        makSalesTable.update();
        ttsCommit;

        counter++;
    }

    info(strFmt("Successfully processed %1 records.", counter));
}

3. Create an action menu item MAKSalesTableService pointing to SysOperationServiceController.

4. Set the parameters of the action menu item to the service operation just created, MAKSalesTableService.processRecords.

5. Compile the service operation class and generate incremental IL.

6. Click on the action menu item to run the batch job. Check the Batch processing checkbox to run the job in CLR runtime which is the batch server execution environment.

7. Click System administration > Inquiries > Batch jobs to view the status of the job. You may also click on the Log button to view the messages written to infolog during the job execution.

Preconditions:

Before running the batch job, all the records were unprocessed:

Post conditions:

After running the batch job, the list page shows that all the records are now marked as processed:

Changing the Background Color on AX Forms in AX 2012

I recently wrote some additions to a nice little utility that changes the background color in forms.  For each company you can set the background color to a different color of your liking.  The color serves as a visual reminder of which company you are currently logged into.  Enjoy!

Addendum:  I just added a project that does the same for AX 2012 R2.  No additional functionality, just made it compatible with AX 2012 R2.  The download is now a zipped file that contains a project for AX 2012, and AX 2012 R2.  Please import the correct project for your version..

Change Background Colors.zip