eConnect 2010 - eConnectProcsRunFirst

eConnectProcsRunFirst is not part of eConnectProcessInfo for eConnect 2010

eConnectProcsRunFirst is not present in the schema for GP2010 eConnect. Just to confuse people, the documentation in the eConnect SDK still references it in quite a few places still.

Converting eConnectProcsRunFirst to use eConnect 2010

What to do when converting previous versions? It seems to be very simple, the order of the nodes in the XML document submitted to eConnect defines the run order. So if a custom stored procedure is required to run first, ensure it is placed first in the XML document relative to the item it must run ahead of. Yes it is that simple!


eConnect Invalid object name ‘PA01901’ GP2010 sp1

After test upgrade of one of our GP installations we were getting the above error when trying to create a purchase order via eConnect. ‘PA01901’ is one of the project accounting tables, a module we don’t have installed.

Late into the night I Googled the issue and found almost nothing about it, also tried Customer Source where again there were some whispers but no substance.


I downloaded the service packs for eConnect. After applying eConnect Service packs for eConnect version11 up to pack 2 we still had the error.

Service packs tried;

After some pointers from a GP contact I have, it turns out that the eConnect stored procedure. taPoHdr is to blame. You can see the check below for the existence of the table in that procedure, the point at which the failure occurs.

if exists(select 1 from dbo.sysobjects (nolock) where name  = 'PA01901')
and exists (select 1 from POP10110 (nolock) where PONUMBER = @I_vPONUMBER)
and not exists
(select 1 from PA01901 (nolock) where PATranType = 6 and PADocnumber20 = @I_vPONUMBER)


The statement tries to see if it has any rows in the table if it exists or not. Obviously if it does not exist you can’t read the rows and falls over, it should have been nested logic here. An easy scripting mistake to make, shame it made it into production code though. It does prove the importance of coverage in testing and checking all code paths…


This can be corrected as shown below by nesting correctly. This is how the problem is solved if GP2010 SP2 is applied. This change to the stored procedure is prevented as a user as this is a protected stored procedure, encrypted to prevent tinkering. I imagine if you managed to decrypt the stored proc and apply the fix to a live environment, it would not be supported.

if exists(select 1 from dbo.sysobjects (nolock) where name  = 'PA01901')
if exists (select 1 from POP10110 (nolock) where PONUMBER = @I_vPONUMBER)
and not exists
(select 1 from PA01901 (nolock) where PATranType = 6 and PADocnumber20 = @I_vPONUMBER)


You could try scripting out the table from your Fabrikam or TWO sample databases and using that to create an empty PA01901 table. However if you have not installed project accounting, it is unlikely to be there either. My other concern with that approach is that if you put those table in, other scripts might start trying to behave as if Project Accounting is installed, trying to add data to other tables that may not exists.
Safer to just get GP2010 SP2 installed.

The above post was the only related post I could find.

Dynamics GP Macro Reference II

After working to support Dynamics GP Macros in our Visual Studio add in for GP I discovered a new layer of macro language not touched on in Mark Polno’s publication of Kevin Gross’s GP Macro Reference.

How to use macros to activate .NET add in forms

Use the following command:
NewActiveWin dictionary ‘default’ form [customID] window [.NET form name]

[customID] seems to be a jumble of characters to uniquely identify this as a addin form.
[.NET form name] is the .NET form name for the form we are trying to show.
NewActiveWin dictionary 'default'  form pARthOSt window AuxFormIV00101


Macro commands passed to RecordMacroItem

Any commands sent to the Macro subsystem from the .NET form are wrapped in a wrapper named “ShellCommand”. To record macro commands to the currently recording macro, call the following method on the form derived from Microsoft.Dexterity.Shell.DexUIForm.

RecordMacroItem(MacroCommandText as string, MacroComment as string)

The text passed in MacroCommandText is wrapped in a “ShellCommand” statement in the resulting macro file, as shown here where the highlighted text represents the string passed as the MacroCommandText when the macro was recorded;

ShellCommand 'ViewWebsiteInformationToolStripMenuItem_Click'
ShellCommand 'ClickHit field "btnOK"'


Long Macro Lines

There is another scenario that must be dealt with, the Add in macro equivalent of
ContTypeTo field 'Account Description' , 'nt 1'
This command would continue typing into the field Account Description appending to whatever is already there. The macro system wraps the whole lot in a ShellCommandBegin block, with each line starting ShellCommandAppend. The following is an example of this arrangement:

ShellCommandAppend 'TypeTo field "rebHTMLText", "<ul>
<li>HDMI cable with swivel ends - up to 180 De'

ShellCommandAppend 'grees </li>
<li>Reduces stress on your cables and risk of disconnecting </li>

ShellCommandAppend 'i>Provides both high definition video and multi-channel audio connection between'
ShellCommandAppend ' digital high definition AV sources such as Blu-ray, DVD players etc. </li>

ShellCommandAppend 'Transfer bandwidth: 10.2Gbps / 340Mhz (v1.3)</li>
<li>Signal Type: Transmission '

ShellCommandAppend 'minimised differential signalling (TMDS)</li>
<li>Connector Type: Gold plated </'

ShellCommandAppend 'li>


Dynamics GP Visual Studio Tools Toolbar

How annoying is it that docking can’t be used when developing add ins for Dynamics GP forms? If a panel is docked it slides under the toolbar at the top but upsets the visual styles such as the separator lines on the buttons.

See below where the panel has been put behind the toolbar, loosing the button effects and toolbar visuals (see highlighted area). The toolbar it seems is painted onto the form itself.


Just one of those niggles. I end up floating all my controls in a container with anchors set for all directions, nothing like as robust as just setting dock>fill.