MultiBaseCS Forum

Hallo,

ich hatte mit MultiBaseCS3 eine lokale Datenbank angelegt und diese seinerzeit mit einer Cloud-Datenbank synchron gehalten.
Jetzt habe ich MultiBaseCS4 installiert, eine neue leere lokale Datenbank angelegt und diese mit der gleichen Cloud-DB synchronisiert.
Die meisten Daten sind wie erwartet identisch mit denen in der Cloud und mit denen der alten lokalen MBCS3-Datenbank auf dem alten PC.
In der Cloud werden alle Daten (meiner untersuchten Stichprobe) erwartungsgemäß angezeigt.

Allerdings musste ich feststellen, dass in meiner neuen lokalen Datenbank alle Dateneinträge eines bestimmten Beobachters nicht mehr diesem Beobachter zugeordnet sind!
Der Beobachtereintrag in den Stammdaten existiert weiterhin (ohne darauf verweisende Dateneinträge) mit der ursprünglichen GUID_Beobachter und wurde offenbar aus der Cloud heraus korrekt heruntersynchronisiert.
In den ursprünglich diesem Beobachter zugeordneten Dateneinträgen ist jedoch ein neuer, in den Stammdaten nicht vorhandener GUID_Beobachter-Wert eingetragen. Daher Wird beim Filter auf den (ursprünglichen) Beobachter kein Datensatz gefunden und beim Anzeigen der Datensätze dieses Beobachters kein Name angezeigt.
Die lokale Datenbank ist somit inkonsistent, obwohl sie frisch aus einer Cloud-Datenbank (die den Beobachternamen noch korrekt anzeigt, bei der ich allerdings die GUID_Beobachter nicht anzeigen kann) heruntersynchronisiert wurde!

Es ist genau ein Beobachter betroffen.
Ich habe diese Datensätze in der Listenansicht durch Sortieren der Beobachter-Spalte ausgewählt und den ursprünglichen Benutzer neu zugewiesen. Danach war meine lokale DB offenbar wieder in Ordnung, jedoch wurde meine Arbeit bei der nächsten Synchronisation mit der Cloud wieder mit den fehlerhaften Werten überschrieben (obwohl meine lokalen Datensätze ja eigentlich neuer sind als die in der Cloud).

Nun sitze ich wieder auf der inkonsistenten und fehlerhaften lokalen Datenbank und kann diesen Zustand nicht reparieren.
Offenbar manipuliert die Synchronisationsroutine die Daten.

• Wie kann ich die Daten reparieren?

• Wie kann ich eine solche Situation für die Zukunft ausschließen?

• Wieso wird die Inkonsistenz bei der regelmäßigen Basis-Datenpflege nicht gefunden?

Vielen Dank!

Torsten


P.S.: Hier ein kurzes SQL-Snippet, das in ähnlicher Form vielleicht in die Basis-Datenpflege integriert werden könnte:

Hallo Torsten,

Du hast da eine sehr interessante Entdeckung gemacht.

Aktuell gehen wir davon aus, dass dieses Verhalten durch einen gelöschten Beobachter zustande kommt. Wird ein Beobachter in einer lokalen MultiBaseCS Datenbank gelöscht und sind diesem Beobachter noch Beobachtungen zugeordnet, so muss ein entsprechender Ersatz angegeben werden. Damit beim Datenimport (egal ob nur neue oder auch geänderte Beobachtungen) ein gelöschter Beobachter nicht wieder aktiv gesetzt wird, speichert MultiBaseCS in der Datenbank am gelöschten Beobachter die GUID des Ersatzes. Beim Import werden Beobachtungen dann entsprechend korrigiert. Ich will nicht ausschließen, dass dabei etwas schief gehen kann.

In Verbindung mit der MultiBaseCS Cloud, wo einem Benutzer ein konkreter Beobachter zugeordnet ist, kann das unter Umständen zu dem von Dir beschriebenen Verhalten führen.

Zunächst würde uns interessieren, ob Du mit nachfolgendem SQL-Statement einen oder mehrere Treffer bekommst. Wenn ja, kannst Du uns das Ergebnis als Excel- oder Text-Datei gezippt an dieses Thema mit dranhängen? In MultiBaseCS im Modul Liste kann man das Ergebnis als Excel-Liste exportieren (Kontextmenü auf der rechten Maustaste > Excel-Datei exportieren).
Herzliche Grüße
Tino

Hallo Tino,

da kam nur eine Zeile zurück, die ich hier ohne Datenschutzbedenken direkt im Text (mit allen Zeichen) wiedergeben kann, weil der Eintrag offenbar keinem Menschen zugeordnet ist:

GUID_Beobachter GUID_Replace Beobachter Flag_Deleted
519ec2a1-a408-4991-89d7-09535884f344 b4cb944d-d04f-4a1d-aa05-b3faad44c09f Chalcolestes viridis...Chalcolestes viridis True

Den hatte ich kürzlich gelöscht, nachdem ich einen genaueren Blick in die Beobachter-Stammdaten geworfen hatte. Er existierte auch bereits in der alten Datenbank und es waren keine Beobachtungen zugeordnet.

In der alten Datenbank auf MBCS3, die bis zum letzten Jahresende mit dieser Cloud-Datenbank synchronisiert wurde, hat dieser Filter übrigens keine Treffer geliefert, obwohl ich mich erinnere, vor langer Zeit mal doppelt angelegte Beobachter konsolidiert zu haben. Die Abfrage nach Flag_Deleted=0 lieferte aber die erwartete Beobachterliste.
Einer dieser damals konsolidierten Beobachter ist derjenige, der jetzt nicht mehr funktioniert.

Der in den Datensätzen vorhandene GUID_Beobachter, für den es keine Entsprechung in der Beobachter-Tabelle gibt, ist übrigens in der alten Datenbank auch nirgends (tblDaten, tblBeobachter) vorhanden. Er ist wohl außerhalb meines PCs erzeugt worden.

Wäre es ggf. möglich, in der Cloud-Website auf der [Status]-Seite der Beobachtungen sowie auf der 'Benutzer Bearbeiten'-Seite jeweils die GUID_Benutzer mit anzuzeigen? Vielleicht ergibt sich ja daraus ein Hinweis.
(Übrigens klappt bei mir seit Kurzem das Anmelden an der Cloud oft nicht mehr reibungslos, dazu erstelle ich ggf. ein getrenntes Posting.)

Was kann ich sonst tun?

LG,
Torsten


P.S.: Ich habe gerade lokal einen Testdatensatz für diesen Beobachter erstellt und in die Cloud synchronisiert. Dort erscheint er unter dem korrekten Beobachternamen. Lokal wurde beim Synchronisieren wieder der GUID_Beobachter des Datensatzes auf den gleichen falschen, nicht existierenden Eintrag gesetzt. Im Log des Sync-Service wurde dabei aber angeblich ein neuer Beobachter heruntersynchronisiert:
11:31:28: Cloud (Details): Download (tblBeobachter)
11:31:28: Cloud (Details): Download IDs: '995 ........ '
11:31:28: Cloud (Details): DownloadData (tblBeobachter, ResultDS: 1)

Dieser erscheint jedoch nach dem Synchronisieren nicht in der lokalen Beobachter-Tabelle.
Nach dem Löschen des Testdatensatzes in der Cloud wurde der Datensatz auch lokal gelöscht, wiederum mit der Angabe im Log, dass der neue Beobachter heruntergeladen wurde.
Also wird anscheinend einerseits die Beobachter-GUID beim hochsynchronisieren in die Cloud umgeschrieben und andererseits die umgeschriebene GUID beim heruntersynchronisieren in die lokale DB verworfen.

Hallo,
das Problem besteht leider immer noch.
LG, Torsten

Hallo nochmal,

auch jetzt besteht das Problem mit dem nicht synchronisierten Beobachter weiterhin, bei JEDEM Synchronisationsvorgang wird wieder gemeldet: Man beachte, dass die lokale Datenbank leer angelegt wurde und initial mit Daten aus der Cloud gefüllt wurde, was bei allen anderen Beobachtern funktioniert zu haben scheint. Sogar der Beobachtereintrag, dem in der Cloud dieser obige GUID zugeordnet ist, wurde in der lokalen Datenbank mit seinem originalen, seit Jahren bestehenden GUID angelegt. Die Daten des Beobachters in der Cloud stimmen mit den ursprünglichen überein. Nur der GUID wurde auf Cloud-Seite verändert und kann nicht synchronisiert werden und keine Daten des Beobachters landen in der lokalen Kopie der Cloud-Datenbank.

Gibt es irgend etwas, das ich helfen kann, damit der Fehler endlich eingegrenzt und behoben werden kann?


Ich habe heute im Konfigurationsbereich der Cloud unter Cloud-Einstellungen | Einstellungen den Punkt "Benutzer mit Cloud synchronisieren" gefunden, der mit "Nein" vorbelegt ist. Was genau bewirkt diese Konfigurationsoption?

Danke und LG,
Torsten

Hallo Torsten,

dieses Verhalten konnten wir in der Tat bisher nicht komplett nachvollziehen.

Welche MultiBaseCS Version setzt du derzeit ein?

Ich gehe derzeit davon aus, dass in der Datenbank tatsächlich irgendwo noch ein Datensatz mit der GUID '995BCA10-CE19-4457-B58F-D8C16A66E6F3' vorhanden ist. Die Prüffunktion der Cloud würde dies dann feststellen und versuchen den Beobachter mit dieser GUID nachträglich herunterzuladen. Leider geht derzeit aus dem Log noch nicht hervor, wo dieser Datensatz konkret vorhanden ist. Dies werden wir mit einem der nächsten Updates ändern.

Du hat geschrieben, dass dieses Verhalten auch in einer leeren Datenbank, die man der Cloud synchronisiert auftritt?

Dann könnten wir auch versuchen diesen Fehler bei uns nachzustellen. Ich würde Dir noch einmal separat eine Nachricht mit meiner E-Mail Adresse senden. Wenn das ok ist, könntest Du mich einmal in deine Cloud einladen. Dann könnten wir hier die Synchronisation in eine leere Datenbank testen und hoffentlich die Ursache finden. Deine Daten behandeln wir natürlich vertraulich!

Beste Grüße
Danny

Hallo Torsten,

ach ja, hatte ich übersehen:

Die Option "Benutzer mit Cloud synchronisieren" hat nichts mit den Beobachtern in MultiBaseCS zu tun.

Über diese Option kann ich bei Cloud-Datenbanken, die mehrere Server-Versionen miteinander verbinden die enthaltenen Benutzerkonten für die Benutzerverwaltung von MultiBaseCS über die Cloud synchronisieren. Dadurch können sich bei diesem Szenario Nutzer mit ihren Login-Daten auch an anderen Standorten einloggen.

Diese Option hilft uns also nicht weiter.

Beste Grüße
Danny

Hallo Danny, hallo Tino,

ich komme erst jetzt zum Antworten, zunächst nochmal vielen Dank für das lange Hilfe-Telefonat!

Eine zweite lokale Testdatenbank, die ich mit der gleichen Cloud synchronisiert habe, zeigt das geschilderte Problem nicht !

Ich kann es leider nicht mehr genau rekonstruieren, aber möglicherweise ist der Fehler in der ersten Datenbank darauf zurückzuführen, dass diese nur vermeintlich ganz leer war. Nach der Migration von MBCS3 zu MBCS4 (auf neuem PC) hatte ich zunächst versucht, die originale Datenbank, die ich vorher als MBCS-Datei exportiert hatte, wieder einzulesen. Nachdem dies unsäglich lange dauerte (siehe Topic ''Import einer MBCS-Datenbank EXTREM langsam" unter viewtopic.php?f=2&t=15, hatte ich den Vorgang wohl seinerzeit abgebrochen und dann möglicherweise sofort die (immer noch mehrstündige) Synchronisierung eingerichtet. Hier könntet ihr gelegentlich vielleicht mal nachsehen, ob der Abbruch des Imports einen wirklich vollständigen Rollback bewirkte oder ob die 'gelöschten Beobachter' überdauern konnten. Eine bessere Erklärung fällt mir nicht ein.

Ich habe jetzt die Testdatenbank durch Umbenennen zur aktuellen 'Cloud'-Datenbank gemacht und der Topic kann geschlossen werden.