Limitations

Documentation

1. Tables without Primary Keys (PKs) are seeded but not tracked for changes. A basic identity LongInt ID field PK satisfies the requirement . For more details see Prerequisites.
If adding a PK is not an option, then the tables without PKs can be added to a scheduled reseeding job. For more details, see the Getting Started section.

2. Tables of type FileTable are seeded but not tracked for changes. For information regarding how to manually seed File Tables click here.

3. Windows/Active Directory logins (user accounts) are not replicated.

4. MSSQL Server level logins/users (along with roles) are replicated, however for security reasons random passwords are assigned. Passwords need to be manually reset on the replica SQL Server after the initial database replication seeding completes. Password changes are also not automatically replicated as part of the schema replication process.

Justification: CloudBasic RDS AlwaysOn/Geo-Replicate (Multi-AZ/Multi-AR) is designed to be lightweight and to handle MSSQL Server continuous replication over TCP/IP and to work in cross-region (over VPN or data encrypted in transit SSL connections), cross-aws-accounts (data/DR artifacts are stored in multiple AWS accounts, account level security breach would not affect business continuity), on-premise to AWS RDS or EC2 MSSQL Server, and even InterCloud replication scenarios.   

5. Dropped or renamed table columns are not automatically replicated as part of the continuous schema replication process. In case of dropped or renamed column(s) the following error will be reported in runtime logs for each change tracking process run:

>>ERROR:Ambiguous schema change detected.
A column(s) been renamed or dropped in table(s):
[dbo].[Managers].CompanyName2, [dbo].[Managers].CompanyName3 ?
To resume change tracking, apply proper schema change(s):
(1) Click [Guide me...] and follow the instructions 
(note: if you do not see such a button then changes had already been applied) or 
(2) Execute below scripts, properly adjusted to account for actual schema changes, manually:

If column1 was dropped, then you need to execute: alter table tablename drop column column1;
(Applicable to redshift replications only): On the Redshift side, you need to execute 2 statements: 
(1) alter table tablename drop column column1 (2) alter table tablename_stage drop column column1

If column1 was renamed to column2, then you need to execute: 
EXEC sp_rename N'[tablename].[column1]',N'column2', 'OBJECT';
(Applicable to redshift replications only): On the Redshift side, you need to execute 2 statements: 
(1) alter table tablename rename column column1 to column2 
(2) alter table tablename_stage rename column column1 to column2

When you click the [Guide Me] button, you will land on an interactive wizard which will allow you to drop and/or rename columns without the need to manually execute alter queries against the staging data store and, if applicable to the replication type,  against redshift:

DROP COLUMNS:

1.1 Selected columns to be dropped:

RENAME COLUMNS:

2.1 Map columns to be renamed (1 pair at a time - if more than 1 columns are renamed):