All ideas are welcome. Just because the Idea doesn't make it into the product immediately does not make it a bad idea.
I can create a filter / where clause for a table in snapshot management that is then included in the replicate job. I can specifiy a specific replication job.
Since I "need" groups to stop replicate hanging (too many open jobs apparently - but that's not the idea), why can I not add my replication job to a group at point of creation?
If I have 200 tables frrom a legacy source & add another table, I have to add it in the datasource, get it processed in snapshot management, then disable the replication job so i can drag it into the group. Then re-enable it.
That's not an efficient process. If I can specifiy a gropu at point of snapshot creation, it's a 1x thing & done.
Guest
Migrate allows you to specify an "Import Group" to a table. So ADRC, ADR6, ADR3, etc are all assigned to the "Address" import group. But that isn't (yet) being sent over to Replicate to add those tables to the Address group automatically. But we fully intend to keep enhancing this interface to make that easier. Focus in 2023 Q3 is to finish building out the Cloud Replication screens in the SKT. With that we start to improve some of the user flows specific to "Snapshot" replications that exist in the management Center. Because that management center manages Snapshots, Mirroring, and Synchronization replications the Enable/Disable logic is applied to everything - not just the Mirror / Synch replications. I think we will address that in the new Cloud UI vs continuing to update the Windows Screens.
Attachments Open full size