Dynamics GP folder path incorrect when using Create Installation Package utility

GP Create Installation Package Menu

Application folder for Dynamics GP moved

The default installation package location moved for the Dynamics GP application to

C:\Program Files (x86)\Microsoft Dynamics\GP

for releases after GP2018. Previously it was in C:\Program Files (x86)\Microsoft Dynamics\GP2018, where the GP2018 was replaced with the version of GP. As the versions are no longer linked to years this was dropped as a folder naming pattern.

Create installation package utility

The Create Installation Package utility, found on the GP installation media main menu, did not get this memo about the folder change, or it introduced a bug to be more accurate. We find it broken since this change was made. After creating an installation package, and then using that installation package to install GP, the folder is not “C:\Program Files (x86)\Microsoft Dynamics\GP”, instead it is “C:\Program Files (x86)\Microsoft Dynamics\GP2018”, as it was in the previous version.

I’ve just tested this with the GP2019 fall release, and that release (V18.4) still will install the application into the “wrong folder”.

When the package is built we are prompted for the folder location:

Dynamics GP Installation Package folder C:\Program Files (x86)\Microsoft Dynamics\GP2018

As can be seen the location is correct (C:\Program Files (x86)\Microsoft Dynamics\GP\).

What makes things worse it reports that if you specify the local location for the dictionary, the resulting launch file (.SET) will then happily mix the file locations, resulting in mixture of folders in the .SET file for GP and GP2018!

Report DIC and Forms DIC locations

The fix/workaround

I stumbled on a fix or work around on Ian Grieve blog with this comment at the bottom of the hands on guide to using the Create Installation Package utility (which if you are not familiar with this, then that is a good guide to go by:


Hands On with Microsoft Dynamics GP Fall 2021 Release: Create Installation Package

So if we try this by removing that trailing slash as shown below, then indeed the application ends up, correctly in the GP folder rather than the GP2018 folder! I have no idea how whoever it was discovered this but well done!

remove trailing slash from install path

See how the slash has been removed, it works!

Dynamics GP Install/upgrade failed SyCompanyImages

install upgrade failed syCojmpanyImages

Interesting issue with upgrading Microsoft Dynamics GP.

The upgrade stopped at the above step

Microsoft Dynamics GP Utilities install/upgrade failed

Turns out this was linked to deleting companies from this instance of GP, and the delete leaving orphaned records in the DYNAMICS..SyCompanyImages table.

The syComanyImages table holds the images used by word template reports, that are uploaded using the form below:

Reports>>Template Configuration>>[Images] button

Company Images Window Dynamics GP

There was an orphaned record from the deleted company in the table that is used to back that form. The extra record was removed using the following script:

DELETE FROM Dynamics.dbo.syCompanyImages
   SELECT  (CMPANYID) FROM  Dynamics.dbo.SY01500 )

Note that I don’t understand how this table works entirely, other than its holding a binary blob of the image, that is referenced back in this bizarre /65536 formula. I would check what records will be deleted before actually running this script.

Note that It is important to have ran ClearCompanys.sql - Script that will clear out all entrys in the DYNAMICS database referencing databases that no longer exist on the SQL Server, BEFORE running the above script. This is to make sure that SY01500 only has companies that have databases associated with them.

Dynamics GP Smart List Export to Excel found a problem with content, repaired records

After moving to from Office 13 to 365 the following error appears when users export from Dynamics GP smart lists to Excel.

We found a problem with some content in 202222-1232S9.XISX. Do you want us to try to recover as much as we can? If you trust the source of this workbook, cick yes

Found a problem with some content in Do you want to try to recover as much as we can?

Followed by

Excel was able to open the file by repairing or removing the unreadable content.
Repaired Records Format from /xl/styles.xml part (Styles)

Repaired Records: Format from /xl/styles.xml part (Styles)


The file generated as a log says pretty much the same thing

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<recoveryLog xmlns="http://schemas.openxmlformats.org/spreadsheetml/2006/main">
     <summary>Errors were detected in file ’C:\Users\***\AppData\Local\Temp\202222-123259.XLSX’</summary>
         <repairedRecord>Repaired Records: Format from /xl/styles.xml part (Styles)</repairedRecord>


By adding the following line somewhere in the Dex.Ini file (normally in the Data subfolder of the application folder of GP), resolved the issue in this case.


This ini switch is not compatible with the GP web client if you are using that.


Undocumented DEX.INI switch cuts down SmartList export times to Microsoft Office Excel

Smartlist: Exports slowly to Excel – Part 1

Dynamics GP–syWindowDefaults cannot find the table SY01407

A get/change operation on table ‘syWindowDefaults’ cannot find the table.

After upgrading a Dynamics GP system from GP2015 => GP2016 => GP(18.4) the following error occurred on opening some enquiry windows in GP;

A get/change operation on table ‘syWindowDefaults’ cannot find the table.

Invalid object name ‘SY01407’

Invalid object name ‘SY01407’

The above window is used for the “The Default Inquiry Sort options for Payables, Receivables and Bank Reconciliation”, a feature introduced in 18.4 version of Dynamics GP.

According to the linked documentation, this feature saves some of the field settings and window sizes for windows:

     Receivables Transaction Inquiry - Customer  (Inquiry > Sales > Transaction by Customer)

     Receivables Transaction Inquiry - Document  (Inquiry > Sales > Transaction by Document)

     Payables Transaction Inquiry - Vendor  (Inquiry  > Purchasing > Transaction by Vendor)

     Payables Transaction Inquiry - Document  (Inquiry > Purchasing > Transaction by Document)

     Checkbook Register Inquiry  (Inquiry > Financial > Checkbook Register)

     Checkbook Balance Inquiry  (Inquiry > Financial > Checkbook Balance)

     Sales Order Processing Item Inquiry  (Inquiry > Sales > Sales Items)

The information for the feature is stored in the following table:

Dynamics GP table name: SY01407
Dynamics GP Technical Name: syWindowDefaults


Checking in the database to see if the table was in SQL server, proved it was not:

select * from DYNAMICS..SY01407

Msg 208, Level 16, State 1, Line 1
Invalid object name 'DYNAMICS..SY01407'.

So it would seem this table got missed when the GP installer/upgrade scripts were created!

There is evidence of other people having similar experience on the forums, Inquiry error message missing table SY01407

Creating building table SY01407 and its associated database objects

Being a new table it is easy to build as you don’t need to worry about pre-existing data. Do so using the Dynamics GP SQL Maintenance window as user sa.

Microsoft Dynamics GP>>Maintenance>>SQL

Select Database DYNAMICS

Product Microsoft Dynamics GP

Locate the table in the list (“System Window Defaults”) and select it (you will see 1 object selected as shown below)

Select the checkboxes to “Create Table” and “Create Auto Procedure

SQL Maintenance Window Dynamics GP

Then select Process button, the missing table will be created along with some stored procedures and now the error messages should stop occurring as the defaults feature should start to function.

Thanks to Beat Bucher for confirming the issue for me and confirming I could use the above window to build the missing database object.

He noted there is also a script you can obtain from GP support if you raise a ticket, that effectively does the same thing as the GP client does above.

Resulting database objects created


stored procedures:






Important Note:

Although this will get you running, it may be a sign of other issues with the upgrade. It is always important to run a dummy upgrade and perform User Acceptance Testing on it to ensure everything is ok before doing the upgrade of the production environment.