If you need to debug something that will destroy your test data, that is not easy to recreate (i.e. posting a complex journal), then normal approach would be to take DB backup, and restore it after you finished debugging to debug again/test the fix.
Database snapshot is a better option in this case - it is lightning fast (15 seconds to restore 80GB database).
CREATE DATABASE AxDB_Snapshot ON (Name ='AxDB', -- this is the Logical Name value from database Properties / Files / Database files FileName='J:\Snapshots\AxDB_Snapshot.snp') -- ensure the drive has enough space to store the database AS SNAPSHOT OF AxDB;
select name, physical_name from AxDB.sys.database_files;
Microsoft Dynamics 365 Unified Operations: Batch Manageme Microsoft Dynamics 365 Unified Operations: Data Import Ex Management Reporter 2012 Process Service World Wide Web Publishing ServiceIIS Express
USE AxDB ALTER DATABASE AxDB SET SINGLE_USER WITH ROLLBACK IMMEDIATE USE master RESTORE DATABASE AxDB from DATABASE_SNAPSHOT = 'AxDB_Snapshot' ALTER DATABASE AxDB SET MULTI_USER WITH NO_WAIT
Start d365fo services from powershell: Start-D365Environment
DROP DATABASE AxDB_Snapshot;
If you found value in what I share, I've set up a Buy Me a Coffee page as a way to show your support.
Buy Me a CoffeeNo comments. Be the first one to comment on this post.
DaxOnline.org is free platform that allows you to quickly store and reuse snippets, notes, articles related to Dynamics AX.
Authors are allowed to set their own "buy me a coffee" link.
Join us.