Here’s a list of af few reasons why I think it is important to fix those best practice errors :-).

Improved performance
Many best practices have an influence on performance. For example, it is best practice to set the property CreateRecIdIndex to True on tables with Created/Modified DateTime fields. If you don’t, this will have an adverse effect on the performance of those tables.
Another example is that if you adhere to the best practices concerning the construction of classes and the use of batch classes, it will be much easier to improve performance by enabling batch multi-threading.

Improved readability of code
When all developers follow best practices about formatting of code, the code will be more readable and easier to understand. Avoiding dead code and removing unused variables will also make the code less confusing.

Developers learn
There are a lot of handy things you can learn by solving best practice deviations. Adding fields to field groups for example is a great way to avoid customizations to forms. And by figuring out what configuration is needed on a menu item, you learn about what effect configuration keys have on you solution.

Improved security
Adding security and configuration keys is vital to good security. When ignoring best practices, an unauthorized user might cause a big mess that you’ll have to clean up.

Certified for Dynamics AX
Making sure your solution is best practice deviation free goes a long way towards passing the Software Solution Test.

Better user experience
Some best practices have to do with labels, help texts, descriptions for batch task, etc. If you ignore those, it will be more difficult for the user to understand the solution you created.

User ‘Admin’ is not authorized to delete a record in table ‘DEL_PBATRANSLATECONSISTOF). Request den[ied].
Cannot edit a record in Translation table (DEL_PBATranslateConsistOf). Access Denied: You do not have sufficient authorization to modify data in database.

This week was the n-th time someone has come to me with this problem, so it’s time to blog about it :-).

The error you receive is odd, because user in question has enough rights to edit any table (administrator).
This error occurs when you don’t have the Product Builder (PBA) license key enabled.

There are two possible solutions to this problem:

• Either activate the license key for Product Builder under Administration – Setup – System – License information (if you have the PBA license key), and after synchronizing the Data Dictionary, you should be able to delete the company account
• Or if you don’t have the PBA license key, go to the AOT – Data Dictionary – Tables – DEL_PBATranslateConsistOf, and clear the security key property.

Try again
You probably already did, but make sure you can reproduce the problem. If it only occurred once, it’s not a problem.

Check your code again
Check your code carefully for errors, and maybe ask a colleague’s opinion.

Compile
Your project might contain compile errors, so compile it to be sure.

Close the debugger
Sometimes, when the debugger is active, AX will keep executing ‘old’ code. Close the debugger to make sure the latest code is executing.

Compile forward
When you have modified a class that is inherited by other classes, you might want to compile forward this class.

Synchronize data dictionary
You may have made changes to application objects that haven’t been synchronized with the database. Open the AOT, right click on the Data Dictionary node and choose Synchronize.

Restart AX client
Simple as that, close the AX client and start it again.

Reset usage data
Go to options screen (AX button > Extra > Options) and click the Usage Data button. Click reset to remove this data.

Check the application event log for clues
Open the event viewer on the AOS to see if the AOS service has logged something in it. Messages here can help you a great deal. You can also check the event log on the database server or your client pc.

Google it
If you receive an error, just copy and paste it in Google. Most likely you are not the only one having that problem.

Check your client version
Check your AX client version. You might for example be connecting to a SP1 application with an SP0 client. You can check this in the about screen: AX button > Help > About. The kernel version indicates the client version, below that is the application version.

Refresh AOD, Dictionary and Data
You can flush cashed information using three option in the Tools > Development tools menu: refresh AOD, refresh Dictionary and refresh Data. This can be useful when you just imported an xpo file, or when you are developing for the enterprise portal.

Delete AUC file
The application Unicode object cache file, if there is one, is located at C:\Documents and Settings\[USERNAME]\Local Settings\Application Data for xp, or C:\Users\USERNAME\AppData\Local for vista. Delete this file while the AX client is closed.

Check if other users are having the same problem
Knowing whether you are the only one that’s having that problem or if it’s a general problem is a big step towards solving the problem. For example, if you alone have the problem, restarting the AOS probably won’t solve it, but removing usage data might.

Check security settings
When only some users have a problem, big changes are that it has something to do with security settings. Security can be set up from Administration > Setup > Security, on the Permissions tab.

Check configuration key setup
Some features of AX won’t work if a configuration key is disabled, be aware of this.

Full compile
Open the AOT, right click the AOT node and select compile.

Restart AOS
Sometimes restarting the AOS solves your problem just fine. If you can, it’s worth the try as this doesn’t take long.

Remove .aoi file
When the AOS is stopped, you can delete the .aoi file from the application files. This file will be rebuilt when the AOS starts.

But sometime, you’ll have to change it, whatever you reason may be. One reason why you might need to change these, is because the user group permissions setup has been messed up by adding one or more new security keys, or by importing them from an xpo file. The security keys will be set to ‘No access’, and because you can’t change these for the admin group, this poses a problem.

This can easily be solved by changing the method isAdmin() on the form SysUserGroupSecurity to return false.

Alternatively, if you don’t want to change your code, you can put a breakpoint on the ‘return true’ statement, and then drag/drop the pointer to return false.