Marwin ja war ich auch von betroffen. Damals hing es soweit ich mich erinnere am Rechtemanagement. 

markus. burger ein Backup, wenn die API von Ninox nicht funktioniert? Das hängt davon ab, wofür Du Ninox einsetzt und was die API (Make/n8n) für Aufgaben hat.

Jeder Fehler ist anders. Wenn die API seitens Ninox ausfällt... Mal kann es sein, dass Du Ninox von außen nicht ansprechen kannst (so wie heute) und mal kannst Du von Ninox aus nichts rausschicken.

Wenn ich das richtig beobachten konnte, war heute nur die Public Cloud davon betroffen. Die Private Clouds nicht. Aber auch das ist keine Garantie.

Ich glaube eine allgemeine Backup-Lösung gibt es da nicht. Man kann eher dafür sorgen, dass man unabhängiger von Online-Diensten wird. Das würde dann in die Richtung self Hosting gehen. Da ist dann am Ende aber auch die Frage, was teurer ist. Ein Ausfall von x Stunden oder die Kosten für eine self Hosting Lösung.

Patrick Danke für die Ideen. Self Hosting nimmt aktuell in der Tat zuviel Arbeit / Kosten / Ressourcen in Anspruch. Ich hatte noch gedacht, dass man die Ninox Daten zur Not lokal abfragt und selbst an andere Dienste weiterschickt. Oder das man die gesamte Geschäftslogik nochmal bei einem zweiten Datenban-Anbieter hat. Alternativen machen einen ja auch immer unabhängig. Hast Du davon schonmal gehört?   

markus. burger auch da ist die Frage, was Ninox für eine Funktion hat. Wenn die Steuerung bei Ninox liegt, bist Du ein Stück weit daran gebunden. Man könnte die Daten auf externe Dienste auslagern. Aber wenn Ninox versagt, kannst Du mit den Daten nichts machen. Dient Ninox allerdings als ein kleiner Teil eines großen Projektes oder nur als reine Datenbank und die Funktionen liegen woanders, kann man ggf. kurzzeitig auf Ninox verzichten oder die Daten entsprechend spiegeln. Aber für eine reine Datenbank gibt es weitaus bessere Tools als Ninox.

Ich habe z.B. mal eine Lizenzierung im Zusammenspiel mit Ninox und mySQL entwickelt. In Ninox werden die Lizenzen angelegt und auf mySQL verschlüsselt gespeichert. Darüber kann ich nun von jeder Plattform aus die Lizenzen prüfen, ändern, usw. - wenn ich sie entsprechend programmiere....

Ninox enthält in dem Fall direkte Informationen über den Lizenzinhaber (Name, .....) und mySQL speichert die Schlüssel, Ablaufdatum, Lizenzinhalt, usw. Das hatte damals aber den Hintergrund, API-Calls zu reduzieren. Heute war jedoch so ein Paradebeispiel. Ich selbst arbeite über die Public Cloud und handle darüber die Lizenzen. Jetzt habe ich einen Kunden mit einer Private Cloud, wo eine Lizenz abgefragt wird. Meine Public Cloud hätte man nicht erreicht, dafür aber die mySQL Datenbank. In dem Fall konnte der Kunde ohne irgendwelche Fehlermeldungen arbeiten, da die Lizenz abgefragt werden konnte.

Und btw., es handelt sich hier nur um Lizenzen für Services die ich anbiete. Nicht um eine Ninox-Lizenzierung.

Wie gesagt, es kommt immer auf den einzelnen Fall an. Wie breit kann man ein Projekt splitten um es nach wie vor attraktiv für den User zu gestalten und was kostet einem der Aufwand für die Umsetzung.

Patrick Ich nutze immer weniger Logik in Ninox seit dem Fehler letztes Jahr, aber bis zu >nur Datenbank< ist es noch ein bisschen. Danke für das konkrete Beispiel, das hat es gleich greifbar gemacht

@markus. burger  Eure Diskussion zusammengefasst kann man sagen dass Ninox ein Qualitätsproblem hat. Ein System ist immer so gut wie das Schwächste Glied in der Kette.

Nicht Ihr solltet back-up Lösungen bauen, sondern Ninox sollte intern sein entsprechende Backup-/Alternativ-Lösungen bauen. Das ist ja der Sinn der Cloud/SaaS Konzepte. 

Self Hosting kann auch Probleme bereiten. Wenn man oder der Mitarbeiter sehr erfahren kann das eine (teure) Alternative sein. Aber man ist dann vom Menschen abhängig.

Ein Ansatz könnte sein die Ninox Funktionalität als Prototyp bei einem andern SaaS Anbieter aufzusetzen und parallel zu betreiben. Mit Logging etc. und wenn das dann stabiler läuft zu wechseln.

Man könnte bei Ninox Druck aufbauen, wenn ein guter Ninox-Kunde der hohe Lizenzbeträge zahlt, einen Anbieterwechsel androht. Auch sollte die Kommunikation seitens Ninox verbessert werden und die Kunden per eMail informieren was passiert ist und was die Maßnahmen zur Verbesserung sind.

LG, Axel