Scripted upload applies only to MobiLink applications that use SQL Anywhere remote databases.
When you implement scripted upload, dbmlsync does not use the transaction log to determine what to upload. As a result, if your scripts do not capture all changes, data on remote databases can be lost. For these reasons, log-based synchronization is the recommended synchronization method for most applications.
In most MobiLink applications, the upload is determined by the database transaction log so that changes made to the remote database since the last upload are synchronized. This is the appropriate design for most applications and ensures that data on the remote is not lost.
However, in some rare cases you may want to ignore the transaction log and define the upload yourself. Using scripted upload you can define exactly what data you want to upload. When doing scripted upload you do not have to maintain a transaction log for your remote database. Transaction logs take up space that may be at a premium on small devices. However, transaction logs are very important for database backup and recovery, and improve database performance.
To implement scripted upload, you create a special kind of publication that specifies the names of stored procedures that you create. The stored procedures define an upload by returning result sets that contain the rows to insert, update, or delete on the consolidated database.
Note: Do not confuse scripted upload with upload scripts. Upload scripts are MobiLink event scripts on the consolidated database that you write to tell the MobiLink server what to do with the upload. When you use scripted upload, you still need to write upload scripts to apply uploads to the consolidated database and download scripts to determine what to download.
The following are some scenarios where scripted upload may be useful:
Your remote database is running on a device with limited storage and there is not enough space for a transaction log.
You want to upload all the data from all your remote databases to create a new consolidated database.
You want to write custom logic to determine which changes are uploaded to the consolidated database.
Before implementing scripted upload, be sure to read this entire chapter. In particular, take note of the following points:
If you do not set up your scripted upload correctly, you can lose data.
When you implement scripted upload, you need to maintain or reference things that dbmlsync normally handles for you. These include pre- and post-images of data, and the progress of the synchronization.
You need to lock tables on the remote database while synchronizing via scripted upload. With log-based synchronization, locking is not required.
Transactional uploads are extremely difficult to implement with scripted upload.
| Discuss this page in DocCommentXchange. Send feedback about this page using email. |
Copyright © 2009, iAnywhere Solutions, Inc. - SQL Anywhere 11.0.1 |