User 'UserName' is not authorized to update a record in table 'TableName'. Request denied.

You thought you were the administrator.
You thought it was your data.
You thought you could do with it what you want.

You thought wrong!

Even as an administrator, you may come across these kinds of error:

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.

Or, from real life:

User Admin is not authorized to update a record in table LedgerTrans. Request denied.
Cannot update a record in LedgerTrans. Access Denied: You do not have sufficient authorization to modify data in database.

The reason behind this, is a security measure. The AOS is guarding the access to the table data. This has been set up by using the AOSAuthorization property on the table.

And, is there a workaround available? Yes, there is.
But first of all: Beware! Changing or inserting data in tables that are protected like this should be done with extreme caution, as essential business logic is at risk.

The easiest thing to do is to change the AOSAuthorization property on the specified table. STOP! Don't do that, don't put your data at risk like that. Badly written code can easily mess up your data, and that's not something you want with a table like fe LedgerTrans. You only want to modify this data in a very controlled setup.

A better solution is to use the unchecked statement. With this statement, you can switch off any AOSAuthoratization setup on the table, only for the current code block.

Example:

LedgerTrans.skipTTSCheck(true);
select firstonly forupdate
LedgerTrans where LedgerTrans.RecId==123;

if(LedgerTrans.RecId)
{
LedgerTrans.Txt="Hello";
unchecked(Uncheck::TableSecurityPermission)
{
lLedgerTrans.doupdate();
}
}

All this should get you interested in Ax and it's security setup. A recommended reading for that can be found over on the Microsoft site.