Tuesday, November 5, 2013

Dynamics AX 2012 - Reset/Clear your user's usage data


Within Microsoft Dynamics AX (2012 and earlier), you may encounter issues where someone within your organization asks you to clear your 'usage data'. It will likely be because you are experiencing issues in your AX application that isn't happening for everyone else and maybe after an AX code promotion or deployment. It's usually one of the first things people check when debugging an issue for an end user or system tester.

CAUTION: By clearing your usage data, you will loose any previously stored queries and personalized forms used via Intellimorph. If its a specific area of functionality you need to fix, you might be able to clear the specific usage data creating the problem without loosing everything.

It's not too crazy of a process but can be intimidating if you are new to the system and don't know where to go and what it does. I will explain 1) how to clear your user data, 2) what usage data is exactly, and 3) why you may need to clear it

How to clear your usage data:
  1. In your Dynamics AX instance, you will want to navigate to ‘File’->Tools->’Options’ (Figure 1 below)
  2. Click on ‘Usage Data’ in the ‘Options’ form that opens up (Figure 2)
  3. Click on the ‘Reset’ button in the ‘Usage Data’ form that opens up (Figure 3)
  4. Click ‘Yes’. (Figure 4)  NOTE: This will only reset the usage data for your user, not anyone else’s
To make sure everyone is clear, the above will remove all your personalizations under your user including boxes that you previously checked as 'Do not ask me again'.

What is usage data?
Usage data is essentially AX's way of storing what you did last in order to provide a way for end users of the system to personalize and optimize their experience with the ERP.  Usage data is unique for every person.

For example, if you go into an AX form and move a field on a grid one field to the left, every time you go into that form in the future, AX will show you that field moved to the left. This way, every user in AX can have AX remember what they last did to that object whether it is values in a query/report, form layouts, templates, etc.

Technical dive example:
When a form is opened, AX will look at the universal object for the form. From there, it will see if the user opening the form has done any personalization to the form (aka a usage data record for that object seen in Figure 5 below). If the record doesn't exist, the form will open like it looks in base. If the record does exist, the data in the usage data record for that object is considered. The data in the record is a container that basically tells the system what data the user entered last or what needs to be where (like fields) that varies from what the base AX object in the AOT.

Why do I need to clear it?
On occasion, like in the case of new development to the underlying objects in the AOT, AX will not be able to translate the data in the usage data container for an object being used. This can result in an error upfront or a non-critical error that just creates extreme slowness or 'weirdness' as it can be reported.

Hitting the 'Reset' button in Figure 3 below will just tell AX to wipe the slate clean on things. It's a safe, fast bet to resolve whatever might be ailing you in AX that might only be happening to only you and not your fellow cohorts in your business unit.

UPDATE 11/21/2014 - Read the comments below for information in regards to selectively deleting records from usage data as well as how usage data templates are stored and removed. I added a picture in Figure 6 to supplement the comments as well.

UPDATE 3/20/2015 - STILL NOT WORKING AFTER TRYING EVERYTHING?
Is there still something not working? The field you just added to the form still not showing up for certain user(s) even though it is for others? Here are some things to check:

  1. Make sure they are in the correct environment 
  2. Try an apples to apples sanity check:
    1. Log into AX from a working user. 
    2. Make sure the field(s) in question are there. 
    3. Share your screen with the user having issues. 
    4. Right click on the Dynamics AX icon in the start menu in the way to run AX as a different user (in Windows Server 2012, go to the Start screen, richt click the Dynamics AX 2012 application tile and select that option)
    5. have the user then enter their credentials by giving them control of your screen
    6. Verify the issue exists/is fixed and go from there
  3. Go to the users machine and make sure that they don't have the form up anywhere when the usage data is reset. This includes if it is in a ListPage embedded in AX. Get another list page loaded if you have to, then reset the usage data
    1. The reason for this is that the usage data is recorded in AX when the form is navigated away from. If its still up, the usage data is cleared, then the user navigates away and back to it (to refresh the form), the old usage data will be saved again when the page is closed and then reloaded with the old data unintentionally.


Figure 1 - The 'Options' location for your Dynamics AX user


 Figure 2 - The 'Usage data' button under user options

Figure 3 - The 'Reset' button under usage data form


 Figure 4 - Click on 'Yes'

Figure 5 - A close look at the data within usage data

 Figure 6 - Usage data record rendered on form vs the template record (see comments below)

13 comments:

  1. Hi Justin,

    Our company is running on AX2012 R2 and I'm currently working as a support analyst for our users. I do encounter AX 2012 that is crashing for specific users, and usually it's caused by a personalization that goeas crazy and crashes the system.

    I do ask them to reset their usage data or do it myself for them (from the Users options in the Systemen Admin module), but I don't like this option because the users are losing their personal screens; it's causing frustration and loss in productivity to rebuild them.

    Is there any better option?

    Is it a "best practice" to do this kind of reset of usage data?

    Thanks,
    David

    ReplyDelete
  2. David,

    As far as resetting all of the usage data, I generally steer clear of wiping clear all data if they've modified a number of forms for the same reasons you've detailed above: loss of productivity to rebuild and frustrations. There really aren't 'best practices' around clearing usage data per se but its more a decision of strategically finding the object in usage data that is crashing and delete that one line over obliterating all usage data objects. Fishing with hand grenades? But the former option does take more time and skill to identify but IMO is the best option in a production environment.

    You 'should' be able to do quite a bit with the forms before you get crashing so I'm wondering what the underlying problem with the crashing is... I've seen some people have a form run lightening fast but it looks absolutely nothing like the base form. I say, good for them for being creative!

    As an example of some usage data crashing situations, some forms can have dynamically generated elements which take ids and potentially can cause a conflict with previously indexed form ids in usage data. Or as another example, a modification to the underlying form is promoted to Prod and conflicts with the end users' usage data built off the old form. Is it a base form causing the issue? Any modifications on that form? Is there a specific 'event' or 'place' or even 'time of day' that the crashing occurs?

    There are definitely options for streamlining usage data restores though. Not long term fixes but would help you for sure with productivity. Frustrations would still be there though... For instance, save off users usage data so when you clear everything out, you can reload and see if the issue is resolved just by a push of a button (or running X++ job)

    Are you saving the form layouts, clearing usage data, and then just reloading the old usage data? Might be a good exercise to push someone's saved form configuration to another user and see if it crashes theirs.

    If you're still not getting any success, yet another option would be to create a form in X++ which mimics the form's user layout customizations. From there, everything is already as it should be. And to streamline this, you can copy the original form, give it a new name and go cosmetic from there. I steer clear of mods if I can but its definitely an option if the productivity gains from eliminating the problem this way really help.

    Definitely some options though!

    ReplyDelete
    Replies
    1. There is a less invasive option:
      navigate to the user account in file manager. Example: C:/user/user/appdata/local. (Make sure to unhide all files and folders before trying this)
      2) locate the files ending with .ACU and .KTI. Delete them
      3) Have the user log in and AX will rebuild the files upon login. Personalizations will be intact still.

      Delete
    2. this is a great solution , fixed my problem. thanks

      Delete
    3. I had a big long response and then my browser crashed so I lost it all.

      In regards to methods of fixing crashing being more or less invasive, that is not true. The crashing may come from two different issues. But yes it is a good point to do the AUC and KTI file deletions to see if that might fix it quickly. I love comments helping to expand the conversations!! Keep adding them!!

      You can delete the AUC (not ACU file) and KTI files as a first step which might solve the issue but it might not. I'll explain: The AUC file is the Application Unicode Cache and is used for performance. It caches the users applications objects which can come from the base AOT object and changed by the users' usage data but is not actually 'storing' the usage data to restore for a later point in time. The KTI file is the Kernel Text Index file which is the index file for the data file (.KTD) which is used for system error messages and the AX interface. If you delete the AUC file, no reason to not delete the KTI file to refresh it while you're there...

      So its not a matter of one method being easier than another as the resolutions are mutually exclusive. If the users forms is conflicting with new form changes, deleting the files won't help and you'll need to dig into the form in a more 'strategic way. A pain yes but it could save significant hours for certain users so it may be worthwhile.

      The AUC and KTI files are client side which is why you may see some users instances crashing and not others.

      Hope this helps add clarity!

      Delete
  3. Thanks for the reply Justin. Many good insights for my team and me. :-)

    David

    ReplyDelete
  4. How do you selectively delete Usage Data? For example, I added a column to a grid in the Item Details form in Inventory Management, saved it, and gave it the name “test1”. Then I saw the “test1” change I had saved in the Usage Data, Form setup tab, System name: InventTable, Caption: Item details, More info: test1. I deleted that row, and then restarted AX, but the column I added was still in the grid. I also cleared the auc file, and restarted AX and the column I added was still there. I thought deleting the Usage Data row would remove the form customization. What am I doing wrong? Thanks!

    ReplyDelete
    Replies
    1. PK,
      Sounds like you are deleting the save configuration template, not the actual usage data on your account. There are two different records here. The usage data is automatically saved in the system when you close the form. There is no need to explicitly tell AX to save the changes you made to a form via IntelliMorph. You can however save the usage data in a 'template' which can be shared with others in the organization as usage data is user specific. When you save the active form setup, you are saving the data to a template. The actual form appearance is stored in a second record.

      So you save the configuration with the changes, go to personalization of that form and select the 'Load' button on the Layout tab. You should see the configuration you saved (test1 in your example). The save button is obviously how you save the template to begin with. Then go to the usage data's 'Form setup' tab. You should see two of the same name in the 'system name' field which would be the AOT name of the form you made changes to. For example, if the changes were made to the List Page for the item details form, there will be two records with 'System name' field of 'EcoResProductPerCompanyListPage' except one will have your template name in the 'More info' field. This record is the template that can be shared and not what is actually being rendered on your form.

      If you delete the record that DOES NOT have the 'More info' field populated (select record and click Alt+F9), your usage data on that form will be deleted but you should still have your templated usage data option available to you if you want to revert back to it or share with another person. This sounds like what you want to do. And you may not even need a template if it doesn't add value for what you are doing.

      BIG NOTE: Make sure you do not have your target form open when you clear your usage data. The usage data deletion will not reflect on the open forms. Usage data is written to the database upon closing of the form. So to recap, if you have your form with changes on it open, then delete usage data, then close the form and reopen it. The changes will remain on the usage data. If you check the usage data forms, you will see your old changes re-added again.

      Delete
  5. I added a graphic for the selective deletion of usage data in Figure 6 above. I'm a visual guy so hopefully that helps paint the picture better.

    ReplyDelete
  6. This comment has been removed by a blog administrator.

    ReplyDelete
  7. "Why do I need to clear it?"
    We had an APPCRASH / Ax32.exe / MSVCR90.dll / c0000005 from just one user on one form via multiple client installations within an AX 2012 R3 instance.
    Localising the form name, then the equivalent entry in the usage data removed the error.
    Note that for another particularly 'stubborn' user we would delete not only the *Form* but related *Class* and *Usersetup* data that was all referenced by the offending form.

    ReplyDelete
    Replies
    1. How do you go about deleting Form, Class, and Usersetup data in an offending form, for one particular user?

      Delete