Large companies often have many copies of the same application running in different divisions or plants. For example, a company might have 1 instance of Maximo running at each of their manufacturing plants. These all need to be mapped as sources with mostly the same mapping rules.
It's possible that sometimes the mapper will choose the wrong datasource and map it completely. Then they realize they mapped the wrong source and need to change it. This is possible, but not super common.
A more common usage would be as we copy a RELEASE we then need to update the copied mappings from one source (MAXIMO_A) to the new source (MAXIMO_B).
By changing the Datasource we would need to cascade down the change to the Primary Table ID (GUID) to be the same table in the new datasource.
Allow REL_INTERFACE_SOURCE.DATASOURCE_ID to be changed to the new Datasource ID.
The list of new DATASOURCES should be limited to only datasources with the same APPLICATION_ID and which contain the same table name referenced by the PRIMARY_TABLE_ID. ie. if we are mapping MAXIMO1.ITEMS then show any other Maximo datasources that also have an ITEMS table...
Upon changing the datasource, update the PRIMARY_TABLE_ID to the new table id from from the new datasourceid.
Update COR_DATA_MAP for all child records (based on INTERFACE_SOURCE_ID) to have the new DATASOURCE_ID, but only if the datasource_id is the same as the OLD datasource ID. Note that some mappings might be from a Different Datasource_ID so we can't just update all the mappings.
Update REL_MAP_LINAGE.DATASOURCE_ID using the same logic as for the mapping screen. Don't trigger an additional info message as these
If there are OTHER datasources referenced by COR_DATA_MAP.DATASOUCE_ID or REL_MAP_LINEAGE.DATASOURCE_ID - pop up an informational message to alert the user to verify all existing mappings as some secondary datasources have been used in mappings.
Set the MAP_STATUS to 'In-Progress' and BUILD_STATUS to 'New'