Issue with Converting Progress 9.1E to OpenEdge 10.2

[Renee Crichlow]

Good morning,

I am still a newbie dealing with Progress so I might have missed some things on the installation/conversion.

I installed OpenEdge 10.2 on a new server. Progress 9.1E sits on another server. I truncated 9.1E on the 9.1E server and copied the truncated file to the OpenEdge 10.2 server.

I tried to run the conversion using

proutil <path to dbname> -C conv910 on the OpenEdge 10.2 server and got the error below

CONVERT MAY NOT RUN FROM DLC PATH.

Please assist.

Regards,
Renee

 

[Cringer]

The best thing to do AFAIK is to start proenv from the Start menu, that gets all your system variables set. Then navigate in there to the path of the db and "proutil dbname -C conv910". That should do it. In the proenv screen if you type prompt you will see where you're currently located.

 

[Renee Crichlow]

Hi Cringer,

I was able to get pass the initial error by running the command from proenv. However I encountered another error:

"Unable to open or create <dbname>.d1 error 2. Conversion failed in drReadMasterblk9, ret= -1"

 

[Cringer]

I'm afraid I'll have to let you wait on this for someone more experienced of this kind of thing. I'm sure someone will be along shortly.

 

[TomBascom]

Are these servers both running the same operating system? Or are you trying to change platforms?

How did you go about copying the database from one system to the other? Did you maybe use FTP and forgot to specify "binary" mode?

 

[Renee Crichlow]

Hi TomBascom

9.1E Progress runs on Windows Server 2003 SP1 and OpenEdge 10 runs on Windows Server 2003 x64 SP2.

The database is used with an application called LOANS. So I just truncated the bi file and then copied them to a folder created on the OpenEdge server (in LOANS application).

The documentation that I read just specified the steps for migrating i.e truncate bi file then convert.

Are there any steps that I missed out?

 

[LarryD]

Did you restore the various extents to the same directory structure as was on your old server? As a guess, you may have an issue with the .d1 (and perhaps other .d# and .b# bi extents) that are not in the same directories as before?

If not, you need to edit the database .st file to point to the new directories for the various extents and run a prostrct repair.

From the kbase:

The structure description file (.st) is the text-file representation of the database structure that is saved in the .db file.
The .db file, or database control area, acts as a table of contents for the database engine, listing the name and location of every area and extent in the database.
The database structure is written into the .db file for the database, and when a database is moved using operating system utilities, the .db file must be updated accordingly.
The .db file is updated running prostrct repair. It uses an .st file to update the location of the extent file.
Prostrct repair should be used when a database is moved to a new file system or location, so that the directory structure is changed, e.g. when a database is copied from drive c:\Progress to drive d:\Progress using os utilities.


Steps to follow:
1. Run prostrct list dbname to obtain an up- to-date structure file (.st).
Example:
prostrct list mydb temp.st

2. Edit the structure file to reflect the new paths to the database files.
In the above example, edit the temp.st file.

3. Change all references in the .st file to reflect the new locations where the files will be moved to.

4. Use operating system tools to move the files.
5. Run prostrct repair dbname using the edited .st file to change the structure file to show the new paths.
Example:
prostrct repair mydb modified-temp.st

6. Run prostrct list again to verify the paths to the database files are correct.
Example:
prostrct list mydb new-temp.st

 

[TomBascom]

The simplest conversions assume that you have the old Progress and the new Progress both installed on the same server. Lots of subtle little things go wrong when two servers and two versions of Progress get involved.

It may, for instance, be that you are running into an issue like what Larry describes.

Since you have a shared drive available, let us call it X:, here is what I would do:

1) On the old server: procopy dbName X:\dbName
2) Just to be really sure -- truncate the bi file on X:

3) Switch to the new server, cd to X: and run proutil dbName -conv910
4) procopy dbName c:\dbPath\dbName

 

[Renee Crichlow]

Hi LarryD,

Where am I supposed to run the prostrct repair? On 9.1 progress server or OpenEdge server?

 

[LarryD]

If you follow Tom's suggestion, you won't have to.

 

[Renee Crichlow]

Thanks Larry.

Would the shared drive be created on the old server or the new server? I am just trying to make sure I have everything correct.


Regards,
Renee

 

[TomBascom]

If it were me I would share drives from the new server. That way I would (probably) be sharing faster drives and when I turn off the old server nothing will unexpectedly go away.

 

[Renee Crichlow]

Hi Tom,

Based on your instructions, if I share drives on the new server(OpenEdge), is there a utility to truncate version 9?

1) On the old server: procopy dbName X:\dbName
2) Just to be really sure -- truncate the bi file on X:

3) Switch to the new server, cd to X: and run proutil dbName -conv910
4) procopy dbName c:\dbPath\dbName

 

[TomBascom]

There is. It is in %DLC%\bin\91dbutils

However getting that environment to work properly is undocumented and a royal PITA. I've spent days figuring it out. Use it only as a last resort and out of desperation.

In your case there is no need -- do the truncate from the old server in step#2.

 

[Renee Crichlow]

I was advised to uninstall OpenEdge, install version 9 then re-install OpenEdge (on the new server). Would this be a better approach?

 

[TomBascom]

That seems like a ridiculous amount of work for no perceptible benefit.

 

[Renee Crichlow]

Hi Tom,

I am a bit confused by your steps. How is procopy different from just copying the database files over to the new server?

When creating the share, should I create the share to the folder that contains the db files?

 

[Renee Crichlow]

Let me see if I get it right.

truncate the bi file on the old server
create a share on the new server (this doesn't have any files in it) -
run procopy from the old server to the new server share location (at this point I get an error stating <dbname>.lk cannot be found)



Am I suppose to have a copy of the dbase files on the share location as well? This seems to defeat the purpose of using procopy. I may be wrong.

Please clarify.

 

[TomBascom]

Procopy is different because it knows where all the pieces of the db reside, makes sure that a complete and consistent copy is made and then takes care of any pathing issues so that the newly copied database doesn't think that it belongs on some other path.

OS level copies may miss parts of the database (extents can be stored in many folders and it isn't always obvious where they are) and os copies may screw up the timestamps on extents. An OS copy will also result in a database that is usually in the wrong path. All of this can be fixed by using various prostrct options but it is much better to not have to go through that.

Let us assume that your share is X: and that is is mounted on both the old and new servers as X: Your database is called dbName and on the old server it is in C:\db. You would like an OE10 database in C:\db

On the old server:

1) cd /d C:\db
2) proutil dbName -C truncate bi
3) procopy dbName X:\dbName
4) cd /d X:
5) proutil dbName -C truncate bi # this probably isn't necessary -- but do it just for kicks

On the new server:

6) cd /d X:
7) proutil dbName -C conv910
8) procopy dbName c:\db\dbName

You may now eliminate the X: share and its contents. Or keep it around for future use if you are going to do more of this kind of thing.

 

[Renee Crichlow]

Hi Tom,

Finally it's working. I followed your instructions and everything seems to be going well. I am running the final step.

Thank you very much for your advice and patience.

Regards,
Renee