Do the columns in the Consolidated and Remote DB have to be identical?

"Yes and no" - I will explain.

"No." A remote database can select a subgroup of columns of a table from the consolidated database that are to be synchronized - so it is perfectly acceptable that the consolidated database can potentially have more columns on a table contained within it than the remote contains.

One of the (most often) excluded columns on the remote is the 'last_modified' (generally an 'auto-timestamp') column, since this value is used only for logic on the server-side MobiLink event scripts for timestamp-based synchronization. The remote database automatically keeps track of which records to upload, and thus you don't need to explicitly keep track of this information at your remote database and thus the column is omitted. (Unless you are using Scripted Uploads to perform your uploads, but then you would need to devise your own logic - this is advanced usage, however).

"Yes." Both the schema type and the number of columns per table defined for a synchronization must match to the synchronization scripts on the consolidated.

e.g. If you had a remote table publication with "int, varchar, timestamp, int" as the upload data, then your upload scripts must accept the data as those datatypes and only refer to a maximum of 4 column values. Likewise, your download_cursor event script for that table must only select the data types "int, varchar, timestamp, int" to be sent back to the remote database.

You don't mention it, but it sounds like you used a synchronization model with timestamp-based downloads (using a "last_modified" column in the consolidated table) and logical deletes on the consolidated database (using a column called "deleted").

In that case neither the "last_modified" or "deleted" columns should be in the remote table.

Note that the synchronization model support for logical deletes assumes that rows logically deleted on the consolidated database should really be deleted (not logically deleted) on the remote.

Also, unless you are already using logical deletes on the consolidated it is usually easier to track deletes for synchronization in a shadow table. Otherwise you have to ensure that all connections to the consolidated database do logical deletes and exclude logically deleted rows from any queries. In other words, all existing applications would have to be changed.

They do not need to be the same. They may be identical, or they may be different. You can have columns in the consolidated that aren't in the remote, and you can have columns in the remote that aren't in the consolidated. It all depends on your business and synchronization needs. They don't even have to be the same table name, because the download_cursor and download_delete_cursor events let you define a SQL script that maps consolidated values to remote values however you want. That said, many deployments use the same table names for both the remote and consolidated tables.

I strongly recommend going through the MobiLink tutorials in the documentation. For version 12.0.1 these are at: http://dcx.sybase.com/index.html#1201/en/mlstart/mg-part-tutorials.html