Dynamics AX - SysDatabaseTransDelete

As the years have gone on, more and more professional now exist in the Microsft Dynamics AX Space. With this, some handy things that us old dogs know about sometimes are taking for granted.

So in the spirit of giving, and making sure to bubble up some handy tips and tricks, I thought I would highlight an old dog of a class, with that being of SysDatabaseTransDelete

This is a very handy class, but one you should use with care. The point of this class is to remove, from a given company, all transactional data that has been generated.

So many times, when doing implementations, you generate test data, and need the ability to remove that data and make sure to have a clean slate, while keeping the Master data elements you have setup in tack.

Enter SysDatabaseTransDelete, as this is the purpose of that class. It's been around for a while, since early AX days, and you can customize this if need be, but be careful in doing so and in it's use. A small "are you sure" is all you get and bang! Transactional data goes bye-bye!

That's all for now, I have my next series of MSDynamicsWorld.com article coming out soon, along with a few interviews, Dynamics Community Site, more on AX 2012, and getting ready for Convergence coverage.

Till next time!

"Visit the Dynamics AX Community Page today!"

SSRS 2008 Setup Option for Dynamics AX 2009

With deploying Role Centers, and specifically around SQL Server Reporting Services (SSRS) 2008 for Dynamics AX 2009, we have seen all kinds of existing whitepapers, blog entries, etc. That help get Role Centers up and running.

Reporting Services is a part of the underlying technology that enables Role Centers to work.

With Dynamics AX 2009 and SQL Server 2005, as part of SSRS setup we had the IIS Pool Identity that we set to the .Net BC. We also had to setup an execution account that the Reporting Service executed under, and that had correct Kerberos Security SPN's created.

With SQL Server 2008, Reporting Services, we no longer have a SSRS site in IIS, and therefore no longer an AppPool identity to set for the .Net BC. What does you do then?

Well if the .Net BC account is also your execution account for SSRS, what the service 'logon as' is set too, then your fine. However what if you Want a seperate account for your .Net BC, that is different from the account used for esxecution of the Reporting Service?

This is where the execution account, in the Reporting Services comes into play. Wait though!

In the setup, have we not seen where when this is set, we see issues with Role Centers, specifically SSRS based web parts not working? Yes, but with SQL Server 2008 Reporting Services, and this desired setup, then we have to supply the execution account be that of the .Net BC.

Doing so enables us to have a seperate account for the execution of the SSRS service, that is different from the .Net BC account, while still enabling Kerberos security work and Reporting Services Web Parts to be fired correctly that point back into Dynamics AX.

So in short.:

• You can have a seperate account that runs the Reporting Service, that is different from the .Net BC account.


• In SQL Server 2008, no AppPool identity to set.


• Instead of AppPool identity, setup the Execution Account as the .Net BC account.


After having correct Kerberos Security, with SPN's setup, then this will enable the desired mentioned configuration.

One other point with SQL Server 2008 Reporting Services, do everything through the 'Reporting Services Configuration Manager'. This includes restarting the services, and setting accounts and settings. It's not recommended that you restart the Reporting Service, through the Service MMC. Doing so cause order of service startup actually to sometimes mess up.

That's all for now, but check back soon as more to come!

"Visit the Dynamics AX Community Page today!"

SQL Quick tip - OpenQuery

Alright, it's been a while since I had to do this, but just in case. If you are in an implementation and you happen to be moving data from Oracle or and AS/400 and want to query the tables and views, first:

• Take and create a linked Server, with the correct provider to the database.


• Make sure to make use of the openquery syntax

The syntax for openquery goes: select * from openquery(Linked_Server,'Select Statement')

This will save a lot of pain, and allow the other server to handle servering up table attributes, data types and the likes that will cause issues if you try a standard linked server, FQN statement. :-)

Check back soon!

Find a job at: www.DynamicsAXJobs.com

Quick Tip - Application Object

Have you ever had a need to run some code, or preform a task after each user's logon into Dynamics AX? Well I had just this need this past week and this is best done by using the Application.startupPost() method. In this method you can place code to call, say another class, to preform a task as each logon, better, after each logon into Dynamics AX.

This is the safest and preferred method of doing such a task. Well thought I would pass this along. Mostly a common knowledge thing, but sometimes it's hard to recall things that you have not touched, or even possibly thought about in a while.

check back soon!

Find a job at: www.DynamicsAXJobs.com