MobiLink Synchronization User's Guide
Writing Synchronization Scripts
DBMS-dependent scripts
Following are a number of issues that you may encounter when using a consolidated database that is not Adaptive Server Anywhere.
Oracle does not provide session-wide variables. You can store session-wide information in variables within Oracle packages. Oracle packages allow variables to be created, modified and destroyed and these variables may last as long as the Oracle package is current.
Oracle does not have autoincrementing primary key values. You can use an Oracle sequence to maintain primary key uniqueness. The CustDB sample database provides coding examples, which can be found in Samples\MobiLink\CustDB\custora.sql.
For an example of using an Oracle sequence, see Tutorial: Using MobiLink with an Oracle 8i Consolidated Database.
IBM DB2 does not have the ability to make session-wide variables. It also does not support packages which would allow you to run user-defined procedures. A convenient solution is to use a base table with an extra varchar column for the MobiLink user name. This column effectively partitions the rows of the base table between concurrent synchronizations.
IBM DB2 does not have the ability to make user-defined procedures. However, you can use Java or .NET to manipulate SQL statements and substitute new values.
For an example of Java as a procedural language for DB2, see the CustDB scripts in the files Samples\MobiLink\CustDB\custdbq.sql and Samples\MobiLink\CustDB\custdbq.java.
For more information about Java and .NET, see
To download BLOB data from an Adaptive Server Enterprise consolidated database, you need to set an ODBC driver connection option to allow column sizes greater than 4096 bytes. To do this, use the ODBC driver connection option called StaticCursorLongColBuffLen. For example,
dbmlsrv9 -c "...;StaticCursorLongColBuffLen=number"
where number is in bytes, and is larger than the largest expected BLOB.
Note that using this option consumes significantly more disk space on the computer that runs the MobiLink synchronization server.
Some database-management systems provide no convenient mechanism to store the identity of the current user.
For more information, see Storing the user name.
Some databases, such as Microsoft SQL Server, require that procedure calls with parameters be written using the ODBC syntax.
{ CALL procedure_name( ?, ?, ... ) }On these systems, an error-handler that uses a RETURN value can also be in the following form. For example, you can return values in OUTPUT parameters in IBM DB2.
{ ? = CALL procedure_name( ?, ?, ... ) }Adaptive Server Enterprise also requires the latter format when returning a value from a procedure.
The MobiLink synchronization server requires that primary key values of type numeric or decimal be explicitly converted to their types under Adaptive Server Enterprise.
You must add an explicit conversion to the numeric parameters in the script as displayed in the following examples.
SELECT ... WHERE numeric_col = CONVERT( NUMERIC, ? ) ...
The above statement explicitly converts the first parameter to type NUMERIC.
SELECT ... WHERE decimal_col = CONVERT( DECIMAL(10,8), ? ) ...
The above statement explicitly converts the first parameter to type DECIMAL (10,8).
In Adaptive Server Anywhere databases (including UltraLite), CHAR is the same as VARCHAR: values are not blank-padded to a fixed width. In many other DBMSs, CHAR data types are blank-padded to the full length of the string. The dbmlsrv9 command line option -b can be used to remove trailing blanks from strings during synchronization.
For more information, see -b option.
For information about the conversion of data that must take place when a MobiLink synchronization server communicates with a consolidated database that was not made with Adaptive Server Anywhere, see DataType Conversions.