converting unix DB to windows DB

[selasi]

good day all.

i would like to know how i can convert a progress database that was running o unix to windows. this has been caused by change of servers so initially it was running on unix server and now i want to put it on a windows platform, are there any special procedures hat i need to take

and what is the best network emulation software that i can use for the purpose of networking?

regards

selasi

 

[RealHeavyDude]

The only supported way to move a Progress/OpenEdge database between operating systems is via dump & load. Dump & load works ascii as well as binary ( binary dump files are platform independent ). Simply copying the database to another machine with a different OS might seem to work ( for example Progress V9 from Windows to Linux ) as you might be able to start the database. But as the database is internally corrupted for the target OS you will suffer serious problems. Backups are not platform independent too ...

Can't give you any advice on emulators though.

Heavy Regards, RealHeavyDude.

 

[mjpowellesq]

Thats the joy of using Progress / OpenEdge - platform independant
No problems at all, it is a simple process.
The process is called dump & reload.
Simply dump data & definitions from 1 format, and reload on the other.
good look. BFN

 

[vikaetta]

The Dump/Load provided by progress works, but what happens when the dump/load facility does not work due to the usage of pointers on a no. of tables. As such, dump/load procedures need to be written to cater for these tables.

Anyone with procedure to do this process.

 

[TomBascom]

Are you saying that the application uses RECIDs as fields in db records?

That is a very bad idea.

The best cure is to fix the code to no linger do that.

Otherwise you need to write a program which will re-create the RECIDs using some other key. There is no generic way to do that -- it is specific to the application in question.

 

[vikaetta]

yes they do have RECIDs, its on some old application and we need to move database from UNIX to Windows.

Have been advised earlier that dump/load procedures need to be written to cater for these tables ( those with RECID's)

but have no clue how the procedure woule be like for dump/load as am used to the default Progress gives.

 

[RealHeavyDude]

The RECID is the physical position of the record - it contains the physical address of the database block in which the record is stored and the position within that database block. There is no way a program could control the RECID a record that is newly created will get in the database. That means that, when loaded into another database, each record will get a new - different - RECID rendering the dumped RECIDs useless.

In order to have the correct RECID stored you need to identify the new RECID of the record to which the RECID pointed in the old database. You could do something like this:

Scenario: The RECIDs stored in one database field of one table A point to a record in database table B, table B has a unique key.

• You need to create an export of table B that contains the pair of the unique key and the RECID for each record.
• After the load you need to find the RECID that is stored in table A in the manually created file, get the unique key, and, with that unique key find the record in table B in the new database - there you have the correct RECID. All you have to do is to store that RECID in table A.

Heavy Regards, RealHeavyDude.

 

[vinod_home]

Or in the current database, add a tmp_recid field to all tables and store the recid within it. Once you dump/load, use that field to fix all the links and remove the field.

HTH

 

[vikaetta]

Seems possible but easier for a small database.

anyone who can assist with code i can use to run for all tables at once? teh database has got more than 200 tables.

would appreciate the help

 

[TomBascom]

You cannot generically code the suggestion above.

At the very least it requires a new field to be added to every table that might be impacted.

To determine what tables and fields you need to worry about run this:

for each _field no-lock where _field._data-type = "recid":
  find _file no-lock of _field.
  if _file._hidden then next.  /* skip schema tables... */
  display _file-name _field-name.
end.

For every field that the report identifies you will need to figure out how you plan to reconstruct the recid relationship.

If you are lucky there aren't very many and there will be obvious alternative keys.

An example of an obvious alternative key would be if the ORDER table has both a CUST-RECID and a CUST-NUM field. In a case like that you would:

1) perform the dump & load normally

2) repair the recids with something like this:

for each order exclusive-lock:
  find customer no-lock where customer.cust-num = order.cust-num no-error.
  if available( customer ) then
    order.cust-recid = recid( customer ).
end.

(The code above is light on error handling and is not terribly efficient for large tables... it is just an example.)

More complex scenarios would require more complex solutions.

 

[vinod_home]

Always backup your source database before you start changing anything.

HTH