Hi All,
I'm not so sure where to put this, but I think this is the most appropriate forum.
These are the hardware I'm currently using:
Computer 1
> Windows 2000
> 2.8 GHz CPU
> 1.0 GHz RAM
> 80 Gig Hard Drive
Computer 2
> Windows XP
> 2.5 GHz CPU
> 1.0 GHz RAM
> 80 Gig Hard Drive
Both have MS SQL 2005 installed
Both have Progress OpenEdge 10.0B SP03 installed
I've been testing the exact same process on both machines.
I've been trying to migrate the Progress database to the SQL database via the Data Administrator provided by Progress.
After the migration, most data and definitions went across, except for 1 table. I thought it was a bit strange since we (my compnay) has 450 tables, why just 1 failed?
It did brought the table across to the SQL side, but for some reason when it tried to create the Progress schema holder, it failed, therefore the data for that particular table did not get brought to SQL but just the table and its definitions. (Progress schema holder's definitions do not have the failed table)
Anyways, I tried to isolate the problem so I created 1 progress database and loaded that 1 table. (Table name is called fix-ints)
I performed the same processes and it failed again with that one table. I'm not sure to why, so I decided to delete all the fields in that single table and left the primary key (asset) and performed the whole migration process.
The result was the same; it failed to add the table into the progress schema holder.
So my last hopes was to rename that table by adding 'a' as the first letter (from fix-ints to afix-ints), and it worked happily.
So my end results was that the table fix-ints was not an appropriate table for Progress... but why did it let me create it in the original table...
Anyways, I thought, because I can rename it back, I'll rename it for the migration and rename it back after the migration. So I started the full migration process again.
Guess what, another table failed, a table called fix-deposits.
After numerous tries, it seems that any table that starts with 'fi' will fail and if you have more that one 'fi'<XXX> tables the latter one will fail.
Very wired indeed.
I thought someone here might have come across the same issue and have a fix for this or know why this problem is occurring?
NB: Renaming the tables starting with 'fi' before migration and then renaming them back is not an ideal way to perform the migration.
Thanks in advance.
cluc
I'm not so sure where to put this, but I think this is the most appropriate forum.
These are the hardware I'm currently using:
Computer 1
> Windows 2000
> 2.8 GHz CPU
> 1.0 GHz RAM
> 80 Gig Hard Drive
Computer 2
> Windows XP
> 2.5 GHz CPU
> 1.0 GHz RAM
> 80 Gig Hard Drive
Both have MS SQL 2005 installed
Both have Progress OpenEdge 10.0B SP03 installed
I've been testing the exact same process on both machines.
I've been trying to migrate the Progress database to the SQL database via the Data Administrator provided by Progress.
After the migration, most data and definitions went across, except for 1 table. I thought it was a bit strange since we (my compnay) has 450 tables, why just 1 failed?
It did brought the table across to the SQL side, but for some reason when it tried to create the Progress schema holder, it failed, therefore the data for that particular table did not get brought to SQL but just the table and its definitions. (Progress schema holder's definitions do not have the failed table)
Anyways, I tried to isolate the problem so I created 1 progress database and loaded that 1 table. (Table name is called fix-ints)
I performed the same processes and it failed again with that one table. I'm not sure to why, so I decided to delete all the fields in that single table and left the primary key (asset) and performed the whole migration process.
The result was the same; it failed to add the table into the progress schema holder.
So my last hopes was to rename that table by adding 'a' as the first letter (from fix-ints to afix-ints), and it worked happily.
So my end results was that the table fix-ints was not an appropriate table for Progress... but why did it let me create it in the original table...
Anyways, I thought, because I can rename it back, I'll rename it for the migration and rename it back after the migration. So I started the full migration process again.
Guess what, another table failed, a table called fix-deposits.
After numerous tries, it seems that any table that starts with 'fi' will fail and if you have more that one 'fi'<XXX> tables the latter one will fail.
Very wired indeed.
I thought someone here might have come across the same issue and have a fix for this or know why this problem is occurring?
NB: Renaming the tables starting with 'fi' before migration and then renaming them back is not an ideal way to perform the migration.
Thanks in advance.
cluc