Last week, I wrote about a situation which was causing issues with the Database Validation feature of GP Power Tools. Triggers on the ACTIVITY table that fired when records are deleted that attempt to clean up data in the company that the record is related to.
The problem is that if the current user does not have access to this company or company database does not exist or is not online, errors are generated and the code fails. This is discussed in my blog:
Microsoft Dynamics GP 2015 R2 added lots of new features and enhancements and fixed a number of bugs too. However, it also introduced a change that is now causing errors in some ISV’s (Independent Software Vendor) products.
I first came across this issue when preparing to release GP Power Tools build 22 and was testing the Database Validation feature on my Microsoft Dynamics GP 2016 install.
Following on from my recent article, #GPPT Adding Vendor Item Number to SOP Documents, I thought it would be worth showing how we can use GP Power Tools custom Report Writer functions with a SQL Query to obtain any data available from any table on the SQL Server.
To make this happen we are going to combine the Runtime Execute Setup custom RW function code with a SQL script created in SQL Execute Setup. Note that these techniques, which have been available since June 2009, are completely Web Client compatible which makes them even more valuable now.
I want to make everyone’s life easier.
I should clarify that this is life in respect to my work life. As a Developer, IT Professional and Microsoft Dynamics GP Consultant I love anything that makes my job easier.
That’s why I created GP Power Tools (formerly the Support Debugging Tool) in the first place.
My good friend, Belinda Allen MVP, sent a funny comic strip from xkcd to me last week.
I thought it needed to be shared as it is funny to the database administrators and developers among us, but also highlights an important issue.
This is the third and final article in the series, make sure you look at the previous articles before this one.
The previous articles can be found at:
Today’s article adds the final step by adding a method for a user to execute the code we have written so far without requiring access to any Support Debugging Tool windows.
This is the second article in the series, if you haven’t already, please see the previous article: Using the Support Debugging Tool to create user accessible SQL Scripts – Part 1.
Today’s article adds a simple user interface for the previously created SQL scripts using Dexterity sanScript.