User ‘UserName’ is not authorized to insert a record in table ‘TableName’. Request denied.

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
Comments (4)

  1. MProuty says:

    We have experienced now 3 distinct incidents where users suddenly start receiving these access errors doing activities they did the day before. 2 of those users are in Admin group. Our only option is to remove the AOSAuthorization on table.

  2. JAlger says:

    We recently began to invoke security and immediately ran into this same error on the following tables when users were attempting to run STANDARD AX updating processes.  







    Our solution to date has been to set MaxAccessMode to "delete".

    If there is a better solution, we would like to hear it.  Thanks!

  3. There are hotfixes for those, see KB969185 for ProjCostTrans, KB970505 for ProjEmplTrans, as described n the article above, the solution is to use the special piece of code where records in these tables need to be created/updated. I recommend searching on partnersource or conacting us in support if you need further fixes for these tables.

    Tariq Bell MSFT

Skip to main content