Im Folgenden werden einige Einschränkungen bei der Verwendung des Assistenten zum Erstellen eines Synchronisationsmodells und des Modellmodus beschrieben:
Kein erneutes Deployment für Änderungen außerhalb des Modells möglich Wenn Sie ein Deployment für ein Modell vornehmen und es dann außerhalb des Modells ändern, werden diese Änderungen nicht im Modell gespeichert. Das stellt kein Problem dar, wenn Sie das Modell als Ausgangspunkt verwenden und dann alle Änderungen außerhalb des Modells vornehmen. Wenn Sie jedoch ein erneutes Deployment des Modells vornehmen wollen, sollten Sie die Änderungen im Modellmodus durchführen, sodass sie gespeichert werden und ein erneutes Deployment möglich ist.
DB2-Mainframe MobiLink-Modelle können nicht für konsolidierte DB2 Mainframe-Datenbanken verwendet werden.
MobiLink-Systemdatenbank Es ist nicht möglich, eine MobiLink-Systemdatenbank zu verwenden.
Mehrere Publikationen Es ist nicht möglich, mehrere Publikationen zu erstellen. Nachdem Sie ein Deployment des Modells vorgenommen haben, können Sie mithilfe von Nicht-Modell-Methoden weitere Publikationen hinzufügen, z. B. die CREATE INTO-Anweisung. Es ist jedoch nicht möglich, diese Erweiterungen in das Modell einzufügen.
Ansichten Es ist bei der Auswahl von konsolidierten Datenbanktabellen für Tabellenzuordnungen nicht möglich, eine Ansicht auszuwählen.
Generierte entfernte Datenbank Wenn Sie im Assistenten zum Erstellen eines Synchronisationsmodells ein neues entferntes Schema erstellen, enthalten die neuen Spalten der entfernten Datenbank keine Fremdschlüssel, Indizes oder Standardspaltenwerte für die Spalten in der konsolidierten Datenbank. UltraLite-Datenbanken unterstützen keine NCHAR- oder NVARCHAR-Spalten. Es ist daher nicht möglich, Tabellen einer konsolidierten Datenbank mit Spalten dieser Datentypen zu verwenden, um ein neues entferntes Schema für eine entfernte UltraLite-Datenbank zu generieren. Nach dem Deployment können Sie das entfernte Schema erstellen oder ändern und dann das Schema für das Modell aktualisieren.
Berechnete Spalten Wenn Sie eine konsolidierte Datenbanktabelle mit berechneten Spalten synchronisieren wollen, können Sie kein Upload in die Tabelle durchführen. Wenn Sie ein Deployment eines Synchronisationsmodells mit berechneten Spalten vornehmen, kommt es während des Deployments bei der Erstellung der Trigger, die für zeitstempelbasierte Downloads verwendet werden, möglicherweise zu Fehlern. Sie können die Spalte entweder aus der Synchronisation ausschließen oder die Tabelle als reine Download-Tabelle konfigurieren (und entweder den Snapshot-Download verwenden oder die generierte konsolidierte SQL-Datei bearbeiten, um die berechnete Spalte aus der Triggerdefinition zu entfernen).
Das Kopieren berechneter Spalten verursacht beim Deployment des neuen entfernten Schemas zur Erstellung einer neuen entfernten Datenbank einen Syntaxfehler. Bei der Verwendung berechneter Spalten ist einer der folgenden Schritte durchzuführen:
Führen Sie das Deployment des Synchronisationsmodells in eine vorhandene entfernte Datenbank durch.
Schließen Sie die berechnete Spalte aus dem entfernten Schema aus. Beachten Sie: Wenn Sie eine konsolidierte Datenbanktabelle mit berechneten Spalten synchronisieren wollen, können Sie kein Upload in die Tabelle durchführen.
Die Microsoft SQL Server-Beispieldatenbank AdventureWorks enthält berechnete Spalten. Wenn Sie diese Datenbank zum Erstellen eines Modells verwenden, müssen Sie die Spalten als reine Download-Spalten festlegen oder die Spalten aus der Synchronisation ausschließen.
Logische Löschungen Bei der Unterstützung des MobiLink-Synchronisationsmodells für logische Löschungen wird davon ausgegangen, dass eine logische Löschspalte sich nur in der konsolidierten Datenbank und nicht in der entfernten Datenbank befindet. Wenn ein konsolidiertes Schema in ein neues entferntes Schema kopiert wird, lassen Sie alle Spalten aus, die mit den logischen Löschspalten in den Synchronisationseinstellungen des Modells übereinstimmen. Bei einem neuen Modell wird der Standardspaltenname gelöscht.
So fügen Sie den Spaltennamen für die logische Löschung dem entfernten Schema hinzu:
Wählen Sie im Assistenten die Option Logische Löschungen verwenden aus.
Benennen Sie die logische Löschspalte um, sodass sie mit keinem Spaltennamen in der konsolidierten Datenbank übereinstimmt.
Nachdem der Assistent fertig ist, aktualisieren Sie das entfernte Schema und behalten die Standardtabellenauswahl bei. Der Name der logischen Löschspalte erscheint in der Schemaänderungsliste und kann dem entfernten Schema hinzugefügt werden.
Sie müssen die logische Löschspalte der entfernten Datenbank der Löschspalte der konsolidierten Datenbank zuordnen.
Lange Objektnamen Die Namen der beim Deployment erstellten Datenbankobjekte können länger als die von der Datenbank unterstützte Länge sein (da die neuen Objektnamen durch das Anfügen von Suffixen an die Namen der Basistabelle erstellt werden). In diesem Fall nehmen Sie das Deployment in eine Datei vor (nicht direkt in eine Datenbank) und bearbeiten die generierte SQL-Datei, um alle zu langen Namen zu ersetzen.
Neue entfernte Schemata Wenn Sie mit dem Assistenten zum Erstellen eines Synchronisationsmodells ein neues entferntes Schema erstellen, enthalten die Spalten der neuen entfernten Datenbank keine Indizes für die Spalten in der konsolidierten Datenbank. Fremdschlüssel und Standardspaltenwerte werden in die neue entfernte Datenbank kopiert. Da diese Unterstützung jedoch auf Datenbankmetadaten basiert, die vom ODBC-Treiber zurückgegeben werden, können eventuelle Treiberprobleme zu Syntax- oder anderen Fehlern führen. Wenn zum Beispiel ein Treiber einen Standardspaltenwert in einem Format angibt, mit dem ein solcher Standardwert nicht in einer entfernten SQL Anywhere- oder UltraLite-Datenbank deklariert werden kann, können Fehler auftreten (darunter auch Syntaxfehler beim Deployment).
Das Kopieren berechneter Spalten verursacht beim Deployment des neuen entfernten Schemas zur Erstellung einer neuen entfernten Datenbank einen Syntaxfehler. Bei der Verwendung berechneter Spalten gehen Sie wie folgt vor: Führen Sie entweder ein Deployment in eine vorhandene entfernte Datenbank durch, um die Verwendung des entfernten Modellschemas zu vermeiden, oder führen Sie folgende Schritte aus:
Führen Sie das Deployment des Synchronisationsmodells in eine vorhandene entfernte Datenbank durch.
Schließen Sie die berechnete Spalte aus dem entfernten Schema aus. Beachten Sie: Wenn Sie eine konsolidierte Datenbanktabelle mit berechneten Spalten synchronisieren wollen, können Sie kein Upload in die Tabelle durchführen.
UltraLite-Datenbanken unterstützen keine NCHAR- oder NVARCHAR-Spalten. Es ist daher nicht möglich, Tabellen einer konsolidierten Datenbank mit Spalten dieser Datentypen zu verwenden, um ein neues entferntes Schema für eine entfernte UltraLite-Datenbank zu generieren.
Nach dem Deployment können Sie das entfernte Schema erstellen oder ändern und dann das Schema für das Modell aktualisieren.
Proxytabellen Es ist möglich, eine Synchronisation mit konsolidierten Datenbanktabellen durchzuführen, die Tabellen in eine andere Datenbank weitergeben. Wenn Sie jedoch eine TIMESTAMP-Spalte für zeitstempelbasierte Downloads verwenden, müssen Sie die TIMESTAMP-Spalte sowohl der Basistabelle als auch der Proxytabelle hinzufügen. Der Assistent für das Deployment eines Synchronisationsmodells kann einer Proxytabelle oder seiner Basistabelle keine Spalte hinzufügen. Daher müssen Sie entweder eine Spalte verwenden, die sowohl in der Basistabelle als auch in der Proxytabelle verwendet wird, oder eine Schattentabelle bzw. einen Snapshot-Download benutzen.
Materialisierte Ansichten Wenn Sie zeitstempelbasierte Downloads verwenden und gewählt haben, konsolidierten Tabellen eine Zeitstempelspalte hinzuzufügen, müssen Sie vor dem Deployment alle materialisierten Ansichten deaktivieren, die von den Tabellen abhängen. Andernfalls werden möglicherweise Fehler ausgegeben, wenn versucht wird, die Tabellen zu ändern. Verwenden Sie bei konsolidierten SQL Anywhere-Datenbanken die Systemprozedur sa_dependent_views, um festzustellen, ob für eine Tabelle abhängige materialisierte Ansichten vorhanden sind. Weitere Hinweise finden Sie unter der sa_dependent_views-Systemprozedur.
Entfernte Datenbanken basierend auf einer konsolidierten Oracle-Datenbank erstellen Wenn Sie eine konsolidierte Oracle-Datenbank als Basis für die entfernte SQL Anywhere- oder UltraLite-Datenbank verwenden, kann es sinnvoll sein, DATE-Spalten in der konsolidierten Datenbank in TIMESTAMP zu ändern. Andernfalls gehen beim Upload Informationen zu den Sekundenbruchteilen verloren.
Proxytabellen Wenn Sie Schattentabellen verwenden, die von Triggern verwaltet werden, sollten sich die Trigger und Schattentabellen in der Basistabelle befinden. Ein Trigger in einer Basistabelle kann eine Schattentabelle in der Datenbank, die die Proxytabelle für die Basistabelle definiert, nicht ändern.
Kommentieren Sie diese Seite in DocCommentXchange. Senden Sie uns Feedback über diese Seite via E-Mail. |
Copyright © 2009, iAnywhere Solutions, Inc. - SQL Anywhere 11.0.1 |