There is a critical bug in SkyVia Replication with respect to removing columns from a replicated Salesforce object.
First off, you should not be automatically adding new object columns to a replication package. If you want to expose them on the UI pending the user's selection of such for including the column in the object replication, this would be acceptable. Automatically adding new columns is a breaking change because the target table does not have the column defined. This needs to be addressed.
Secondly, any attempt on our part to remove the column from the replication causes us to have to re-sync the package. This should not be the case. This needs to be addressed
Additionally, if we remove a column that is being replicated from an object this causes a failure in the package. And we cannot go in and remove the column from the package because to do so would cause us to have to re-sync the package. This is not acceptable.
To reiterate, you should not be automatically adding new object columns to replication.
You should allow columns to be removed from a package without requiring a re-sync. Think about it. You don't need to re-create the table. DML Updates don't require the column to be present. DML Inserts only require the column to present unless there is a constraint requiring such.
Our confidence is greatly diminished. To be candid, we continue to use SkyVia at this time due to budgetary constraints. This may not continue to be the case in the future when budgets are under review if serious effort is not put into addressing the problems we have identified and you become much more transparent and forthcoming in discussing the issues presented at a technical level. I would like to hear from Simon on each of the issues presented and would like to know what will and won't be addressed, along with a projected timeline for each that will be addresed. Frankly, these errors are indicative of grossly inadequate testing, and more.