Hello,
When we import a task with a new table and new fields from a workspace to another, the position number may be different for the included fields. Why does this happen and is there any way to prevent it? If you load an environment with a database backup where the positions are not the same as those in the database used for compilation then we get a CRC error. In both our test environment and development environment, we have several databases that we connect to. Each database may contain a certain scenario that we want to test and develop against. That is why we have different databases that use the same source code. We have a database that only contains database and is used for compilation, that database is empty and contains no business data.
We use OpenEdge 11.7.2 and RTB 11.6.1. And we use the "old" Appbuilder.
Regards Micke
Hi.
"Why does this happen.."
This value is generated by the db engine when the field is added to the physical schema. Since the fields may have been originally added in a different order then the order in which the Schema Update routine applies them, the values may end up being different.
"... is there any way to prevent it?"
One way to work-around this would be to write a routine to programmatically generate and apply an incremental DF file to the other target databases (the PSC Kbase has some examples of calling the OE routines) and then call this procedure from the "updateSchema" event hook that fires after the schema has been updated.
Hi.
"Why does this happen.."
This value is generated by the db engine when the field is added to the physical schema. Since the fields may have been originally added in a different order then the order in which the Schema Update routine applies them, the values may end up being different.
"... is there any way to prevent it?"
One way to work-around this would be to write a routine to programmatically generate and apply an incremental DF file to the other target databases (the PSC Kbase has some examples of calling the OE routines) and then call this procedure from the "updateSchema" event hook that fires after the schema has been updated.
Thank you Jeff
/micke