Dynamics AX
  RSS Feed  LinkedIn  Twitter
Want to turn you're data into a true asset? Ready to break free from the report factory?
Ready to gain true insights that are action focused for truly data informed decisions?
Want to do all of this across mutliple companies, instances of Dynamics and your other investments?
Hillstar Business Intelligence is the answer then! (www.HillstarBI.com)

Hillstar Business Intelligence for Microsoft Dynamics AX and NAV on Mobile, Desktop, Tablet


Let us prove to you how we can take the complexity out of the schema and truly enable users to answer the needed questions to run your business! Visit Hillstar Business Solutions at: www.HillstarBI.com

Saturday, November 05, 2005

Axapta Client Cache?!

Now here's one that I know everyone will benefit from. You see we went 'live' this past week at work. In all accounts it's been a great success.

Well going live, and running into issues, and having to fix those issues on the fly is a given. Well in the process of doing that a co-worker of mine ran into an issue were he fixed some code, compiled the code, and then went to the user's machine who would be using that code. He ran the Sales Order, and ran into the same problem that where he had fixed? Puzzeled, he thought that the issue was the AOS server. So he kicked everyone out, and restarted the AOS server. Same issue!

So he then logged on as himself, to the same machine and it worked for him!? He logged on as the user, and she had the old code???!!!! Come to find out, Axapta has client cache files stored at:
c:\Documents and Settings\\local settings\application data\*.aoc


Well once we removed these files, and then openned Axapta, the user got the new code! So needless to say we added a script to everyone's network logon so it would run:
cd "c:\documents and settings\"
del /S *.aoc

That script will remove everyone's *.AOC files each time they restart their machine, which would ensure that the machine was running the latest code!

Find a job at: www.DynamicsAXJobs.com

3 Comments:

Blogger Sinister Cheese said...

However it will also slow the user down the first time he opens any menu item/functionality after restarting his machine, because the client cache file is gone.

A suggestion:
Maybe the systemadministrator should handle it instead:

Everytime something major has been updated in the Axapta, have the sytemadministrator activate the script code:

cd "c:\documents and settings\"
del /S *.aoc

in the login script of all users.
But only at that time.

This way the client cache file is not deleted, when it is actually not necessary, and the users will not complain about slow response time every morning.

5:28 AM  
Blogger Brian said...

You mention the AOC file storing code. I was previously informed that these files only act as a cache for table data. Do they also store code settings?

2:02 PM  
Blogger chris said...

I'm sort of new at AX, but a table data cache could only work if it were managed at the total database level and not a user level; otherwise, each user cache file would need to be managed when table data changed. This would undoubtedly counter vein any performance gains by a cache in the first place.

5:25 PM  

Post a Comment

Links to this post:

Create a Link

<< Home


Copyright 2005-2011, J. Brandon George - All rights Reserved