|
Whenever an event occurs, the MobiLink server executes the associated script if you have created one. If no script exists, the next event in the sequence occurs.
NoteWhen you use the Create Synchronization Model wizard to create your MobiLink application, all the required MobiLink scripts are created for you. However, in some cases you may need to edit them. |
Following are the typical upload scripts for tables:
|
Event |
Example script contents |
|---|---|
|
upload_insert |
INSERT INTO
emp (emp_id,emp_name)
VALUES {ml r.emp_id}, {ml r.emp_name}
|
|
upload_delete |
DELETE FROM emp
WHERE emp_id = {ml r.emp_id}
|
|
upload_update |
UPDATE emp
SET emp_name = {ml r.emp_name}
WHERE emp_id = {ml r.emp_id}
|
The first event, upload_insert, triggers the running of the upload_insert script, which inserts the emp_id and emp_name into the emp table. In like fashion, the upload_delete and upload_update scripts will perform similar functions for delete and update actions on the same emp table.
The download script uses a cursor. Following is an example of a download_cursor script:
SELECT order_id, cust_id
FROM ULOrder
WHERE last_modified >= {ml s.last_table_download}
AND emp_name = {ml r.emp_id}
There should be no implicit or explicit commit or rollback in your SQL synchronization scripts or the procedures or triggers that are called from your SQL synchronization scripts. COMMIT or ROLLBACK statements within SQL scripts alter the transactional nature of the synchronization steps. If you use them, MobiLink cannot guarantee the integrity of your data in the event of a failure. |
You can write scripts using the native SQL dialect of your consolidated database, or using Java or .NET synchronization logic. Java and .NET synchronization logic allow you to write code, invoked by the MobiLink server, to connect to a database, manipulate variables, directly manipulate uploaded row operations, or add row operations to the download. There is a MobiLink server API for Java and a MobiLink server API for .NET that provide classes and methods to suit the needs of synchronization.
For more information about programming synchronization logic, see Options for writing synchronization logic.
For information about RDBMS-dependent scripting, such as scripting for Oracle, Microsoft SQL Server, IBM DB2 UDB, or Adaptive Server Enterprise databases, see MobiLink Consolidated Databases.
SQL scripts are stored in MobiLink system tables in the consolidated database. For scripts written with the MobiLink server APIs, you store the fully qualified method name as the script. You can add scripts to a consolidated database in several ways:
When you use the Create Synchronization Model wizard, scripts are stored in the MobiLink system tables when you deploy your project.
You can manually add scripts to the system tables by using stored procedures that are installed when you set up a consolidated database.
You can manually add scripts to the system tables using Sybase Central.