Monday, June 11, 2018

Opening Dynamics GP Windows using .NET and Visual Studio Tools

My blog has moved!  Please visit the new blog at:  https://blog.steveendow.com/

I will no longer be posting to Dynamics GP Land, and all new posts will be at https://blog.steveendow.com

Thanks!



By Steve Endow

When you develop a Dynamics GP customization, you may want to automatically open Dynamics GP windows to add dramatic flair to your application.

I mean really, let's be honest, what's cooler than saying your customization lets the user "drill down" into Dynamics GP?  (Is that still a buzzword? I may be behind the times)

Take the GP Transaction Search tool as an example. When a user searches for an AP transaction, I thought it would be handy if the user could right click on a row and view both vendor information and transaction information directly in Dynamics GP.


Just because I developed the PM Transaction Search window doesn't mean that I want to (or need to) develop a new window just to view vendor info or transaction info.

Why not just leverage Dynamics GP windows to view that information?

I want the user to be able to right click or double click on a row in the grid and view the details in an existing Dynamics GP window.

Here's a full video with a code review of opening GP windows from .NET using Visual Studio Tools:




Fortunately, adding this drill-down functionality to a VS Tools AddIn for Dynamic GP is relatively easy.  For some windows.

For other windows, it requires a slightly more involved process.

And, unfortunately, for some windows, it may be very difficult or impossible.

Tuesday, June 5, 2018

Dynamics GP Transaction Search v1.0 is Available! For FREE!

My blog has moved!  Please visit the new blog at:  https://blog.steveendow.com/

I will no longer be posting to Dynamics GP Land, and all new posts will be at https://blog.steveendow.com

Thanks!



By Steve Endow

A few weeks ago, a question was posted to the GPUG Open Forum asking why the AP Transaction Inquiry by Document was so slow.


The post explained that the company has so many different vendor accounts for FEDEX that they can't easily search based on vendor ID.  So they find it easier to search by vendor Invoice Number.

Unfortunately, because they have so much transaction history, and because the window pre-loads some data, it takes over 3 minutes for the inquiry window to even be displayed.

That. Is. Crazy.

I was...intrigued.

What would cause a seemingly simple Dynamics GP inquiry window to take 3 minutes just to open?  That's just weird.

So I decided to test the window and trace the SQL activity that occurs when the window performs a search.

It...was...bad.  The PM Transaction Inquiry Document window throws out SQL queries like they're going out of style.


Every single PM transaction record that is retrieved by the inquiry window results in at least 3 subsequent queries.  FOR.  EACH.  RECORD.

After seeing that, I gave up on attempting to "fix" or optimize the window.  It wasn't a SQL performance issue or a question of optimization.  It's just a terrible design.

So, what would an ideal PM Transaction Inquiry window look like?

How about this:



A window that allows you to search by date range AND vendor ID AND vendor name AND document number AND document amount.  All simultaneously.

Here is a video explaining the project and demonstrating the PM Transaction Search window that is included in version 1.0:




As you type each character, this magical search window calls a SQL stored procedure and updates the search results.  In real time.

To keep the window honest, a status bar at the bottom of the window shows how many records were retrieved, how many milliseconds it took to retrieve the data from SQL, as well as how many milliseconds it took to display the data in the window.

We're talking real-world accountability here, folks.

Want to see more info about a transaction?  Just double click on the row to drill into GP!  Or right click on a row to view the master record inquiry window.

Don't like the columns that are displayed in the search window data grid?  No problem.  You can modify the included stored procedure.  Want to add a column or two to the data?  No problem.  Just add a few fields to the procedure.

Are you so thrilled by the results of your search that you want to share them with your coworkers?  No problem.  You can click on the Copy button to copy all of the data in the grid and paste it into Excel.  Or you can click on the CSV button and save the data to a CSV text file.

And the GP Transaction Search tool is extremely simple to install.  Just run a SQL script to create a stored procedure in each of your GP company databases, then copy 3 files into the GP AddIns subdirectory.  It really is that easy.



You must be thinking: Wow, with all of those features, that fancy search window must cost a fortune!

But that's where you're wrong!  The Dynamics GP Transaction Search tool is available for FREE!


Here is the temporary link to download the search tool from OneDrive:

https://1drv.ms/f/s!Au567Fd0af9TogwHx8OKAarDM3Zm


UPDATE: I now have a dedicated page for the GP Transaction Search in the Free Products sections of my web site at:

https://precipioservices.com/free/gp-transaction-search/



But that's not all!  In addition to offering the tool for the rock bottom price of Free, I have published the code on GitHub as an open source project so that others can contribute to the project:

https://github.com/steveendow/gp-transaction-search


If you are a .NET developer or a Dexterity developer and are interested in helping enhance GP Transaction Search, please contact me!

If you have any questions about the search tool, or if you have used it in a real GP environment and have any suggestions for improving it, please contact me!


https://precipioservices.com/contact-us/




You can also find him on Twitter, YouTube, and Google+







Monday, June 4, 2018

"There's nothing wrong with our SQL Servers or network", says the IT department confidently

My blog has moved!  Please visit the new blog at:  https://blog.steveendow.com/

I will no longer be posting to Dynamics GP Land, and all new posts will be at https://blog.steveendow.com

Thanks!



By Steve Endow

Let me share a story about an all-to-common situation in the life of the Dynamics GP consultant or developer.

You develop an integration, or customization, or implement some software that talks to a SQL Server.  We do this stuff every day.  Normal, routine, common projects.  Just software talkin' to a SQL Server.  It's usually so reliable you don't think twice about it.

Then, after your integration or software has been running just fine for months, without a single issue, you encounter this error on Monday at 1am:

A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: SQL Network Interfaces, error: 26 - Error Locating Server/Instance Specified)


Hmmm, that's odd, we've never had this issue before--the integration has literally never had an issue connecting to the SQL Server.  We've had two dozen other errors related to bad data or import errors, but never before have we seen an issue connecting to the SQL Server.


"Hey IT manager, we received this SQL Server connection error from our weekly on Monday at 1am. Can you look into what might be causing this?"

IT Manager, 5 minutes later:  "Nothing wrong on our end! No errors, no issues, all of our jobs are running fine. If there was a problem, I would have known about it."


Oooookay then.


One week later.  Monday.  1am.  Same error, second week in a row.  And this is occurring for two different integrations--one pointing to the production GP company, and the other pointing to the Test GP company.


When both integrations are run manually at 10am, they both run fine.  So this is not a fluke, and it is occurring consistently now.


"Hey IT manager, for the second week in a row, we received the SQL Server connection error at 1am. It's occurring with two different integrations, so there is definitely something causing this. Can you please look into this again?"


IT Manager, 1 minute later:  "I was able to figure out the cause of the problem.  We are shutting down our GP SQL Server every night from 10pm to 5am."


Face.  Palm.


I actually encounter this on a regular basis.  Fortunately in this case, it turned out to be a blatantly obvious cause--the IT manager had just forgotten about the change to the server maintenance schedule.  But once he remembered, we had our explanation.

But usually, the problem is less obvious and much more difficult to track down.

It could be a bad switch or network card that causes intermittent SQL connection errors.  It could be custom code that only fires at certain times, locking or blocking SQL resources, causing seemingly random SQL command timeouts that get blamed on your software.  I've even had a situation where a Veeam backup of a completely different VM caused the host machine to drop network connections for other VMs. (a Veeam bug that I believe has been fixed)

I've seen all of my custom SQL objects literally disappear every week because a super security conscious corporate customer has a routine that deleted any unapproved SQL objects from the database.  And then there's the common case of anti-virus software blocking or deleting an EXE or DLL.

Modern networks are complex, and when you have dozens or hundreds of things going on, it's usually not easy to identify what might be causing an intermittent or infrequent problem.  When hardware and software is normally incredibly reliable, it seems that people are resistant to consider the possibility that something other than your integration or software is causing the problem.

Just because your software happens to be the one that is logging the error, there seems to be a strange bias that has people blame your software and deny that something else is preventing your software from communicating with the SQL Server.

I currently work with hundreds of customers, and as a result, I probably see this issue weekly.  Unfortunately, if the IT department claims that their systems are working perfectly, in many cases there isn't much that I can do except to add additional error handling, logging, and diagnostic information to my log files to present to the IT department repeatedly.  Sometimes it's enough to help a motivated tech do enough research to find the cause.  But many times an intermittent non-critical error just gets ignored.

If you encounter this issue with IT departments, do you have any suggestions?  Do you have a technique for making the IT department curious about researching the problem instead of getting defensive?  If so, I'm all ears.




You can also find him on Twitter, YouTube, and Google+