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.
Please help!
*This post is locked for comments
We're now on GP 18.4.1384 and this bug has still not been fixed... I know this doesn't look like to be a high priority, but yesterday we ran into a situation on a customer site where the default views needed to be re-created for a specific company and we never got the DMU into completing the process.. despite all the efforts of trying to kill rogue SPID's..
When can we expect this to be fixed ?
Thanks.
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.. :-(
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 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.
Work-around steps:
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.
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.
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.
Thanks
Thanks Derek,
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 ..
B@
Hello,
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.
Thanks,
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/
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.
Stay up to date on forum activity by subscribing. You can also customize your in-app and email Notification settings across all subscriptions.
#1
André Arnaud de Cal...
291,280
Super User 2024 Season 2
#2
Martin Dráb
230,235
Most Valuable Professional
#3
nmaenpaa
101,156
Share
Report
All responses (
Answers (