Office: (Office 2003) Aktion bei Schließen der DB

Hallo Accessgemeinde...

meine Zielstellung... ich will mir was konstruieren, dass mir regelmäßige Backups einer DB macht und das Backup mit der laufenden Versionsnummer versieht. Dazu einen Code zu formulieren sehe ich nicht als Schwierigkeit und ist nicht meine Frage. Diese lautet:

Kann ich an irgendeiner Stelle beim Öffnen oder Schließen(wäre mir am liebsten) die Ausführung von Code auslösen ohne ein Formular zu verwenden??????

Mit bestem Dank im Voraus....

:)

 

Hallo,
Backups von Access aus zu machen halte ich für keine gute Idee, da zu viel Schief gehen kann.
Besser man kopiert das Backend mit Datum versehen per Windows Aufgabenplaner zu bestimmten Uhrzeiten oder bei Rechnerstart.

Andreas

 

Danke für die Antwort...
Ich bin mir jetzt nicht im Klaren, welche Risiken da bestehen, ich nehme es aber mal als gegeben hin. Eine Batch zu schreiben und diese über die 'geplanten Tasks' auszuführen scheint mir eine brauchbare Lösung.

Trotzdem hätte ich meine Frage aus #1 gern beantwortet. Würd' mich halt auch so interessieren, ob es da irgendwelche 'Angriffs'möglichkeiten gibt.

 

Du könntest eine Funktion schreiben und diese in einem Makro ablegen. Dieses Makro könntest du durch ein Kommandozeilenargument (IIRC /x Makroname) beim Access-Start aufrufen.

Die Funktion müsste die Backenddatei kopieren. Das wird bei geöffnetem und verbundenem Frontend schwierig. Wenn es unbedingt Access sein muss, würde ich das in einer "Service-Datenbank" auslagern, die das macht und selbst nicht auf Tabellen des FE oder BE zugreift.

Aber grundsätzlich ist Datensicherung keine Aufgabe für Access.

 

Hallo
ich habe das einmal so gelöst:

•Access MDB (FE) als /Runtime gestartet
beim schliesen prüfen ob Daten Verändert sind
wenn das der Fall ist MDB schliessen und
zweite Access MDB auch als /Runtime Starten die, die BE-MDB Kopiert
die Kopie heist dann in einem BackupPfad so was SjjjjmmtthhmmssPROJ.mdb

ich könnte auch ein Muster mit allem drum und dran erstellen *wink.gif*
braucht jedoch zeit
ob ich das noch vor meiner nächsten Herz operation vom Dinstag 11.10.11 07:30 noch hin bekomme
kann ich nicht versprechen *frown.gif*

 

eine Übliche Methode um auf das Schließen der Datenbank zu reagieren ist ein verstecktes Formular, bei diesem bekommst Du mit dem Ereignis
Form_Close()
mit wenn das Formular geschlossen wird, und dieses wird auf jeden Fall auch geschlossen wenn die Accessanwendung pet ALT+F4 oder auf andere nicht von Dir angebotene Menümöglichkeiten geschlossen wird - ausser dem Abschuß durch den Taskmanager oder das PC-Ausschalten *grins )


Gruß

Frank

 

Was genau ist diese DB?

Ein Access-Backend kannst Du jederzeit kopieren und damit sichern, wenn Du sicherstellen kannst, dass es keine aktiven Zugriffe darauf gibt wie
- offene gebundene Formulare inkl. Listen- und Kombifelder,
- DLookups u.ä.,
- Recordsets,
- Fremdzugriffe aus anderen Anwendungen,
und das natürlich unter Beachtung eines möglichen Mehrnutzerbetriebes (der ist bei den vorangegangenen Hinweisen noch nicht so beachtet worden).
Der Anstoß des Backups kann also durchaus von einem Formular ausgehen, es sollte nur allseits ungebunden sein. Persönlich verwende ich so ein Formular beim Schließen der Anwendung, wo der Anwender entscheiden kann, ob er einfach nur schließen will oder ob er mit Datensicherung schließen will für den Fall, wo er Neueintragungen vorgenommen hat.

Bei Kopieren des BE´s mit aktiven Zugriffen hast Du eine latente Gefahr auf "unnachvollziehbare" Fehler bis zur Korruption der DB.

Für eine laufende Datensicherung könnte man die Inhalte von wesentlichen Tabellen per Abfragen in eine leere Kopie des Backends kopieren. Hier könnte man überlegen, ob man Beziehungen und Indizes "einspart", um schnell und problemlos schreiben zu können. Wenn es nur um Daten geht, könnte man auch schlicht Tabellen in Textdateien exportieren.
In beiden Fällen braucht man dann etwas höhere Rücksicherungsintelligenz.
Bei mehreren vorhandenen Backups muss man aber auch entscheiden, welches davon das Hilfreichste ist.

Das FE brauchst Du nicht zu sichern, sondern würdest es bei Bedarf (oder laufend) durch ein sauberes Original vom Entwickler ersetzen.

 

@Ruedi, das ist ganz lieb von Dir aber bitte kümmer Dich um Deine Gesundheit. HIer sind diverse Lösungsansätze gezeigt, die mich sicher weiter bringen werden.

@Frank, diese Idee hab ich auch schon überlegt.

@Eberhard, hier war zunächst die Mutter des Gedankens, erst einmal meine Entwicklerversionen regelmäßig zu sichern und mit einer fortlaufenden Nummer zu versehen. Die Datensicherung ist dabei aber auch zum Thema geworden.

Die Anwendung, um die es geht, ist in FE-BE aufgeteilt, wird aber nur von einem FE bedient, Mehrbenutzer sind somit ausgeschlossen.

Ich hab in der Vergangenheit schon mal mittels des Application-Objektes ein Backup realisiert. Risiken, wie in #2 erwähnt, hab ich keine gesehen. Ich überlege, diese Variante wieder zu verwenden, unter Verwendung eines versteckten Forms oder aber eine Hilfs-DB zu erstellen, die vor dem Backup prüft, ob die fragliche DB geöffnet ist und wenn nein, die Backups vornimmt. Dies Anwendung könnte ich über geplante Tasks und Batchdatei aufrufen

 

So etwas kommt dann "plötzlich" und "überraschend".

Ich würde auch nichts davon halten, dass ein Frontend sich selber sichert und somit dabei offen sein muss.
Ausnahme: Externe Sicherung per SaveAsText
Als große Lösung gibt es da Versionenverwaltungen, siehe mal bei Josef auf der Homepage nach, auch in aufgezeichneten virtuellen Stammtischen (als angemeldetes Mitglied).
Eine kleine Lösung wäre, dass man zum Start ein VBS-Script ausführt, das erst das Frontend kopiert und es danach startet. Hast Du bei intensiver Entwicklung das Bedürfnis zu sichern, müsste die DB einfach heruntergefahren und über das Script neu gestartet werden. Schließen und Neustarten erzeugt einen definierten (wiederholbaren) Zustand, inklusive des Komprimierens (wenn gewünscht). Im laufenden Betrieb kann man es durchaus mit besonderen Zuständen zu tun bekommen.
Bei eigener strukturierter Arbeit könnte man das aber auch per Hand erledigen.

 

da liegt ja mein problem, bin halt ein bissel chaotisch *entsetzt *entsetzt *entsetzt

 

Ich habe hier ein Update/Start-Script vorgestellt...

 

Guten Morgen...

Ich hab mich jetzt mal etwas über VB-Script informiert. Basiert auf VB..
@Benny.. wie passen da PHP und PowerShell hinein? Ich bin da noch völlig unbedarft.

 

Hallo Benny....

ich hab mich jetzt mal mit der Thematik befasst, was VBScript ist, hab mir nen Editor im Netz gezogen(Wordpad war mir nix) hab auch schon ein wenig experimentiert(teilerfolgreich)

Bin Deinen Code mal durchgegangen der ja soweit klar ist, Mir ist nur die Zuordnung der Variablen nicht wirklich klar. Hab mir mal erlaubt, Deinen Code zu zitieren und meine Fragen da rein zu setzen:

'Variablen füllen
strProgPath = "\\Server\Freigabe\Anwendungsordner\"
strNetFEPath = strProgPath & "FrontEnd"
strFEPath = WSHEnv("APPDATA") & "Anwendungsordner"
strProgName = "Anwendung.mde"
Welche Variable beinhaltet hier was???
strVersion = "2.3"
Warum eine scheinbar starre Versionsnummer?
strVerFile = "version.log"
Was beinhaltet diese Datei und wie wird sie erstellt???
strIcoFile = "Anwendung.ico"

Wäre schön, wenn Du meinen Horizont ein wenig erweitern würdest! *Smilie *Smilie *Smilie

 

Hast Du Dir den Thread durchgelesen in dem ich das Script gepostet habe? Da werden die Thema u.a. auch behandelt.

Hier eine kurze Erläuterung
Zur Frage "Welche Variable beinhaltet hier was???"
Wie soll ich das verstehen? Die Variablen werden doch oberhalb befüllt; daraus ergibt sich deren Inhalt.
strProgPath = Pfad zur Datei auf dem Server ohne die Datei selbst (z.B. \\DeinServer\DeineFreigabe\DeinApplikationsordner)
strNetFEPath = Pfad zur gesamten Datei auf dem Server (FrontEnd steht hier für den Namen der Datei die kopiert werden soll)
strFEPath = Der Zielordner in dem die Anwendung auf dem Client liegt (z.B. C:\DeineApplikation)
strProgName = Der Name der Datenbankanwendung
Die "starre" Version ist die aktuell gültige Version (das Script liegt ja auf dem Server) der Anwendung. Gegen diese wird beim Ausführen des Script verglichen.
Die Datei version.log wird beim kopieren von Server -> Client mit kopiert und liegt somit auf dem Client.
Mit dieser Version wird verglichen und ggf. kopiert.

Beispiel:
Du erstellst Version 1.0 Deiner Anwendung. Publizierst sie auf dem Server, schreibst in die version.log 1.0 und in die obige Variable ebenfalls 1.0

Jetzt kommt der erste Client daher, ruft das Script auf, stellt fest ich hab noch nix und kopiert alles und startet die DB.

Morgen erstellst Du die Version 1.1 Deiner Anwendung und publizierst auf dem Server (wieder version.log auf 1.1 und die interne Version des Scripts auf 1.1 ändern)

Jetzt ruft der Client erneut das Script auf und stellt fest:
Script.Version = 1.1
Version in der lokalen (am Client!) version.log = 1.0
-> Ich muss kopieren

Anwendungs.ico ist lediglich das Anwendungssymbol welches ich mit kopiere.

Klar soweit?

 

Ich hatte eher den Eindruck, dass ein Sichern der eigenen Entwicklungsarbeit per Backup gewünscht war.