The Paradox of Choice by Barry Schwartz

By Steve Endow

Several years ago I read an article in Scientific American called "The Tyranny of Choice" by Barry Schwartz.  It was fascinating and finally gave a name to a frustration that I had been noticing for several years, particularly when having to shop for something new or expensive.  If it visited a store, I would be confronted with an entire wall or aisle of products and it was overwhelming to try and choose just one.

I recommend reading the article, but Mr. Schwartz has since published his full book on the topic, called  The Paradox of Choice.  And he has a great TED presentation on the topic as well.

I think it's a good topic and concept for everyone to understand, as many sales and marketing strategies revolve around offering customers choices.  Even consultants in the field can benefit, as they need to understand that clients who are not Dynamics GP experts can be frustrated by a list of choices as well.

So when you are working with your customers, keep the concept of The Paradox of Choice in mind.

Steve Endow is a Dynamics GP Certified Trainer and Dynamics GP Certified IT Professional in Los Angeles.  He is also the owner of Precipio Services, which provides Dynamics GP integrations, customizations, and automation solutions.

You can also find him on Google+ and Twitter

http://www.precipioservices.com

Great quote: "I am never a fan of always"

By Steve Endow

I was on a call with a client this week and we were discussing a moderately complex business process related to Dynamics GP transaction integrations and custom reports.

At some point during the conversation, the client was asked if he thought that a particular report would always be run in a particular way.  After pausing for a moment, he had a great response:

"I am never a fan of always"

It instantly got my attention, and I love the somewhat ironic use of "never" in the phrase.

The quote speaks to something that most veteran consultants know well.  Whenever developing a business process, or a solution tied to a business process, you can rarely make an assumption that any particular thing will "always" occur--or "never" occur for that matter.  Business processes are often defined by their exceptions, and in many businesses, it seems that exceptions are the rule.

While this often makes it difficult to implement consistent processes in Dynamics GP, such exceptions are often what makes a business unique and competitive.  They offer the wacky discounts or weird invoicing options or strange business processes that you've never seen before and that are difficult to setup in Dynamics GP.  But those things were often created to accommodate customers, so there are often good reasons for the madness.

Anyway, I thought that was a great quote.

Steve Endow is a Dynamics GP Certified Trainer and Dynamics GP Certified IT Professional in Los Angeles.  He is also the owner of Precipio Services, which provides Dynamics GP integrations, customizations, and automation solutions.

You can also find him on Google+ and Twitter

http://www.precipioservices.com

Windows Application Event Log fills with Information events: Event ID 1903 from source HHCTRL

By Steve Endow

UPDATE: A Dynamics GP partner found a way to disable the rampant HHCTRL events by adding some registry entries.  That solution is listed at the bottom.


I recently had a customer contact me regarding an issue he saw in his Windows Application event log.  The log was being flooded with events from source "HHCTRL".  Several events per second were being recorded, resulting in thousands of entries in the Application log.

The events were only "Information" messages, so they didn't appear to indicate an issue, but the volume was annoying, as it made it very difficult to identify any legitimate errors that might be logged.

The description for Event ID 1903 from source HHCTRL cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer.

I have seen this issue before, and did some preliminary research previously, but all of the threads I found either had no real information about the problem, or they offered solutions that didn't work.  Some threads mentioned that Microsoft issued a security patch for HTML Help, and it was that security patch that introduced this HHCTRL event log message issue.

Since the issue came up again, I finally researched it with a colleague and we discovered what we believe is the cause of the issue.

We knew that the messages appeared to be associated with an application that could be run as a standard Windows app, or as a Windows Service.  My colleague did some testing and discovered that when the application was run as a typical program in a Windows session, the messages did not appear.  But, when he started the service for the application, the HHCTRL messages did appear in Event Viewer.  I was able to verify and reproduce this on my server as well.

We then tried checking permission issues, but we were both testing with Administrator logins, so we doubted it was a permission issue.

Stumped, I decided to try a long shot and launched the SysInternals Process Monitor application.  I ran a trace in Process Monitor, then searched for HHCTRL.  I found that the application was trying to access a copy of the hhctrl.ocx file in the local application directory, but was unable to find it, so an error was generated.  I tried copying the hhctrl.ocx to the app directory, which resolved the error in Process Monitor, but did not eliminate the messages being logged to Event Viewer.  Hmmm.

I then tried unregistering and re-registering the hhctrl.ocx file in different directories, but that didn't eliminate the Event Viewer messages.

So then we pondered why the messages did not appear when the app was launched in a Windows session, but did appear when the app was launched as a service.  And then it dawned on us.

When a service is started, it runs in a security and user-profile "nether world".  The service can have permissions that are equivalent to a user, but the service will not have the exact same "amenities" as an application launched in a user session.

For instance, a service does not necessarily use the same system variables as a Windows user, so the TEMP directory may be different.  And certain operations are blocked for a service that are allowed for a user.  I have had to deal with this quirk over the last few years, and it has resulted in a fair amount of frustration and troubleshooting, but we at least know that such issues exist and know to look for them.

Since we know the HHCTRL messages only appear when the app is run as a service, and I found that the messages appear to be related to HHCTRL, we dug further into the HHCTRL component.  It is part of the Microsoft HTML Help system on Windows, and as we learned, there were a few security updates to HTML Help that restricted its ability to perform certain operations.  We speculated that when an app was run in a user session, it had sufficient permissions, but when run as a service, the Microsoft HTML Help security patch restricted its capabilities and caused the Event ID 1903.

To validate this, I performed a simple test.  I setup a new task in Windows Task Scheduler that would simply launch the Dynamics GP eConnect Programmers Guide, which is a .chm help file.  I did this because Task Scheduler allows you to run an application in your user session, or as a system task that does not require you to be logged in--this runs it in a "nether world" similar to running as a Windows Service.

When I chose the option to "Run only when a user is logged on", the HHCTRL message did not appear in Event Viewer.   But when I chose "Run whether a user is logged on or not", an HHCTRL message DID appear in Event Viewer.

We had found the cause of the problem:  If a Windows application that uses HTML Help attempts to run as a Windows Service or other type of background process (such as with Task Scheduler) that is NOT in a Windows user session, the security restrictions in HTML Help prevent it from working.  When this happens, Event 1903 is logged to the Application event log.  That, in concept, is not a problem.

The problem, which appears to be poor design, or a bug, is that the HTML Help appears to constantly try and run multiple times per second, which results in a flood of HHCTRL 1903 messages in the Application log.  This is annoying, to put it mildly.

So, now that we had found the cause of the problem, what can be done to "fix" it?  The ideal solution is for Microsoft to fix the problem, but since this issue appears to have existed for years, this seems unlikely.

My colleague and I then pondered how we might work around the issue.  Since Process Monitor told us that one component of this issue is the hhctrl.ocx file, what if we unregistered or removed the OCX file?  My colleague had tried that before, but because the file is locked by Windows, it can't be deleted or renamed.

And that is where Unlocker comes in.  Unlocker is an elegant Windows utility that lets you rename, move, or delete files that are locked.  I fired up Unlocker and renamed the two copies of the OCX files on my server.  That didn't fix the problem--we suspected that the OCX was still in memory, so I rebooted my server.  And then we tested again.

Eureka!  Renaming the hhctrl.ocx file in the Windows\System32 and Windows\SysWOW64 directories eliminated the HHCTRL messages going to Event Viewer.  We could launch the application as a service, and no messages were sent to the Application log.  So that solved the problem.

But, there is a minor downside.  By renaming the hhctrl.ocx files, we essentially disabled the HTML Help system on Windows, so we were unable to use the F1 key or open any help files.  On a server, I don't think this will be much of an issue, but on a workstation it may pose a problem.

So the options we offered the customer are:

1. Just ignore the HHCTRL messages
2. Disable the HTML Help system
3. Don't use the app service, and instead run the app in a user session

None of these are ideal, but we believe that #1 and #2 are the least inconvenient.

And with that, I am able to finally close the saga of the rampant HHCTRL event log messages.



UPDATE:  Thanks to Bill at JourneyTeam for finding a way to disable the HHCTRL messages with registry entries.

Copy this text into notepad and save the file as hhctrlfix-32.reg:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\HTMLHelp\1.x\HHRestrictions]
"MaxAllowedZone"=dword:00000001
"EnableNonInteractiveUser"=dword:00000001
"EnableFrameNavigationInSafeMode"=dword:00000001


Copy this text into notepad and save the file as hhctrlfix-64.reg:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\HTMLHelp\1.x\HHRestrictions]
"MaxAllowedZone"=dword:00000001
"EnableNonInteractiveUser"=dword:00000001
"EnableFrameNavigationInSafeMode"=dword:00000001


With those two reg files created, double click on them to import the settings into the registry.

Steve Endow is a Microsoft MVP for Dynamics GP and a Dynamics GP Certified IT Professional in Los Angeles.  He is the owner of Precipio Services, which provides Dynamics GP integrations, customizations, and automation solutions.

You can also find him on Google+ and Twitter

http://www.precipioservices.com

eConnect 2010 / 2013 error: Procedure or function 'ta___________' expects parameter '@________, which was not supplied

By Steve Endow

It can be really strange how some Dynamics GP issues come in clusters.  One week, all will be quiet, but the next week, you'll get multiple calls, often regarding the same issue.

Last Saturday, I received an email asking for help with an eConnect error.  An existing POP Receipt integration worked fine with GP 10.0, but once it was upgraded to GP 2013, the import would get the following error when trying to submit serialized XML to eConnect:

Procedure or function 'taPopRctLotInsert' expects parameter '@I_vPOPRCTNM', which was not supplied

For an existing integration that was working fine to have this error suddenly occur after being upgraded is pretty odd.  Obviously you wouldn't submit a lot record without assigning the value for the POP receipt with which it is associated.

I offered one or two guesses as to the possible cause, but those didn't pan out.  But the next day I received an update explaining that they had found the issue.  When they reviewed the serialized XML prior to submission, they found an extra node:

< taPopRcptLotInsert xsi:nil="true" / >

(spaces added to the end caps of the node to keep it from being stripped out by Blogger)

The exact same integration worked fine with GP 10, but has this problem with GP 2013.  It would seem that something changed with the eConnect Serialization library, and one might assume that this is an "eConnect bug".

But not so fast.  I've developed several POP Receipt imports that have upgraded from GP 10 to GP 2010 and 2013, and have not run into this issue.  So I had a hard time imagining that this was a fundamental bug in the POP Receipt eConnect serialization.  In this case, the developer implemented a workaround to strip out the extra "nil" node, and that solved his problem.  But I was puzzled--something didn't seem right.

So this morning I glanced at the GP forum posts, and saw a post titled "eConnect 2010,2013 Bug".  Posts like that always catch my attention, so I reviewed it.

Interestingly, this user was experiencing a very similar issue.  An eConnect integration that worked fine on GP 10 suddenly has a similar error when upgraded to GP 2013.

Procedure or function 'taPMDistribution' expects parameter '@I_vDOCTYPE', which was not supplied

(I'm guessing that the error message was mistyped and actually read "which was not supplied", but perhaps the error message does vary between eConnect methods)

Finding it very odd that I have seen this error twice in less than a week, I tried searching for this particular version, and I found gold.

http://dyndeveloper.com/thread.aspx?Threadid=1069

On this thread, someone else had the same error.  Coincidentally, the last post references one of my eConnect blog articles, but at the bottom, it appears that he traced the issue to how he was dimensioning his taPMDistribution_Items array.

In VB, you can use the ReDim Preserve command to dynamically increase the size of your eConnect arrays as you build them.  Well, if you have an incorrect counter, or forget that you are working with a zero based array, you can easily end up dimensioning your array to be one larger than what it should be.  When you do that, an extra node gets serialized and gets output with the "nil" value.

So here is my theory:  eConnect 10 used to dispose of these extra "nil" nodes during serialization, but eConnect 2010 (and 2013) do not ignore them, and dutifully output them.  So when someone upgrades their integration from GP 10 to 2013, an integration that used to work perfectly may get an error, due to what they will believe is an "eConnect bug".

I also theorize that this issue will only affect integrations that were written in Visual Basic, as VB has the ReDim Preserve command, which is not available in C#.  I speculate that these VB developers are really running into a bug in their integration code that improperly dimensions the array to be one value larger than it should be.

In C#, this is probably very unlikely, but I suppose if arrays were used, someone could still incorrectly dimension the array.  I personally use List<> objects for my eConnect array, and there is no dimensioning required, so I should never experience this particular issue.

I've responded to the forum post, so I'm interested to see if they confirm that they are using VB and if they did improperly dimension their array.

If anyone else thinks this theory makes sense, or has a different interpretation or theory, I'm interested to hear about it!

Steve Endow is a Dynamics GP Certified Trainer and Dynamics GP Certified IT Professional in Los Angeles.  He is also the owner of Precipio Services, which provides Dynamics GP integrations, customizations, and automation solutions.

You can also find him on Google+ and Twitter

http://www.precipioservices.com

Microsoft Project Auto Schedule option

By Steve Endow

I recently started a new project that looked like it would require a bit of planning between at least two different client teams, the GP partner, and two contractors.  I initially created an Excel file to start recording tasks, dates, and estimated hours, but it quickly became clear that it would be difficult to manage the task list in Excel.  When I added a task or changed an estimated date, I had to manually update other dates and try and figure out dependencies.

I almost never use MS Project, but it has some nice features that make it easier to try and figure out dependencies and timeline.  This project was a good candidate, as it has several dependencies, several scope changes, and a lot of changing dates.

Since I so rarely use Project much, I quickly ran into an annoying behavior when I changed a task date:  Dates for dependent tasks would not update automatically.

A red squiggly line would appear in the date for a dependent task, and the Gantt chart would show dashed lines around the task.

I found the option to "Respect Links", which would fix the task dates and Gantt chart for that item--but it would only update the one item.  The next dependent item would then have the same issue, on down the line.

After seeing this a few times, I searched for the issue and found this nice post of MS Project frequently asked questions.  Seems I'm not the only one with this problem.

The solution is to select the Auto Schedule option instead.

This changes the color and style of the task in the Gantt chart and thankfully has the task dates update automatically on the dependency when an upstream task is modified.

This option is also available in the Task Information window.

Presumably this is obvious to MS Project pros, but it took me a few minutes to track it down.

Happy project planning!

Steve Endow is a Dynamics GP Certified Trainer and Dynamics GP Certified IT Professional in Los Angeles.  He is also the owner of Precipio Services, which provides Dynamics GP integrations, customizations, and automation solutions.

You can also find him on Google+ and Twitter

http://www.precipioservices.com

Search for text in all SQL Server stored procedures

By Steve Endow

A customer emailed me this morning saying they were getting this error when posting some batches in their test environment:

The stored procedure glpPostBatch returned the following results:  DBMS: 0, Microsoft Dynamics GP: 20507

I opened up the glpPostBatch stored procedure in SQL Server Management studio and searched the script, but there was no error number 20507.

Hmmm.  So my guess was that glpPostBatch was calling other procedures (which might themselves be calling other procedures), and one of those sub-procedures was raising error 20507.  Rather than dig through the stored procedure and try and track down the sub-procedure, I figured I should be able to search all stored procedures for the error number 20507.

Thanks to this Stack Overflow post on this very topic, I used this script:

SELECT DISTINCT o.name AS Object_Name,o.type_desc
FROM sys.sql_modules m 
INNER JOIN sys.objects o 
ON m.object_id=o.object_id
WHERE m.definition Like '%20507%'


In a few seconds, it found that the number was present in a procedure called smAddPostingSecurityRecord.  I then scripted that procedure, and found this code:

select   @sCompanyID = CMPANYID  from  DYNAMICS.dbo.SY01500  (NOLOCK)  where  CMPNYNAM = @I_cCompanyName   
if @@rowcount <> 1  begin  
select @O_iErrorState = 20507  
break  
end  

So it is querying SY01500 for the company record, and if it doesn't get exactly 1 record, it returns that error number.  Makes sense.  But obviously there should always be exactly 1 company record in SY01500, so that doesn't help explain the error.  My only guess is that something is locking or blocking the table, causing the query to fail or return NULL--I'm skeptical that it is returning 0 or 2, but I've asked the client to check the table to confirm the company record is valid.

If that is what is causing the error during batch posting, then my assumption is that there is little I can do to troubleshoot it.  I've been down this road with glpBatchCleanup errors, and have learned that these types of errors are generally best handled by GP support.

Fortunately, the error is only occurring in the customer's test environment and not in their production or UAT environments, so it does appear to be isolated.  I recommended that they try and restore the Dynamics and company databases to see if that helps.

Steve Endow is a Dynamics GP Certified Trainer and Dynamics GP Certified IT Professional in Los Angeles.  He is also the owner of Precipio Services, which provides Dynamics GP integrations, customizations, and automation solutions.

You can also find him on Google+ and Twitter

http://www.precipioservices.com

Finding your Dynamics GP Site Name to Request ISV Registration Keys

By Steve Endow

This may seem pretty basic to many, but it is such a common issue for me that I want to discuss it in the hopes of clarifying it for GP customers.

I sell several ISV "add-on" solutions for Microsoft Dynamics GP.  To allow customers to use trial versions of the software, and ultimately license the software to customers, I generate software license keys.

Like the Dynamics GP license keys, my ISV license keys are based on the "Site Name" that is entered in the Dynamics GP Registration window, under the Tools -> Setup -> System -> Registration menu (or Administration page -> System -> Registration).

This window is where you type the company name that is provided to Microsoft to generate your Dynamics GP license keys.  Microsoft performs some type of hash or calculation with the company name, licensing scheme, and modules to create Dynamics GP license keys that will allow you to use the software and perhaps also additional modules that you have purchased.

When you trial or purchase an ISV "add-on" solution, the ISV typically generates its own separate license key based on the Site Name.  So in my case, when a customer wants to try Post Master Enterprise, I ask that the customer send me their exact Site Name so that I can generate a trial key.

Surprisingly, I regularly have customers who don't know what it means to find their Site Name, have a hard time finding their exact site name, or more commonly, they send me the wrong site name.  

When finding your Dynamics GP Site Name, every single character matters, and the name must be exact.

The following are five different Site Names:

Consolidated Holding Company Inc

Consolidated Holding Company Inc.

Consolidated Holding Company, Inc

Consolidated Holding Company, Inc.

Consolidated Holdings Company, Inc.

The spelling, spaces, commas, and periods matter.  And, I don't know if it matters for the GP reg keys, but for my reg keys, capitalization also matters.

So it matters if you send your ISV a name of "Consolidators Unlimited, Ltd." with a comma and period, or without the comma or period, or with LTD capitalized.

As a side note, I used to ask people to send me a screen shot of their Dynamics GP Help -> About window, as that window shows both the GP version number and the Site Name.  But there is a catch.

The Help -> About window has a limited amount of space to display the Site Name.  So if the customer has a very long site name, the name will be truncated when it is displayed on the About window.  Once I discovered that, I had to stop using the About window as an option.

There is another popular location to find the Dynamics GP site name, and that is in the Microsoft VOICE system where partners can view and manage their registered customers.  When I am working with partners, they typically understand the Site Name and the need to get it exact, so they either send me a screen shot from VOICE, or know to get the exact site name from the GP registration window.

To help make make our licensing process a little easier, both I and Envisage Software Solutions now display the full site name on our registration key windows.

So when a customer tells us that the license key doesn't work, we ask them to send us a screen shot of the License window so that we can verify the site name.  In most cases, the customer missed a comma, period, apostrophe, or misspelled something.

One other problem that I have had is with Microsoft Office and its "Smart Quotes" feature.  When a customer emails me their site name, if the site name contains an apostrophe, I can't always copy the name into my license key generator.

In the above example, the first line was copied from Microsoft Outlook and pasted into Notepad.  I typed the second line.  Notice that the apostrophe is different.  If I generate a license key by copying the first line, I will generate an invalid key--something I did just yesterday.  I then need to remember to fix the apostrophe or just re-type the entire name instead.

With that said, I have found that Dynamics GP has a relatively simple and easy licensing system that is very easy for ISV solutions to piggy-back on for their keys.  Just make sure to send your ISV your exact site name, exactly as it appears in your GP Registration window!

Steve Endow is a Dynamics GP Certified Trainer and Dynamics GP Certified IT Professional in Los Angeles.  He is also the owner of Precipio Services, which provides Dynamics GP integrations, customizations, and automation solutions.

You can also find him on Google+ and Twitter

http://www.precipioservices.com