Kbase P142600: Errors 6182, 87 and 76 during the data load of protoXXX migration process
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
13/03/2009 |
|
Status: Unverified
SYMPTOM(s):
Errors 6182, 87 and 76 during the data load of protoXXX migration process
You tried to compare or to update a character field with a value longer than the maximum length. (6182)
** Input value: <input> should be <yes
o>. (87)
** Invalid character in numeric input <character>. (76)
FACT(s) (Environment):
The above errors happens when loading data after successful migration of the Progress database to the SQL Server as well
The Progress Database has many tables with recid field type on the middle or almost beginning of the each table
The DataServer converts the recid data type to the integer data type on the foreign database as well for the progress data type on the schema holder
Windows
OpenEdge 10.1x
DataServer
CAUSE:
During the protoXXX process, the utility dumps the .d of each tables if load data is selected. Progress database skips the data from progress recid fields when used dictionary utility to dump .d file. This causes the misalignment of the rest of the data on the same records for other fields as the recid field is on the middle or almost at the beginning of the table. Thus, different errors are apparent depending on the field that has the order number next to the recid field.
FIX:
There are four workarounds available. Depending on your business requirements, you can implement any one of those workarounds:
1. You can change the order of the RECID column so it is the last field on the table. EXPORT/IMPORT use the field's order so if it is always the last ones, then there is never a gap in between fields and the load will always work. You can do this in your OpenEdge DB before the migration and leave it like that for good. Now that changes the table's CRC so if you have .r compiled, you may have to recompile the .r's that access those tables. You could also change the order just in the schema holder, run the load and then change them back to the order back after the load.
2. Write a .p that either dumps the recid fields so the load works, or write a .p that load the data but skips the recid fields. That's an easy thing to do too, probably more straightforward than changing the order back and forth, if you can't change the order for good.
3. If you do not require the recid column for the MS SQL Server implementation, you can just delete it from both schema holder and from the MS SQL Server so the load will always work.
4. Change the recid field data type to decimal data type on the OpenEdge database before migration.