Microsoft Dynamics 365 Blog

Recently I got confronted a lot with the following error message in Dynamics AX 2009:

User ‘UserName’ is not authorized to insert a record in table ‘TableName’. Request denied.
Cannot create a record in TableLabel (TableName). Access Denied: You do not have sufficient authorization to modify data in database.

The reason for this error message is quite obvious:
The user has not enough permission perform the noted database operation and so the AOS is preventing the execution of the noted database operation.

The AOS is guarding the specified table because the property AOSAuthorization is set to a different value than None. When this property is set the AOS is performing an explicit check of  user permissions for the selected database operation(s). If the user has necessary permission the corresponding table method aosValidateOperation would be executed next.

Let’s assume you have a table and have assigned the user access to this table by cascading down Full Control permissions. In this scenario you can still get confronted with this error message, because the table property MaxAccessMode needs also be taken into account. Whatever permission is set for a user group the effective permission for the corresponding table cannot exceed the value set in the MaxAccessMode table property.

So if you have a “not clever” mixture of the properties AosAuthorization and MaxAccessMode you might get into trouble, preventing every user (besides Administrators) from inserting records.

There can however be a valid reasons for choosing a very restrictive combination. But how do you e. g. get records inserted if you have selected only Edit for MaxAccessMode?

There is the X++ statement unchecked that if used together with the uncheck::TableSecurityPermission enum value allows to turn off the effect of AosAuthorization for a specific code block:


When does a combination of AosAuthorization, MaxAccessMode and the usage of unchecked make sense? A valid scenario is when you have a transaction table, several forms that show the content of the transaction table but you want to prevent everybody from manually entering data in this table. So only the business logic that is supposed to enter data in this table is using unchecked to get around the enforcement. As another side effect, code that is not supposed to enter or modify data (that is not using unchecked) can also be identified easily this way.

When you are starting to use the MaxAccessMode table property please take into account:

  • Edit includes View
  • Add includes Edit and View
  • Delete includes Add, Edit and View (and is the default value for this property)
–author: Alexander Lachner
–editor: Alexander Lachner
–date: 07/05/2009

We're always looking for feedback and would like to hear from you. Please head to the Dynamics 365 Community to start a discussion, ask questions, and tell us what you think!