Hi,
danke für die Antworten.
Erlaubt mir, es etwas näher zu erklären.
Es gibt keinen Grund gegen regelmäßige Sicherungen, nur es reicht nicht. Ich werde es mir ansehen.
In der Schule werden monatlich Lastschriften von den Kunden eingezogen.
Dabei werden massiv neue Umsätze erzeugt und Verträge angepast.
Es ist sinnvoll, davor eine Sicherung zu machen, weil viele Daten dadurch verändert werden.
Dieser Termin ist aber nicht immer am Fr sondern kann irgendwann sein.
Ebenfalls können neue Kurse entstehen wodurch sich sehr viele Daten ändern, auch davor ist eine Sicheung sinnvoll.
Es muss also eine Möglichkeit geben, eine Sicherung "außerhalb der Reihe" zu machen.
Natürlich kann man das im SSMS machen, aber bitte verstehe, das die Bedienerinnen der Software nicht EDV-affine sind.
Sie hassen es, ihre Access-Oberfläche zu verlassen zu müssen.,
Wenn ich ihnen sage, ihr müßt euch bei SSMS anmelden und dort 5 Klicks machen oder ich biete an, nur einen Klick im Access-Fe...
Sie werden mir um den Hals fallen...
Technisch ist es ja möglich, Ich habe eine Entwicklungsumgebung auf meinem lokalen Rechner, da klappt es wunderbar:
Ich klicke auf "backup" und erzeuge ein SqlCmd, was dann einem shell Command übergeben wird. Darin ist dann das eigentliche Backup-Statement, wie oben beschrieben.
Ich werte dann den Output aus und merke mir die Filenumber in einer kleinen Tabelle, die ich für Restore-Funktionen nutze, wo die FILE-Numme benötigt wird.
Das wird man sicherlich auch über eine Systemtabelle rausfinden können, aber die sind mit zu kompliziert...
Dann habe ich neben der Produktion noch eine weitere Umgebung aufgebaut: Sandbox.
Dort kann man die Produktionsdaten rein kopieren und beliebig Dinge austesten, ohne die echte Produktion zu gefährden.
Ich habe einen Button in der Access-Oberfläche der da heißt: "fill Sandbox from Produktion" und zack wird der aktuelle Produktionsbestand dorthin kopiert iund sie können sich dort anmelden und spielen. Wunderbar!
Intern gelöst durch Backup von Produktion und Restore von dem Prod-Backup
Wie gesagt, das sind alles Dinge, die man auch im SSMS machen kann, aber ein Oberflächenbruch ist immer schlecht.
Ich habe es ja alles in der Entwicklung, mit einer lokalen DB-Installation, am laufen, nur frage ich mich, warum es auf dem Server nicht läuft, obwohl ich da auch lokal angemeldet bin.
Die Frage ist also: warum kann ich in der Entwicklunsumgebung sqlcmd Befehle absetzen, nur in der Produktin nicht, obwolh iah an beiden lokal angemdeldet bin und admin-Rechte habe.
Ich hoffe, ich konnte mich ausreichend erklären...
Danke für das Interesse!
Martin