0

Backup zerschießt Datenbank

Hallo zusammen,

ich habe mir ein Backup einer lokalen Datenbank erstellt und wollte diese in ein Clou-Team hochladen. Mir ist nach einer Weile aufgefallen, dass es mir die komplette "dynamischen Auswahlfelder" zerschossen hat.

Ich arbeite viel mit einer zentralen Config-Tabelle, auf die ich in unterschiedlichen "dynamischen Auswahlfeldern" verweise. Zum Beispiel für Budgets, Kategorieen, etc.
Die Config-Tabelle hat also ein Feld für die Rubrik und eins für die Werte.

Die Auswahlfelder verweisen dann auf die Config-Tabelle nach dem Schema select config where Rubrik = Budget oder select config where Rubrik = Kategorie (...funktioniert soweit eigentlich ganz gut)

Beim Import in eine neue Umgebung werden aber die NIDs neu vergeben, auf die in einem "dynamischen Auswahlfeld" verlinkt wird. Da der Wert im "dynamischen Auswahlfeld" aber korrekt importiert wird, kann es sein, dass nun auf einen komplett falschen Wert verlinkt wird.

zB war die Nr 13 früher ein Budget, ist jetzt aber eine Kategorie

Weiß hier jemand Abhilfe? bzw. gibt es eine Möglichkeit eine Backup einzuspielen, ohne dass die NIDs neu vergeben werden?

Bei regulären Verknüpfungen ist mir das bisher noch nicht passiert.

4 Antworten

null
    • mirko3
    • vor 7 Tagen
    • Gemeldet - anzeigen

    Hallo Johannes. Also beim Einspielen eine Backups ist mir das noch nicht passiert. Den von Dir beschriebenen Vorgang kenne ich von der Importfunktion der Mac-App. Also, wenn man Teile einer DB in eine andere DB importiert über die ausschließlich in der Mac-App vorhandenen Importfunktion. Diese zerstört das Script in den dmulti und dchoice Feldern. Ausserdem werden alle importierten Datensätze wieder lückenlos durchnummeriert mit der internen ID. Verweise sind damit unbrauchbar.

    Wenn Du das vermeiden willst, dann ist wohl ein sichererer Weg die dmulti und dchoice über JSON zu befüllen. Jetzt erfolgt die Nummerierung lückenlos im dmulti/dchoice. Die ausgewählte ID durch numbers(dmulti) oder number(dchoice) entspricht also nicht mehr der ID in der Config-Tabelle. Ich denke, das hat Vor- und Nachteile. Man kann auch Config-Tabelle mit JSON-dynamische Auswahlfeldern kombinieren. Das ist das, was ich jetzt immer mal teste - bisher ohne Probleme. Aber wer weiß...

    Ich lege mal ein Beispiel dabei, der Wert "Biene" und "Puma" ist einmal gelöscht worden und wieder angelegt. Damit gibt es eine neue ID in der Config-Tabelle, die ID im dmulti/dchoice bleibt aber gleich. Mirko

      • john_eans
      • vor 4 Tagen
      • Gemeldet - anzeigen

       Das mit der JSON ist super, werde ich für neue Apps so auch umsetzen, erscheint mir etwas konsistenter.

      Ich hab jetzt nochmal x-verschiedene Wege getestet: es ist tatsächlich so, dass die Mac-App sowohl beim Archiv-Import als auch beim Teil-Import (wie von dir beschrieben) einfach stumpf neu nummeriert. Das ist wohl von der "letzten" Sortierung der ersten Ansicht abhängig, nahezu unmöglich das irgendwie zu übersetzen oder zu korrigieren...insofern so wie du schreibst: Die Verweise/Nutzung interner IDs sind mehr oder weniger unbrauchbar, sollte man mit der Mac-App importieren wollen/müssen.
      Leider eine sehr späte Erkenntnis, da ich oft mit den Nr-Werten arbeite.
      (z.B. um per Button einen Wert in einer Verlinkung oder in einem dmulti zuzuweisen.)

      Derzeit stehe ich somit vor dem Problem, dass ich zwei Datenbanken in Teilen zusammenführen will. Die eine liegt in der Cloud, die andere in der Mac-App. In der Cloud kann ich nicht von der einen DB in die andere DB übertragen, und in der Mac-App zerschießt es mir beim Import der Cloud-DB die kompletten IDs...uff 😄

    • fcasoria
    • vor 6 Tagen
    • Gemeldet - anzeigen

    Ich hatte gestern auch ein Problem.Hatte ein Tag vorher ein Backup auf meinem Mac mit der App erstellt.Am nächsten Tag während man mit der Datenbank gearbeitet hat,war alles weg.Die gesamte Datei war kaputt.Zum Glück konnte ich es aus dem Online Backup zurück holen sonst hätten wir ein grosses Problem gehabt.Die Datenbank enthält ein Terminplaner für Friseur und das wäre eine Katastrophe.Die Datenbank hat viel CSS.Aber es darf nicht passieren.

    • Fred
    • vor 4 Tagen
    • Gemeldet - anzeigen

    My response is to only use dynamic choice fields as a UI element and never depend on it to store data. So I have a trigger after update on the dynamic choice field that creates/deletes records from a child table when I select a choice.

    My data entry has evolved now that I use a dashboard to enter in data so the trigger is no longer needed.