Answered Binary D&L from 10.2B08 to 11.7.5


Active Member
We are moving a customer to a new server and converting the db from 10.2.B08 to 11.7.5.

Is it possible to do a binary dump on the 10.2.B08 server and load the binaries directly into the 11.7.5 db or do we need to move the db to the new server, conv1011, then do the dump and load into an empty db (of course with the schema loaded)?

I should probably know this but am not sure.

Rob Fitzpatrick Sponsor
You won't need a conv1011 because after dumping your data, schema, users, etc. from the v10 database, you'll be loading the schema and data into an empty v11 database that was created with 11.7 prostrct create.

You could choose to dump on the old server, transfer the files (or write them directly to storage shared between the servers) and then load on the new. Alternatively, if the new server is a lot faster than the old then it might be advantageous to move the DB to the new server to dump there.

It's hard to say what's appropriate, because it depends on factors like database size and the duration of each phase (dump, transfer, load, idxbuild) on the different servers, compared with the downtime window available from the business.


Active Member

We already have an automated script generation process that does all the work up to and including the idxbuild, so that is not the question.

My concern is whether the binaries from the 10.2B08 db are compatible with the binary load on 11.7.5.

Previously we've not created a new server, and just did the conv1011 and then binary d&l on the same server. I have not tested trying to do binary loads directly (although we can certainly do it in this case), but was just wondering if they are compatible to load.

FYI -- db is small (less than 5GB), and we will have an appropriate window for the conversion since we will be doing it in test modes for timing prior to the "live" conversion.


The .bd file format is upward compatible. You can always dump from a lower version and load into a higher version.

(Ok, a long time ago there might have been a few glitches with that - but those are far in past and could be worked around without too much trouble.)


Personally I prefer approaches where the source database is left untouched and where your fall back position is to continue using the old system if anything goes wrong getting the new one loaded and ready.

Rob Fitzpatrick Sponsor
Sorry Larry, I guess I didn't understand your plan; maybe I still don't. Typically when I do a server migration/D&L, the plan looks like this:
  • the current DB and old DLC are on the old server, and the new DLC is never installed there
  • the new DLC is installed on the new server
  • the desired end state is that the newly dumped and loaded DB runs on the new DLC on the new server
  • the DB is prepped and dumped on the old server on the old DLC
  • the dump files are transferred to the new server
  • a prepared (prostrct created/extended) empty DB is already on the new server, with schema loaded
  • the dumped data is loaded into that DB with the new DLC
  • backup, idxbuild, verification, compile, business validation, yadda yadda, business go/no-go decision
  • go live
I may need to get creative if the window is narrow and a plan like this won't fit but that isn't often the case.

That's me. Now for your plan:
We are moving a customer to a new server
This is why I talked about server migration, but based on the next quote I'm not sure now if that's happening.

Previously we've not created a new server, and just did the conv1011 and then binary d&l on the same server.
If you're doing D&L, you don't need conv1011. If you're doing conv1011, you don't need D&L, unless the server migration also involves a platform migration, e.g. Windows to Linux. Although you could be choosing to do a D&L, for various reasons, even though it isn't strictly required. In that case, again, you don't need conv1011 since the load is into an empty DB that is v11 to start with, so nothing to convert.

My concern is whether the binaries from the 10.2B08 db are compatible with the binary load on 11.7.5.
No. You want to load into a v11 database, and 10.2B binaries can't create or open one.


Active Member
I was probably unclear. By binaries I meant the files created via the binary dump.

Previously we have upgraded customers without a new server, so we do all the work on the same server. Create new empty v11 db, load schema backup new db in case of restarting. Load users, sequences, etc. Shut down existing prod db, backup db, restore old db to new directory, do a conv1011 on old db, binary dump, , load binaries, idxbuild, validate new db counts, data, etc, then go-live. Dumps and loads are done using multiple scripts at the same time. Those is the basic tasks and some things can be done simultaneously.

Perhaps not quite as easy (IMO) as going to a new server where we can do as may tests as needed for both validation and speed. Having only 1 copy of the DLC is easier also.

Also thanks Rob for the list of to-do's. While we've done this a number of times over the years, it's always good to make sure we aren't missing something.

As to the question, it appears answered as the binary is able to be loaded which means we can re-work our existing process, including upgrades on the same server.

Tom --- the only thing I found in kbase was v8 to v9 being a no go.... which means that the kbase documentation hasn't been updated since then. :)


Rob Fitzpatrick Sponsor
I was probably unclear. By binaries I meant the files created via the binary dump.
That clarifies things. I took "binaries" to mean the OpenEdge executables, i.e. program code, like _dbutil, _mprosrv, etc. Binary dump files are indeed intended to be upward compatible as Tom said.

I agree with Tom that when doing a server migration, a good plan will not modify the source DB after it is shut down for the last time, so the fallback plan is absolutely straightforward and quick: restart the old DB and application.

You then also don't have to worry about whether the new DLC will work on the old OS. If the gap between old and new OSes is large enough, it may not. I think you would be better off segregating old and new, given that you are doing a server migration anyway. In this situation I wouldn't try to adapt a one-server solution to a server migration by putting the new DLC on the old box and then having to relocate the new DB to the new box, presumably by probkup/prorest.


Active Member
We had no intention of putting the old DLC on the new box. The only time we have to mess with that is for very small clients that aren't going to go to a new server. And yes, that can get ugly with two versions of Progress on the same box (but we deal with it when required).


I am adding to this post rather than create a new one because I will be facing a similar situation. I have a few hundred remote sites, all with "smallish" DBs (say 7 GB up to 20 GB) - all fairly fast and with quite a lot of disc space. We have a fully automated system that about once a year performs a dump/reload on each site - always dumping from one DB and loading into a freshly built DB. The idea is to not delete the existing DB so that in a worst case we can fall-back to it.

In a few months I need to upgrade Progress from 10.2B to 11.7+ and my intention was to install 11.7+ at each site beforehand. Then I was going to make a change to the D/L process so that after all the dumping and extracting of statistics I was going to add a step to switch DLC to the new version of Progress - then continue with the build, load and index, etc.

I notice a cautionary note in the above posts regarding having more than one version of Progress loaded - and that worried me a little. Is there really any problem with this? I can't see any.



Older releases of Progess on Windows can get confused by multiple installs. Unix variations are not bothered by that.

Cringer Moderator
Staff member
So long as you always install the latest Progress version last, and keep each install in completely segregated folders (DLC and Work), then you'll be fine from 10.2B onwards. I've not had any problems and I have 9 Progress versions (32 and 64bit variants included) on my machine.

Rob Fitzpatrick Sponsor
As Tom said, on Unix systems, DLC installations have always been separate from each other. No problems there. (Though uninstalling an old version is a manual process, if straightforward.)

On Windows, we're more or less there now for most use cases but it's been... an evolution. The ability to have more than one version installed has been with us for a while, though with caveats and with a bit of manual work.

Once there were both 32-bit and 64-bit variants of OE for Windows, you initially couldn't have two different installations of the same version where one was 32-bit and the other was 64-bit. That limitation was removed in 11.5. Prior to that the two shared registry keys so one would blow away settings for the other.

You still can't have two different installations of the same version and same architecture (both 32-bit or both 64-bit) on one machine, though you likely wouldn't want to, outside of maybe a build machine (e.g. to be able to build deployment artifacts with different service packs of the same OE release).

The other thing that has been an issue in the past, if you use OEE/OEM, is the -port/-adminport settings. At various times they used the same -adminport numbers across different versions, so there could be conflicts when installing multiple versions and OEE wouldn't launch in the new version until you manually reconfigured it. The default -port is always 20931. There are multiple KB articles on the subject so you should look at those.

How to allow multiple versions of Progress to co-exist on Windows
What are the default ports used by the AdminServer?
How To Configure Multiple Versions of AdminServer To Be Run Concurrently since OpenEdge 10.1B
How to configure multiple AdminServer versions to be run concurrently on Windows


Active Member
As an FYI , we upgraded all of our customers (Linux) but 1 to 11.7.5 (64 bit) and 11.6 (last version of 32 bit for Linux and customers weren't getting a new server) without issue over 3 weeks. The last one (our largest who is moving to a new server) is scheduled for 4th quarter.

Some had new servers, some were on the same server, but it was actually pretty simple (we created scripts to do all the work). Rob's and Tom's posts were helpful, although admittedly we had similar situations when going from 9.x to 10.2 so we knew how to have multiples OE installs on those that did not upgrade servers.

The reason we did not go to 12.x is due to migrating Classic Appservers to PASOE, which we haven't yet tackled. That will be some time next year.