Choose your path Increase your proficiency with the Dynamics 365 applications that you already use and learn more about the apps that interest you. Up your game with a learning path tailored to today's Dynamics 365 masterminds and designed to prepare you for industry-recognized Microsoft certifications.
Visit Microsoft Learn
2020 release wave 1Discover the latest updates and new features to Dynamics 365 planned through September 2020
Release overview guides and videos Release Plan | Preview 2020 Release Wave 1 Timeline
Ace your Dynamics 365 deployment with packaged services delivered by expert consultants. | Explore service offerings
Connect with the ISV success team on the latest roadmap, developer tool for AppSource certification, and ISV community engagements | ISV self-service portal
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance TechTalks | Customer Engagement TechTalks | Upcoming TechTalks
Hi, I have upgraded a client to GP 2018R2 and now the Database Maintenance Utility cannot be launched as the dbmaintenance.exe file is missing.
Has this happened to anyone else?
I have reinstalled on a new machine and same issue.
Yes, for whatever reason, the Database Maintenance Utility file got removed from the GP 2018 R2 installs, but does exist in GP 2018 installs and prior.
If you copy the DBMaintenance application file to the GP 2018 R2 directory, it will work.
I will try this and let you know. I had 2018 installed and then ran the kb file to get it to 2018R2 so i cannot verify if the 2018 install had the exe file for the dbmaintenance.
Thanks, this worked. I wonder if Microsoft is planning to fix this or if it is intentional.
What if this is a fresh installation of GP 2018 R2 and there is no file to copy? Is it found in any of the subfolders in the install media or do we need to find a copy from some other installation?
What I found is once I install 2018 the plain version, the dbmaintenance file is there. When I apply hotfix MicrosoftDynamicsGP18-KB4099101-ENU the file is wiped out. I didn't try installing plain 2018R2.
Ali, I will need to install GP 2018 on a non-GP workstation and then copy that file to an installation folder for GP 2018 R2. All of our GP workstations have now been upgraded to R2. Looks like Microsoft has got to start beefing up their QA/QC. Too many omissions like this lately.
I'm currently testing the GP Maintenance utility following a process I used to rename a GP instance and/or setup a different instance name.
However, when trying to run the tool, it works only against the Company DB's, but the DYNGP (system DB) doesn't do anything, no matter what objects I select, nor which module I try to run this against..
This is GP 2015R2 on a SQL 2014.. Tried both Windows & SQL authentication..
The blog post I'm referring to is here : https://blogs.msdn.microsoft.com/developingfordynamicsgp/2012/09/25/using-the-named-system-database-feature-for-microsoft-dynamics-gp-2013/
I actually may have re-created the same thing on my GP 2015 R2 instance and it isn't even a changed system database.
When I run the DMU against both the system and company databases, it does nothing and doesn't throw an error at the end.
If I choose just the company database it runs fine.
I also restarted the SQL service to make sure all connections were dropped.
Let me look at this more, probably next week, and I'll let you know what I find out.
I was just thinking I was foolish.. as it is working with the GP 2013 version... I don't have a 2018 right now to test.. so can't speak for that version.
Thanks for confirming that it's not my system DB :-) (tried 2 different names instances and none was working, except for the company DB's).
There is no rush, but I'd like to get this fixed as I may soon have to use it for a migration ..
I was testing this some more and I can actually duplicate the issue in GP 2015, GP 2016 and GP 2018, using more than one install on each version.
What I found with all of them is that I could select the system and company database, modules and objects, then click Next and nothing would happen. Try it again without marking the system database as the only difference, and it would go through.
I found that this was/is a known issue and I was able to use this information to get the DMU to run through even on the system database:
1. Log into DB Maintenance.
2. Select all company databases and the Dynamics database.
3. Select all products
4. Select all options
5. Stop at this window
6. Open SQL Server Management Studio and run the following command in a new query: SP_WHO2
7. Look through the results and find your Dynamics/system database.
8. You will want to look at the SPID column and take note to the second SPID value
9. You will then run the following command in a new query, replacing the SPID number replacing 52 in this example: Kill 52
10. Then go back to DB Maintenance and click Next.
11. You will see it start to go through the progress and then see a results page with green check marks next to all products and databases.
I tested this and the system and company databases, for all features and all objects ran successfully.
Apparently the issue is because the DMU is creating two connections to the same databases, thus the reason why it hangs and doesn't do anything until we kill one of the connections.
Let me know if this doesn't work for you.
Thank you Derek Albaugh,
I was able to re-produce the issue and get around it by following your instructions..
The faulty session that is started in parallel to the correct one contains this SQL command.. which could be the culprit. Though I'm still unclear why it wouldn't work, because it's failing in both Windows & SQL Authentication mode.. But then again, I don't have the code and what it is supposed to do at this stage.. :-)
it would be nice if that could be fixed at some point in time, as it's not really practical to support and explain to a client.
It appears it was documented as a known issue but not sure if it went anywhere, I added my information to it with these steps and the work-around, so hopefully it'll get fixed.
I'm actually seeing two records from sp_who2 for my system database and killing one allows the DMU to go through with the system database successfully, whereas if I don't do these steps, it won't do anything at all, but also doesn't throw any type of error message.
The actual steps I used were/are:
1. Make sure all users are out of Dynamics GP and SQL Server. Stop and restart the SQL Server service.
2. Run sp_who2 and make sure no SPIDS for GP databases.
3. Launch Database Maintenance Utility from Dynamics GP 2018 R2 by right-clicking on DBMaintenance file and choosing 'Run As Administrator'
4. In the Database Maintenance Utility, once I enter the SQL Server and system database, when I run sp_who2 again, I see two SPIDS for my system database that I specified, both show 'AWAITING COMMAND'.
5. Marking the system and company databases, all features and all objects to re-create in the Database Maintenance Utility, nothing happens and it just goes to the Finish screen with no errors or anything showing at all.
6. If I repeat the steps 3-5 but only marking the company databases in the Utility, not the system database, everything works fine.
7. If I launch the Database Maintenance Utility again, put in the SQL connection information, select the system and company databases, all modules and all objects to re-create, but stop there....
8. Running sp_who2 again, I still see the two records for my system database for Dynamics GP, so I use the KILL command to kill/remove the 2nd SPID, leaving only one record for my system database.
9. At that point, back in the Database Maintenance Utility, I click to continue and now it will re-create the selected objects for the selected modules, for both the system and company databases for Microsoft Dynamics GP, without errors. The Finish window shows green check-marks on everything.
I've verified this is the case for different builds of Dynamics GP 2015, GP 2016 and GP 2018, including GP 2018 R2.
I'll get the documentation updated and back to our development team and hopefully we can get that fixed, as the DMU is something handy for troubleshooting and we use it a lot here on the support team as well.
Thanks for pointing it out to us, so we can get it figured out.
Thanks, Derek. I was struggling with both of these issues - dbmaintenance.exe missing and not working on the system db. (All while going through the process to rename the system db on GP 2018.) This was a HUGE help.
It is now Dec. 14th, 2019, and this bug is still around in the latest build of GP (18.2.1036).. I've a brand new setup on a brand new SQL 2016 server at a customer's site, and the DMU is still not working..
Can you please check if there was any update on this bug report ? when is that planned to be fixed..? it just goes behind my mind that you have to fiddle around with the SQL processes and kill processes to get this working.. :-(
Business Applications communities