RPM update 184.108.40.2065 includes several important differences. First and possibly most important to some people, we’ve made progress with the zero byte problem. That is a vital update for many people, and possibly that’s why you are reading this now.
The other issue we discovered is how to keep the job performance in the database on track. It turns out that once we added a regular “database sweep” to the job processing, database performance stopped degrading over time.
One day this past week I ran a quarter-million jobs through RPM. The performance was great through the afternoon and into the evening. When I checked early the next morning, it was pretty slow.
Here are the steps I took, which I recommend to you.
Step 1: stop the service
You can do this from the Services applet, or if you can run an elevated command line, do this:
net stop rpm
If this fails due to permissions, you are not running an elevated command line. Please log in as the administrator or have someone help you. It’s not a problem we can solve for you (and you don’t want us granting admin powers in your network, right?)
Step 2: go to the RPM install folder
Still using your elevated command line, go to the install folder. On my Windows 10 computer running the 64 bit RPM Elite, my folder is:
C:\Program Files\Brooks Internet Software\RPM
Step 3: run the fixdb script
Run this command:
Here is a sample showing how I ran these commands in an elevated command window:
Note that you may have errors when you run fixdb. This means the program is fixing errors. Consider running fixdb monthly or perhaps more often.
Note that nothing can be using the database. You’ll need to stop the service and exit the user interface before you run “fixdb”.
Step 4: run the installer to update to 220.127.116.115
This is what you normally do when you update RPM. All we have done here is insert a few steps.
For future reference
You don’t normally need to stop the service and run the database maintenance program. I advised it for this update because it won’t make much difference for RPM to run the database sweep internally without running the database fix first.
This is similar to the database maintenance article we posted recently. Nothing here supersedes that article. It’s still relevant. You can shrink the database is fine, no need to contact us over that.
My essential point is that for best overall performance, run the fixdb script, and then the update.