Yes. Content Version can also be backed up and restore, within reasonable limitations of your hardware to store the entire record in memory.

Yes. Your database must be defined with a UTF-8 compliant character set for this to work properly.

Yes. The only limitations are

  • The object must be “Createable” — a term which Salesforce means the Salesforce application allows an API user to create new records. For instance, AccountHistory and OpportunityHistory records are not Createable; they are created internally by Salesforce.
  • The user must have security permission to create records in Salesforce.

Yes, the product automatically adds new objects and fields, and keeps old objects and fields that are removed from Salesforce until you specifically request that they be dropped from the database. The only non-automated process is if you change data types in Salesforce, in which the database was originally a number or a date. In that case, you would get a warning message every time a job runs on that object telling you what field didn’t match. If there was every any actual data that couldn’t be copied, the job would fail and let you know that you have to make a decision to drop and re-add the column with the correct data type, using the following command:

RJ4Salesforce -config [config name] -dropColumnForce [object name] [field name]

This is not automated because you might want to preserve or even recover the old data, since Salesforce drops and re-adds the field, leading to possible loss of data.

If you turn on History Tracking, prior versions of each record are retained in a secondary table. You can purge the history with a SQL DELETE or a TRUNCATE statement for the secondary backup tables. There are no versions of the entire dataset, since we’re using a single database schema with secondary backup History Tracking tables to keep prior images of individual records.

All data is retained forever. All versions, if you turn this feature on, are retained unless you physically delete them from the database. The prior versions are in separate tables, so you can manage space more easily.

You can create multiple databases for different purposes, and they will be updated when their own replication cycles happen under your control. But instead of versioning the entire set of data for a single org, you can keep prior versions of individual records in a secondary table for each Salesforce object. This is not Salesforce’s History object, it is our own feature. There is a primary table for each object, and a secondary table that contains each prior snapshot of that record. This approach conserves the amount of database space required to store all versions, and fits better into the incremental replication process.

Yes. This is all done through your own scheduling system or Windows Scheduler, or cron if using UNIX.

Yes. This is the preferred implementation. You can use any job scheduler, including Windows Scheduler, UNIX cron, or a commercial job scheduler.