Letztes backup/restore datum

[mkinzler]

Backup das bisher vom Kunden manuell durchgeführt wurde ist nicht mit dem automatischen Backup aus dem Programm heraus gleichzusetzen

[MyRealName]

Ok, scheinbar gibt es einen Solchen Wert ind er Datenbank nicht zum auslesen. Ich hatte gehofft, sowas wie die OSD Version etc, die man ja auslesen kann, dass da vllt. auch eine Info steht, wann die DB erzeugt wurde (über script oder restore oder was auch immer).

Klar kann ich mir die Funktionen schreiben um nachts ein backup/restore zu machen, aber es existrioert noch nicht und ich hatte jetzt das Problem, dass die KundenDb beschädigt ist und der Kunde mir IMHO quatsch erzählt. Das hat dann nämlich auch was mit Support-Stunden-Abrechnung zu tun.

Aber danke an alle, die sich an der Diskussion beteiligt haben.

[KodeZwerg]

Workaround eventuell:
In deinem Programm, was der Anwender steuert, wenn der Anwender da auf "Backup" Knopf drückt, könnte da nicht auch ein Registrierungs oder Ini oder Text Datei Eintrag erfolgen, ebenso für Knopf "Restore" (falls überhaupt Notwendig)?
Dann hättest Du zwei Werte die Du verarbeiten könntest und eventuell eine visuelle Darstellung basierend darauf wie "Letztes Backup am/um" oder "Achtung: Letztes Backup bereits X Minuten/Stunden/Tage her!" oder völlig Silent nur per Log-Datei.
So wärst Du Unabhängig von DB-Code, was Du ja vermeiden wolltest.

[jobo]

Das klingt eher nach einem Punkt, wo man im Sinne von Professionalität ein Schleife über seine Supportleistungen und deren Bedingungen drehen sollte.
Wenn es Programme gibt (eins?), die einen Backupstempel schreiben, muss man evtl. deren Einsatz verlangen. Andernfalls gibt es nur Support nach Aufwand.

Außerdem denke ich, solche "Effekte" sollten auch die Opensource Anbieter in ihre Entwicklung einbeziehen. Bei closed source Systemen und entsprechenden Wartungsverträgen ist es relativ einfach, hier klare Kante zu fahren. Solche Features entscheiden m.E. am Ende auch über Erfolg und Einsatzbreite eines Systems.

[mkinzler]

Man könnte sich überlegen, in das Programm eine Backupfunktion einzubauen, die neben dem Backup der Datenbank noch andere Sachen sichert. Diese Funktion (bzw. die Verwendung) wäre dann verpflichtent und entscheidend bei einem Supportfall. Man könnte dann auch im Programm auf "fehlende" Backups hinweisen.

[MyRealName]

Zum Verständnis :

Ich will natürlich schon länger eine Funktion, wo nicht nur regelmässig ein backup gemacht wird, sondern es auch kostenpflichtig zur Sicherung auf unserem Firmenserver hochgeladen werden kann, um zum Bsp. die letzten 7 oder 30 Tage als Kopien zur Sicherheit da zu haben.

Bei dem Backup/Restore geht es natürlich darum, eventuell Index- oder Seitenfehler der Datenbank sicher zu beheben, von daher soll natürlich nicht nur ein Backup gemacht werden, sondern auch ein Restore, um darin weiter zu arbeiten. Nur ein backup bringt da natürlich nichts, da ich in derselben Datei weiterarbeite und die Fehler sich nur verschlimmern :p

[jobo]

Das Anliegen bzw. das Ziel der Backup "Erkennung" war denke ich schon relativ klar.
Diese Backuperkennung wäre also auch nur die halbe Miete. Man müsste dann zusätzlich ein Restore feststellen, vielleicht reicht auch das Letztere.
Vielleicht kann man es auch andersrum sinnvoll für den akuten Zweck sein, eigenständig eine Prüffunktion anzustoßen, die Index oder Seitenfehler wenigstens findet. Es reicht ja schon auf Existenz zu prüfen.
Damit spart man sich den Datenverkehr und ist dennoch aussagefähig bzw. kann es im notfalls on demand aufrufen.
Ich weiß nicht, ob fb die reine Erkennung bietet ohne ein backup/restore wirklich durchzuführen.