Art Of Creation: What you should know about database logging: functional impact
As a developer, I am not a big fan of database logging, but many customers and consultant love it. Most developers will probably agree that is undermines many of the performance optimizations that developers do, like using set based operations. It is no coincidence that a whole section is devoted to performance on the Configure and manage database logging page on MSDN.
But I don’t want to talk about performance now, I want to talk about the functional impact of activating database logging.
I will start with the conclusion:
Activating database logging on certain tables can change how Microsoft Dynamics AX behaves and cause hard to explain bugs. It can also cause loss of data.Okay, so why is this?
To improve performance of certain processes, Microsoft Dynamics AX sometimes uses the following set-based operations:
To counter this, you can call a number of skip* methods:
When you activate the database log for a certain table, all set-based operations are converted to row-based operations, as confirmed by MSDN:
When logging is enabled for a table, all database operations that would be set-based are downgraded to row-based operations. For example, if you are logging inserts for a table, each insert is performed as a row-based insert.When we combine all of this knowledge, we realize that activating the database log on a table will cause all code that uses the skip* methods to behave differently, that is to say, the call to these methods will be ignored.
We’ve had problems with this on our project in two cases on AX 2012 FP; namely with code that deletes WMSSHipment and VendInvoiceInfoTable records in this way. In both case, because database log was active, records were being deleted that should not have been deleted. A developer can experienced the problem as for example “skipDataMethods does not work” or “skipDeleteActions does not work“. The problem of course is not the skip* methods but the database log.
What to do about it?
If you really want to activate database logging but you have code that need to do a set-based operation, you can get around this issue by using the skipDatabaseLog method in combination with the other skip* methods.
However, in my opinion it is better not to use database log in the first place. So these are my recommendations about database logging:
Расскажите о новых и интересных блогах по Microsoft Dynamics, напишите личное сообщение администратору.
|emeadaxsupport: MS Dynamics AX database logging feature setup||Blog bot||DAX Blogs||0||22.06.2014 21:16|
|Kurt Hatlevik: Enable database logging on groups and parameters||Blog bot||DAX Blogs||0||29.05.2013 17:11|
|axinthefield: Too Much Database Logging in Dynamics AX||Blog bot||DAX Blogs||0||13.06.2011 00:11|
|Microsoft Dynamics NAV Database Archive for all Country Versions||Blog bot||Dynamics CRM: Blogs||0||11.03.2011 18:43|
|Опции темы||Поиск в этой теме|