web
You’re offline. This is a read only version of the page.
close
Skip to main content

Notifications

Announcements

No record found.

News and Announcements icon
Community site session details

Community site session details

Session Id :
Dynamics 365 Community / Forums / Finance | Project Operations, Human Resources, ... / Strange behavior with ...
Finance | Project Operations, Human Resources, ...
Suggested Answer

Strange behavior with GP 2018 upgrade

(0) ShareShare
ReportReport
Posted on by Richard Wheeler 75,850 Moderator

Here is something I have never seen before. Upgraded GP 2013 to GP 2018 R2 on the server. All runs fine. I created a package file pointing to the GP 2018 instance and then went to the workstations to install GP 2018. Much to my surprise I am getting the usual message about product xxx does not support upgrading from 12.xx.xxx. I get this on workstations that never even had GP 2013 on it. Something is redirecting the DSN to the wrong server. In ODBC administrator Dynamics GP 2018 is pointing to the correct server. Has anyone else ever seen such behavior?

Categories:
Microsoft Dynamics GP
I have the same question (0)
  • Suggested answer
    Derek Albaugh Profile Picture
    Derek Albaugh on at

    The 'product xxx does not support upgrading from 12.xxx.xxx' doesn't have anything to do with whether the workstations had GP 2013 on them or not, I'd be more curious if, in this install package, you selected additional features that you didn't select on the server when upgrading, and there are records in the DB_Upgrade for those additional features, that are at too low a version/build of GP 2013 to upgrade to the GP 2018 R2 you're upgrading to.

    If it is looking at the wrong server, it may be seeing an old DYNAMICS/system database as well and pulling the wrong data.

    That being said, I can't say I've seen the behavior with installation packages for Dynamics GP.

    Thanks

  • Richard Wheeler Profile Picture
    Richard Wheeler 75,850 Moderator on at

    Derek, this was my fault. This client has 12 companies, including TWO. When I copied their databases to our data center I had neglected to include TWO so when I sent the data back over the TWO database was there from a prior upgrade test but now DYNAMICS.DU0000020 still had TWO back at GP2013 as it did not upgraded since it did not exist in our data center. I am surprised the upgrade went through on our end since I would have thought that GP Utilities would have complained about the missing database.

  • Suggested answer
    Derek Albaugh Profile Picture
    Derek Albaugh on at

    It may have been that the DB_Upgrade didn't show TWO at a invalid version to upgrade, so GP Utilities never noticed anything, but the Dynamics GP application, which looks at the DU000020 table instead, noticed it.

    Weird though........

  • Richard Wheeler Profile Picture
    Richard Wheeler 75,850 Moderator on at

    Derek, I also noticed there are several companies in the dbupgrade and du0000020 tables that do not exist in the SY01500 table. Can I simply delete them? There is also an entry for prod id 3107(Extender) in all companies on version 9.. That is the old GP Extender. Is it safe to remove them as well?

  • Suggested answer
    Beat Bucher GP Geek GPUG All Star Profile Picture
    Beat Bucher GP Gee... 28,058 Moderator on at

    Hi Richard,

    yes it is safe to delete them from the DU000020 table, but you should also check other related tables that hold product ID's version (DB_Upgrade, DU000030, and maybe more).

    If you have GPPT installed, you can use the "Fix Utilities" in the database validation to check for old product entries and get rid of them.

    Derek,

    I've discovered an annoying bug in the new deployment package feature from GP 18.2.. when you set the new folder name where GP should be installed, it's not respecting it.. If I set the folder name to be 'GP', after the Workstation install, it ends up being GP2018..  I know this sounds like a minor issue, but it means also that if you have post-deployment scripts that are based on that path, they will fail.

    If you run the GP Setup manually though, the default path folder name is defaulted to "GP"..

  • Richard Wheeler Profile Picture
    Richard Wheeler 75,850 Moderator on at

    I can confirm Beat's findings. Installing GP from the installation package will always create C:\Program Files (x86)\Microsoft Dynamics\GP 2018 and not  C:\Program Files (x86)\Microsoft Dynamics\GP, if that is what was specified.

  • Suggested answer
    Derek Albaugh Profile Picture
    Derek Albaugh on at

    If you have companies that no longer exist in the SY01500 table, and don't exist on the SQL instance you're on, it is probably better to run the ClearCompanies script, which will remove all mentions of that company database from the system database, thus cleaning it out better than just manually deleting records from the DB_Upgrade, DU000020 and DU000030 tables, which you could also do.  (The DU000030 table can actually be completely empty and recommend doing so it won't cause issues with future upgrades).

  • Suggested answer
    Derek Albaugh Profile Picture
    Derek Albaugh on at

    We have this written up as a documented issue that is scheduled to be fixed in the fall release of Dynamics GP as it has been found in the 18.2 version of Dynamics GP as well. The installation package will default to a 'GP2018' directory, even though you specify a default location of C:\Program Files(x86)\Microsoft Dynamics\GP\

    Thanks

  • Richard Wheeler Profile Picture
    Richard Wheeler 75,850 Moderator on at

    Derek, can you please send over the copy of ClearCompanies script you reference? The version I have leaveS db_upgrade, DU0000020 and DU0000030 unchanged. I still see prod id 3107 plus companies that do not exist in SY01500.

  • Suggested answer
    Derek Albaugh Profile Picture
    Derek Albaugh on at

    As long as the database doesn't physically exist in the SQL instance you're running it against, the ClearCompanies script should remove from DB_Upgrade and DU000020, as I just verified it to make sure.

    That being said, this is the 'new' ClearCompanies' script, which is pretty much the same as the original, but it doesn't remove from the ADH00100 table, which causes SmartList to not work. I wasn't able to link it here, but Jen Kuntz has it on this page:

    https://community.dynamics.com/gp/b/kuntzconsulting/posts/clear-companies-script-amp-custom-tables

    Thanks

Under review

Thank you for your reply! To ensure a great experience for everyone, your content is awaiting approval by our Community Managers. Please check back later.

Helpful resources

Quick Links

Responsible AI policies

As AI tools become more common, we’re introducing a Responsible AI Use…

Neeraj Kumar – Community Spotlight

We are honored to recognize Neeraj Kumar as our Community Spotlight honoree for…

Congratulations to the November Top 10 Community Leaders!

These are the community rock stars!

Leaderboard > Finance | Project Operations, Human Resources, AX, GP, SL

#1
Martin Dráb Profile Picture

Martin Dráb 451 Most Valuable Professional

#2
André Arnaud de Calavon Profile Picture

André Arnaud de Cal... 428 Super User 2025 Season 2

#3
BillurSamdancioglu Profile Picture

BillurSamdancioglu 239 Most Valuable Professional

Last 30 days Overall leaderboard

Featured topics

End-of-life Announcement for Microsoft Dynamics GP

Product updates

Dynamics 365 release plans