Hi - we have an issue in upgrading between versions of the databases, and are hoping for any assistance or insight. We have an old Progress 7 database that is being upgrade to the latest version. We are able to upgrade that DB from 7 to 8, but it routinely fails when upgrading from 8-9. We have seen it succeed a couple of times, but that involves a lot of varying factors that we have not been able to identify.
Instead of using the convert scripts, we are directly running the _proutil commands manually to try and isolate the problem. Specifically, "91_proutil.exe db_name -C conv89"
The error is mvGetRecord(drPopulateTable): failed with -1 (7065).
Also, we are running on Windows Server 2008 R2 (64-bit), but have also tried 32-bit versions. I'm currently re-installing the 32-bit version to try again that way.
Any suggestions or help?
Thank you!!
If you're going to version 11, I'd suggest a dump & load. That'll allow you to go to Type II storage areas, and not have to worry about running into conversion issues like you're seeing now.
Thanks, Tim. I'll definitely explore the dump & load process again. Some of our team members were looking at that earlier and were finding that the process was taking 2+ days to complete (on pretty beefy hardware). The DB itself is pretty small (< 4 GB), so that timing definitely seems to be wrong. The challenge is that this will be a live production system being upgraded, so we won't be able to take the database down for very long during the maintenance window. Possibly over a weekend, but that is cutting it close.
Have folks had success working through conversion issues such as the one we are encountering, or is that usually a dead end and results in a dump & load being the only path forward?
Is this database already a multi-volume database.
If doesn't, you have first to convert to a multi-volume database. I don't remember de command. I think it's something like
_proutil database -C make multiv
Thanks, Adriano - yes, the DB is already multi-volume so we are good there. For the conversion between 8/9, we've tried the proutil Conv89 command both with and without the -z argument (that argument was in the upgrade .bat scripts). Not sure what that arg does, but figured I would add that extra detail in case it is helpful to you or somebody else reading the post.
I found an old kbase with this error with some sugests
2 days to dump 4G? Can you post your configuration? There's no way contemporary hardware should take more than an hour tops, and even that time would be considered suspect and open to improvement.
10 years ago you could dump and load 4GB in about an hour on fairly crappy hardware -- I did it as part of several Exchange & PUG presentations.
Today you should be able to do it in half that time. Or less.
I suspect that your team was looking at the "dictionary" dump & load that does tables one by one in sequence.
This can be done quickly -- but it takes some time up front to prepare and test the process.
I'm currently running the full index rebuild test, which was recommended in the article linked by Adriano. Will let you know the results when that has completed.
I don't have the dump/load configuration in my environment, but I'm hearing loud and clear it shouldn't take very long. I'll also work today to prepare that process in my environment to either confirm it can run faster or to detail the configuration if it takes a long time. I suspect ChUIMonster is right that a dictionary dump/load was being done, but even then, it sounds like it should run faster.
Thank you to all the responses so far... definitely helpful.
Note that configuration is important. You can slow things down a lot or speed them up depending on what you dump from and to.
Final update - the process recommended in the link by Adriano worked well. The issue can now be worked around - thank you!
In short, after upgrading the DB from v7 to v8, the indexes should be rebuilt before upgrading to v9. Using the 83dbutils, we added 'proutil <DBName> -C idxbuild ALL' to our process.
> On May 31, 2016, at 4:11 PM, Dan Johansen wrote:
>
> I suspect ChUIMonster is right that a dictionary dump/load was being done, but even then, it sounds like it should run faster.
definitely should run much faster. however, v7 does not have a binary dump so you have to conv78 first, then binary dump.
and v8 does not record the character set in the *.bd files, so you have to remember to make sure the target db has the same character set.
fer shure it should take less than an hour to dump /and/ load with a decent box.