Before running the setup script, you should be aware of the following requirements:
The database user who runs the setup script is expected to be the same one used to update the MobiLink system tables during synchronization. This user must be used to start the MobiLink server and to configure MobiLink applications. See Required permissions.
The RDBMS user that the MobiLink server uses to connect to the consolidated database must be able to use the MobiLink system tables, procedures, and so on, without any qualifiers (for example, SELECT * from ml_user). See MobiLink server system tables.
The MobiLink server login ID must have a SELECT permission on gv_$transaction and EXECUTE permission on sys.dbms_utility. These permissions can be granted using the Oracle grant permission syntax to the MobiLink server login ID. You must connect as SYS to grant this access. The Oracle syntax for granting this access is:
grant select on SYS.GV$TRANSACTION to user-name; |
grant execute on SYS.DBMS_UTILITY to user-name; |
To set up Oracle to work as a MobiLink consolidated database, you must run a setup procedure that adds MobiLink system tables, stored procedures, triggers, and views that are required for MobiLink synchronization. There are multiple ways you can do this:
Run the syncora.sql setup script, located in install-dir\MobiLink\setup.
In the MobiLink 12 plug-in for Sybase Central, choose Folders from the View menu. Open your MobiLink project and expand Consolidated Databases. Right-click the database name and choose Check MobiLink System Setup. If your database requires setup, you are prompted to continue. Note that if you have set up aliases for an existing MobiLink system setup, you should connect as the user whose schema has the MobiLink system setup.
When you use the Create Synchronization Model Wizard or Deploy Synchronization Model Wizard, the system setup is checked when you connect to your server database. If your database requires setup, you are prompted to continue.
You must set up an ODBC DSN for your Oracle consolidated database. See:
Data type mapping The data types of columns must map correctly between your consolidated and remote database. For details, see Oracle data mapping.
CHAR columns In Oracle, CHAR data types are fixed length and blank-padded to the full length of the string. In MobiLink remote databases (SQL Anywhere or UltraLite), CHAR is the same as VARCHAR: values are not blank-padded to a fixed width. 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.
Timestamps The MobiLink server uses gv$transaction to generate a timestamp for the remote to be used in the next synchronization, so the MobiLink server login ID must have a SELECT permission on gv$transaction.
Stored procedures If you are using stored procedures to return result sets or accept VARRAY parameters, you must select the Procedure returns results or uses VARRAY parameters option for the iAnywhere Solutions 12 - Oracle ODBC driver. Also, Sybase Central requires procedures to return results in order to use central administration of remote databases, so this option needs to be selected when using central administration.
Session-wide variables You can store session-wide information in variables within Oracle packages. Oracle packages allow variables to be created, modified and destroyed; these variables may last as long as the Oracle package is current.
Autoincrement methods To maintain primary key uniqueness, you can use an Oracle sequence to generate a list of keys similar to that of a SQL Anywhere autoincrement field. The CustDB sample database provides coding examples, which can be found in Samples\MobiLink\CustDB\custora.sql. Unlike autoincrement, however, you must explicitly reference the sequence. SQL Anywhere autoincrement inserts a column value automatically if the column is not referenced in an INSERT statement.
Oracle does not support empty strings In Oracle, an empty string is treated as null. In SQL Anywhere and UltraLite, empty strings have a different meaning from null. Therefore, you should avoid using empty strings in your client databases when you have an Oracle consolidated database.
Discuss this page in DocCommentXchange.
|
Copyright © 2010, iAnywhere Solutions, Inc. - SQL Anywhere 12.0.0 |