Sperrenerweiterung   Um die Datenkonsistenz zwischen der konsolidierten und der entfernten Datenbank aufrechtzuerhalten, verwendet der MobiLink-Server die folgende Abfrage über die gespeicherte Prozedur ml_lock_rid, um die entfernte ID in jeder Synchronisationsphase zu sperren.

SELECT sync_key into p_sync_key FROM ml_database WHERE rid = a_given_remote_id WITH RR USE AND KEEP EXCLUSIVE LOCKS;

Diese Abfrage sperrt die entfernte ID im Exklusivmodus, um gleichzeitige Synchronisationen mit derselben entfernten ID zu verhindern.

Wenn Sperrenfehler für entfernte MobiLink-IDs auftreten, wenn keine gleichzeitigen Synchronisationen derselben entfernten ID vorliegen, z.B. wenn der MobiLink-Fehlercode -10341 im Log des MobiLink-Servers ausgegeben wird, sollten Sie die DB2-Konfigurationsparameter maxlocks und locklist ändern, um eine Sperrenausweitung zu verhindern. Weitere Hinweise finden Sie in Ihrer DB2-Dokumentation.

Datentypen zuordnen   Die Datentypen von Spalten müssen korrekt zwischen der konsolidierten und der entfernten Datenbank abgestimmt und zugeordnet werden. Siehe IBM DB2 LUW-Datentypzuordnung.

CHAR-Spalten   In IBM DB2 LUW haben CHAR-Datentypen eine feste Länge und werden bis zur vollen Länge der Zeichenfolge mit Leerzeichen aufgefüllt. In entfernten MobiLink-Datenbanken (SQL Anywhere oder UltraLite) entspricht CHAR dem Datentyp VARCHAR: Werte werden nicht bis zu einer bestimmten Länge mit Leerzeichen aufgefüllt. Verwenden Sie in der konsolidierten Datenbank unbedingt VARCHAR anstelle von CHAR. Wenn Sie CHAR verwenden müssen, können Sie mit der mlsrv12-Befehlszeilenoption -b während der Synchronisation nachgestellte Leerzeichen aus Zeichenfolgen entfernen. Diese Option ist wichtig für Zeichenfolgenvergleiche, mit denen Konflikte erkannt werden.

Siehe mlsrv12-Option -b .

Tablespace-Kapazität   Der Tablespace und der temporäre Tablespace einer IBM DB2 LUW-Datenbank, die als konsolidierte Datenbank verwendet werden soll, muss mindestens 8-kB-Seiten verwenden.

Außerdem gibt es Spalten, für die ein Tablespace vom Typ LONG erforderlich sind. Wenn es in der Standardkonfiguration keinen Tablespace vom Typ LONG gibt, müssen die Anweisungen zum Erstellen der Tabelle mit diesen Spalten entsprechend angegeben werden. Dazu ein Beispiel:

CREATE TABLE ... ( ... )
IN tablespace
LONG IN long-tablespace

Ein Beispiel in der Beispielanwendung finden Sie unter MobiLink-Beispiel CustDB.

Variablen für die gesamte Sitzung   Frühere Versionen von IBM DB2 LUW (bis Version 8) unterstützen keine Variablen für die ganze Sitzung. Eine praktische Lösung ist der Einsatz einer Basistabelle mit Spalten für den MobiLink-Benutzernamen und andere sitzungsbezogene Daten. Diese Basistabelle enthält Zeilen, die gleichzeitige Synchronisationen darstellen.

Benutzerdefinierte Prozeduren   IBM DB2 LUW bis Version 8.2 erfordert, dass Sie SQL-Prozeduren in eine ausführbare Bibliothek (z.B. eine DLL) kompilieren. Die so erstellte DLL/gemeinsam genutzte Bibliothek muss in ein bestimmtes Verzeichnis auf dem Server kopiert werden. Beachten Sie, dass Sie Prozeduren in verschiedenen Sprachen schreiben können, u. a. in C/C++ und Java.

Weitere Hinweise zu Java- und .NET-Synchronisationsskripten finden Sie unter:

• Schreiben eines Synchronisationsskripts in Java
• Schreiben eines Synchronisationsskripts in .NET

Anführungszeichen in Systemprozeduraufrufen verdoppeln   Wenn Sie Ihrer konsolidierten IBM DB2-Datenbank mit einer MobiLink-Systemprozedur Skripten hinzufügen, müssen Sie die Anführungszeichen verdoppeln. Beispiel: Wenn das Skript, das Sie mit ml_add_table_script hinzufügen, für eine beliebige andere konsolidierte Datenbank die Zeile SET "DELETED"=''Y'' enthält, müssen Sie diese Zeile für IBM DB2 wie folgt schreiben: SET "DELETED" = ''''Y''''.