You can write your synchronization logic in the version of the SQL language used by your database. You can also write more portable and powerful scripts using Java or .NET. Both Java and .NET offer flexibility beyond what each RDBMS provides via SQL, while also providing full SQL compatibility. When you use Java or .NET synchronization logic, you can hold session-wide variables, create user-defined procedures, integrate authentication to external servers, and so on.

For information about Java synchronization logic, see Writing Java synchronization logic.

For information about .NET synchronization logic, see Writing synchronization scripts in .NET.

Some databases, such as Microsoft SQL Server, require that procedure calls with parameters be written using the ODBC syntax.

{ CALL procedure_name( {ml param1}, {ml param2}, ... ) }

You can return values by defining the parameters as OUT or INOUT in the procedure definition.

In many other RDBMSs, CHAR data types are fixed length and blank-padded to the full length of the string. In SQL Anywhere or UltraLite remote MobiLink databases, CHAR is the same as VARCHAR: values are not blank-padded to a fixed width. If you are not using SQL Anywhere as your consolidated database, It is strongly recommended that you use VARCHAR in the consolidated database rather than CHAR. If you must use CHAR, the mlsrv12 -b command line option can be used to remove trailing blanks from strings during synchronization. This option is important for string comparisons used to detect conflicts.

See -b mlsrv12 option.

For information about the conversion of data that must take place when a MobiLink server communicates with a consolidated database that isn't SQL Anywhere, see MobiLink data mappings between remote and consolidated databases.