My favorite Dynamics GP inventory item for testing

If you have done Dynamics GP demos and had to create a SOP, POP, or Inventory transaction, you've had to choose at least one inventory item to test with.  After doing this enough times, you have probably found an item or two that works.  Preferably one that has quantity on hand, that is assigned to the default warehouse, that is assigned to the vendor, and especially one that isn't serialized.

For years I used to rely on the old standby, 100XLG, our favorite "Green Phone".  It was always at the top of the list, usually had quantity on hand, and was reasonably priced.

But after poking around for additional items to test with, I discovered my new favorite:  FTRUB

Although the description claims they are Rubber Feet, I just love the Item Number, "foot rub". 

Well, yes, it's ERP-geeky, but I thought it was pretty funny. 

FTRUB is now my go-to inventory item for testing.  Post an Inventory Adjustment for 1,000 of those gems, assign it to vendor ACETRAVE0001, and you are all set.


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.

http://www.precipioservices.com

Clearing remembered / default login for SQL Server Management Studio

By Steve Endow

Occasionally I have to test different SQL Server logins with varying permissions to troubleshoot random GP or integration errors.  Sometimes I test those logins by launching SQL Server Management studio and logging in to SQL to confirm they work and behave as expected.

Well, if you have ever tried this, you know that Management Studio suddenly falls in love with the last login that you used and will always display it as the default Login.

So, after I tested with a login of "testuser", every time I launched SQL Management Studio, I was prompted to login using "testuser", and had to always switch to the 'sa' login on my dev machine.  Seems trivial, but it's incredibly annoying, especially when you are just using to pressing enter to login as 'sa' with saved password.

I tried searching for this issue, but didn't get any relevant results.

Thanks to some help from a fellow expert on Experts Exchange, I was pointed to this Stack Overflow thread that explains how to delete the "remembered" logins for SQL Server Management Studio:

SQL Server Management Studio 17.x delete the file 

C:\Users\%username%\AppData\Roaming\Microsoft\SQL Server Management Studio\14.0\SqlStudio.bin

SQL Server Management Studio 2014 delete the file 

C:\Users\%username%\AppData\Roaming\Microsoft\SQL Server Management Studio\12.0\SqlStudio.bin

SQL Server Management Studio 2012 delete the file 

C:\Users\%username%\AppData\Roaming\Microsoft\Microsoft SQL Server Management Studio\11.0\SqlStudio.bin

SQL Server Management Studio 2008 delete the file

C:\Users\%username%\AppData\Roaming\Microsoft\Microsoft SQL Server\100\Tools\Shell\SqlStudio.bin

SQL Server Management Studio 2005 delete the file – same as above answer but the Vista path.

C:\Users\%username%\AppData\Roaming \Microsoft\Microsoft SQL Server\90\Tools\Shell\mru.dat

Deleting the SqlStudio.bin file worked like a charm, and my 'testuser' is now nowhere to be found.

Just be aware that deleting the file will clear ALL saved server connections, logins, and saved passwords.

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

Priorities and Modern Worklife

As a mom of one, and pregnant with my second, this really struck a cord with me.  I don't post often on  here on "soft" topics, but I think this is an important one-- particularly for those of us in the consulting world :)

http://www.cnn.com/2012/04/16/opinion/stone-leave-work-day/index.html?hpt=hp_c1

Resolution for eConnect 2010 Error: The Transaction Has Aborted

Back in September 2011 I wrote about an error I was receiving with a few eConnect 2010 integrations.  In apparent random fashion, the integration would throw the following eConnect exception:

     The transaction has aborted

I researched every aspect of the error that I could think of, and tried every workaround I could imagine, but the error would still occur intermittently with two integrations.  Strangely, the error did not occur with 10 other eConnect integrations running on the same server.

I created a GP support case and worked with Aaron at MS Support over several months trying to figure out the cause and possible ways of troubleshooting the problem.  A few weeks ago, Aaron contacted me to let me know that another customer was getting the same eConnect error, and that they seem to have found the cause.

That customer was calling the eConnect GetNextSopNumber class, and in the process, was also using the Dispose method when using that class.  GP support was able to reproduce the issue with those two elements, apparently triggered by the Dispose method, and they have documented it as a bug.

My two integrations that were getting the error don't use GetNextSopNumber, so I was initially concerned that the other customer's solution wouldn't apply to me.  And as a general rule, I never use Dispose, so I was further concerned that I might be dealing with a different cause for the error.

I found my source code and realized that the two integrations getting the error were older projects that were written in VB, which I stopped using in 2010 after I switched to C#.  I then searched the project for "Dispose", and to my surprise, I was calling the method after submitting data to eConnect.

            returnValue = eConCall.CreateTransactionEntity(gpConnString, transactionXML)
            eConCall.Dispose()

After each call to CreateTransactionEntity and CreateEntity, the Dispose method was being called.  I obviously copied that line from somewhere / someone, since I can't imagine that I would have added the call on my own and have never used it in any of my C# integrations since.

So I went ahead and commented out the Dispose method and deployed the new integrations on the client's server.

It has been about two weeks since I made that change and we haven't had a transaction aborted error since.  We're still monitoring the logs to confirm that the issue is fully resolved, but it's looking good so far.

So, it seems that calling Dispose with any eConnect 2010 class can trigger the error, and simply removing the Dispose call should resolve the issue.

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.

http://www.precipioservices.com