Database log is fine for monitoring parameters.
Be wary about monitoring data - (don't use it all for transactions they write to too many tables and logs.)
Be careful what fields you log if you update things like costs and prices regularly , or regularly add new items in a fashion or industry.
Don't switch on database logging on those fields where if you have not finished loading master data.
Master planning can also flood the log is you monitor invent table.
Consider use of electronic signature to prevent problems and reduce the need to log.
Ludwig's site has a very good post on database log that you should look up.
When you set up database logging on a table where the table property has "Save data per company = Yes", the log details are found in the same company where the Create Update Delete operations are made.
When you set database logging on a table where the table property "Save data per company = No", the log details are found in the DAT company.
Now the bad news
It can your system. So think about database logging early in the project when designing the solution and make sure you develop/test with database logging activated.
When you activate the database log for a certain table, aset-based operations are converted to row-based operations, as confirmed by MSDN:
When you enable logging for a table, all database operations that would be set-based are downgraded to row-based operations. For example, when logging inserts for a table, each insert is performed as a row-based insert.
So activating the database log on a table will cause all code that uses the skip* methods to call to these methods will be ignored. With the database log active, records can potentially be deleted that should not have been deleted.
Do not use database logging because you do not trust your employees or as a form of “security”.
When activating the database log for a table, pay close attention to the TableGroup property of the table.
It OK to use the database log on tables with table group Main, Group and Parameter.
Skipping data methods and delete actions is bad practice, so don't go down that route, (there are places in which standard AX does this and these are not documented. )
When you set database logging on a table where the table property "Save data per company = No", the log details are found in the DAT company
Consider www.arbelatech.com/.../audit-security-manager-asm.html
You can also get a lot of info from SQL.
There is an undocumented function called "fn_dblog" which enables you to read data from your transaction log which contains very informative data about things that are happening in your database. Also the function fn_dump_dblog" but I don't like unsupported functions so better to consider a commercial tool like www.sqlserverlogexplorer.com/restore
Last comment is test first.
