API Differences

Issue: In version 1.2 (EBF4 and later), you could create or access a Connection (connection profile) instance inside a sync thread without additional coding. In version 1.5.2 you must lock the MyDatabase class before creating or accessing a connection profile inside a sync thread.

Action: To create or access a connection profile from within a sync thread, use code similar to this to lock the MyDatabase class first:

lock(typeof(MyDatabase))
{
  Connection conn = new Connection();
  conn....
  conn.Save();
  ConnectionManager.Instance.DefaultConnection = conn;
  Customer.Synchronize();
  List<Customer> items = Customer.FindAll();
}

Simultaneously accessing multiple packages from multiple threads is not supported.

Issue: In version 1.2 (EBF4 and later) it is possible to access multiple packages from multiple threads at the same time. In version 1.5.2, this is not supported.

Action: Do not attempt to simultaneously access multiple packages from multiple threads. You can access multiple MBOs from different publications within the same package.

Issue: In version 1.2 the MobiLinkStreamType property could have a type of either MobiLinkStreamType or string. In version 1.5.2 this property can only be type string.

Action: Change the MobiLinkStreamType property to a type of Sybase.Persistence.MobiLinkStreamType as follows:.

Sybase.Persistence.Connection conn;
...
conn.MobiLinkStreamType =
Sybase.Persistence.MobiLinkStreamType.Http.ToString();

or

conn.MobiLinkStreamType =
Sybase.Persistence.MobiLinkStreamType.Https.ToString();

setPending() is deprecated.

Issue: In version 1.2, all transactions are non-pending by default and calling synchronize() after save would sync all of them. You could use setPending(true) to make a transaction pending before synchronization and thus prevent it from being submitted. In version 1.5.2, setPending() is deprecated. In version 1.5.2, all transactions are pending by default and synchronize() internally calls submitPendingOperations() to submit all the pending transactions.

Action: Do not use setPending() while working with 1.2-compatible code in version 1.5.2.

Issue: In version 1.2 it was not always necessary to refresh the syncResult object. In version 1.5.2, you must always refresh the syncResult object.

Action: This code sample shows a refresh of the SyncResult object.

SyncResult result = Customer.SyncResult(); 
List<OperationLog> logs = result.GetOperationLog(); 
for each (OperationLog log in logs) 
{ 
log.Delete(); 
} 
result = Customer.SyncResult(); // This step is needed in 1.5.2 to refresh sync result 
Console.WriteLine("log count after delete: " + result.GetOperationLog().Count);

Issue: In version 1.2, if the length set for syncParameter is greater than the maxlength specified for the syncParameter, the synchronization gives an error. In version 1.5.2 the same synchronization succeeds.

Action: You can safely ignore the restriction on syncParamater exceeding its maxlength limit for in version 1.5.2.

Issue: In version 1.2 a back-end synchronization failure returns an error message to the client in SyncResult.ErrorMessage. In version 1.5.2, with the same failure the device client sync gets a SynchronizeException, and then you have to call MyDatabase.GetLogRecords() to get the error message.

Action: The system publication is automatically synchronized if the first sync fail due to a server error. There is no need to do anything different in your code, unless you want the code to return the error message. To capture the error message for a back-end sync failure in version 1.5.2, use SynchronizeException to call MyDatabase.GetLogRecords() to get the error message.

Issue: In version 1.2, these properties provided MBO level information. In version 1.5.2 these provide only publication level information.

Action: Change code as necessary to work with publication level information.

Issue: In version 1.5.2, various get methods of SyncResult return only the default values corresponding to their underlying variable’s data types. The only supported method is SyncResult.GetOperationLog().

Issue: In version 1.5.2, OperationLog has only Status, Message, and OperationName properties. In version 1.2, OperationLog has several more properties.

Action: Change code as necessary to use only the three properties available for OperationLog.

Action: Change code as necessary to use methods from classes that are still available.

Issue: In version 1.2 the Sybase.UnwiredPlatform.Data.DatabaseUtilities.DeleteAllDatabases() method is used to delete all UltraLite databases in the same folder of a client application. In version 1.5.2, DatabaseClass.DeleteDatabase() is the comparable method .

Action: Use DeleteDatabase() in place of DeleteAllDatabases().

Issue: In version 1.2, the data obtained using a new sync parameter value always overwrites the data obtained using the previous value; so a FindAll() returns only the data from the current sync parameter. In version 1.5.2 the datasets are added; so a FindAll() returns the data for all the sync parameters previously used.

Action: To achieve the same result in version 1.5.2 that FindAll() achieved in version 1.2, use query limiting for the sync parameter.

For example, to achieve the same result as in version 1.2, the FindAll() query definition will look like:

select x.* from customer x where x.state=:state

Where state is the sync parameter.

Issue: In version 1.2 the FindById() method is generated in the Other Operation class. In version 1.5.2 the method is not generated.

Action: Use the FindAll() method to search the Other Operations.

Issue: In version 1.2 FindAll(), Find(query), FindBy(?int), FindByPK(pk), and FindWithQuery(query) are generated in each MBO. In version 1.5.2, only Find(long) and Find (long?) are generated.

Action: To generate FindAll(), Find(query), FindBy(?int), and FindByPK(pk), define them in the model. To simulate FindBy() and FindByPk(), define an object query in the MBO definition.

Issue: In version 1.2, if the client deletes a pending record before synchronization, it causes an error. In version 1.5.2 the deletion of a pending record is treated as a cancelPending.

Action: You do not have to be concerned about calling cancelPending to prevent an error when a pending record is deleted before synchronization.

Issue: In version 1.2, you must call SetPending(true) to keep a transaction (operation) pending on the client. In version 1.5.2, however, an operation is always pending until SubmitPending() is called on it; calling SetPending(true) on the transaction causes it to fail.

Action: Ensure that you do not call SetPending(true) on a pending transaction.

Issue: The version 1.2 MBO DeleteData() method is no longer supported in 1.5.2.

Action: Change code as necessary to avoid using DeleteData().

Issue: In version 1.2 the IsPersonalized and IsPrimarykey properties are in metadata for MBO attribute. In version the metadata classes reside in the Sybase.Reflectionpackage (com.sybase.reflection for Java).

Action: Change code as necessary to ensure that IsPersonalized and IsPrimarykey properties are accessible.

Issue: In version 1.2, to get or set a personalization key, you must synchronize the system package. In version 1.5.2, you must synchronize the system publication in each package.

Action: Change code as necessary to continue getting or setting personalization keys.

Issue: The SetOverridePersonalization() and UndoOverridePersonalization() methods, which can be called in version 1.2 for both sync and operation parameters, are not available in version 1.5.2.

Action: Change code as necessary to avoid using SetOverridePersonalization() and UndoOverridePersonalization().

Issue: In version 1.5.2 isInserted() internally calls isCreated().

Action: Change code as necessary to accommodate this change.

Issue: In version 1.2 the Structure Parameter array is specified as an Array(A[]). In version 1.5.2 it is represented as a List(AList)

Action: Change code as necessary to accommodate this change.

Issue: In version 1.2, if maxlength for a binary type is set greater than 2048 bytes, the binary is treated as a BLOB. In version 1.5.2, if maxlength for a binary is set greater than 32767 bytes or is not specified, the binary is treated as a BLOB, with a maximum length of -1.

Action: Change code as necessary to accommodate this change.

For more detailed information on changes from version 1.2 behavior for maxlength, see the "Version 1.2 behavior with maxlength for binary data" table immediately below this table.

Issue: In version 1.2, an MBO can be specified to be either syncable (top level) or non-syncable. In version 1.5.2, every MBO in a publication is syncable; the MBOs can not be synchronized individually.

Action: Change code as necessary to accommodate this change.

Issue: In version 1.2, if the MBO operation is called with isPending=false, the next IsPending() returns false even if the MBO is not synchronized, or if the synchronization fails. In version 1.5.2, IsPending remains IsPending=true for the MBO operation until it is submitted successfully in the back end.

Action: Change code as necessary to accommodate this change.

Issue: In version 1.2 metadata classes are generated automatically for the MBO, the attributes, the sync parameters, and the operation parameters. In version 1.5.2, only the MBO metadata class is generated automatically.

Action: To generate all metadata classes, select the Create metadata classes option in the MBO Code Generation wizard.