Subscribe to DataMgr |
Visit this group |
DataMgr provides the ability to migrate a field from an old field name to a new field.
This can be useful if your naming conventions for a field have changed or if you want to move from a many-to-one relationship to a many-to-many relationship.
In order to migrate from a field, just have DataMgr create the new field and include an attribute (or argument) named "OldField" with a value equal to the name of the field from which you want to migrate.
DataMgr will copy the data from the old field to the new one. This will work so long as the old field exists either in the database itself or as a relation field in DataMgr.
As referenced earlier, this can work in moving from a many-to-one relationship to a many-to-many relationship.
So, if you had relationship where every employee is in one region and then you are told that employees can actually be in multiple regions, then you would need to migrate this field.
You could take this code:
<tables>
<table name="regions">
<field ColumnName="RegionID" CF_Datatype="CF_SQL_INTEGER" PrimaryKey="true" Increment="true" />
<field ColumnName="RegionName" CF_Datatype="CF_SQL_VARCHAR" Length="120" />
</table>
<table name="employees">
<field ColumnName="EmployeeID" CF_Datatype="CF_SQL_INTEGER" PrimaryKey="true" Increment="true" />
<field ColumnName="RegionID" CF_Datatype="CF_SQL_INTEGER" ftable="regions" />
</table>
</tables>
and change it to this:
<tables>
<table name="regions">
<field ColumnName="RegionID" CF_Datatype="CF_SQL_INTEGER" PrimaryKey="true" Increment="true" />
<field ColumnName="RegionName" CF_Datatype="CF_SQL_VARCHAR" Length="120" />
</table>
<table name="employees">
<field ColumnName="EmployeeID" CF_Datatype="CF_SQL_INTEGER" PrimaryKey="true" Increment="true" />
<field ColumnName="RegionID" CF_Datatype="CF_SQL_INTEGER" />
<field ColumnName="Regions" OldField="RegionID">
<relation
type="list"
table="regions"
join-table="employees2regions"
field="RegionID"
/>
</field
</table>
</tables>
When DataMgr first creates the "Regions" relation field, it will populate it with the current values from the "RegionID" table, creating records in the "employees2regions" appropriately to bring about that result.
Note that the use of "ftable" is not required. It just made the example a bit shorter.