PDA

Vollständige Version anzeigen : Datensicherung


Pragmat
19.01.2003, 15:36
Habe z. ZT. Windows 98 und Access 2000 im Einsatz.
Es soll eine komplette externe Datenbank kopiert, bzw. gesichert werden.

Dies habe ich dadurch erreicht, daß ich auf der DOS-Ebene eine kleine bat.-Datei mit dem Copy-Befehl geschrieben habe: "copy C:\windows\desktop\datei.mdb f:\". Diese bat.-Datei habe ich über call shell eingebunden.

Es funktioniert auch problemlos: Die Datenbank wird komplett auf das Bandlaufwerk übertragen/gesichert.

Meine Befürchtung ist jetzt:

1. Funktioniert das Ganze auch mit der DOS-Ebene von XP (sofern dort überhaupt eine vorhanden ist) und

2. Geht es vielleicht auch etwas eleganter??


Gruß
Pragmat

Erich Weiss
19.01.2003, 15:54
Hallo Pragmat,

unter tatkräftiger Mithilfe dieses Forums ist es mir gelungen, zu einer Sicherungslösung von Access zu kommen.

Bei dieser Lösung handelt es sich um vba-Code, der als Modul eingegeben wird.
Dieses Modul kann dann, ausgelöst durch irgendwelche Aktionen in Access (z.B. schließen eines Formulares) aktiviert werden.

Es führt dann automatisch eine komplette Sicherung der db auf dem im Modul festgelegten Kaufwerk durch.

Bei der Variante die ich benutze fügt es automatisch Datum und Uhrzeit an den db-Namen an.

Meine db wird in einem Netzwerk mit mehreren Nutzern eingesetzt. Hier nutze ich dieses Modul z.B. dafür, daß beim Beenden von Access des einen Nutzers, auf seinem D: Laufwerk eine Kopie angelegt wird.
Hierdurch ist es dem Nutzer mölich, Veränderungen die nach seiner Arbeit vorgenommen wurden zu erkenn und evt zu verändern.

Ich werde jetzt versuchen dir diesen Code hier zu copieren.

Die Zeilen können in den Zwischenspeicher kopiert werden und dann im Modulbereich von Access eingefügt werden



Option Compare Database
Declare Function apiCopyFile Lib "kernel32" Alias "CopyFileA" (ByVal lpExistingFileName As String, ByVal lpNewFileName As String, ByVal bFailIfExists As Long) As Long
Option Explicit

Public Function neuesBackup()
Dim Result As Long
Result = apiCopyFile(CurrentDb.Name, "D:\erich_" & Format(Now(), "dd.mm.yyyy_hh-mm") & ".mdb", False)
End Function



Dieses Modul legt ein Backup auf dem Lw D: mit dem Namen.

Erich_28.04.2002_18-23.mdb


Es hat geklappt.

Viel Spass, mein Dank nocheinmal an alle die sich in diem Code wiedererkennen.

Gruß EW

Pragmat
19.01.2003, 16:17
Hallo Erich!

Funktioniert hervorragend (was bei Access nicht immer selbstverständlich ist).

Vielen Dank an Dich und alle, die daran mitgewirkt haben!

ein begeisterter
Pragmat

Gralle
19.01.2003, 18:57
Geht das Ganze auch mit nem UNC-Pfad statt ner Laufwerksbezeichnung ?
Habe leider keinen Plan von VBA !

schuldlos
19.01.2003, 21:56
Halloo

ich mach das Sichern mittels Filecopy

FileCopy Forms!Hauptformular!Backend_LW & "jour.mdb",
Forms!Hauptformular!Netz_LW & Forms!Hauptformular!A_LW & "jour.mdb"


allg. Form:

Filecopy Quellenpfad, Zielpfad

(beide Pfade sind strings)

in meinem Beispiel oben stelle ich Quelle und Ziel in einem Formular ein
das ganze geht auch übers Netz
Wichtig: die zu kopierende Datei muss allerdings geschlossen sein.



so ists bei mir

das sag völlig schuldlos :angel:

Mattes
20.01.2003, 08:06
:eek: Sorry Leute, ich muß mal ganz doof Fragen:

Wozu braucht man sowas? In einem Netz wird die Datenbank in FE und BE aufgeteilt und die Daten auf dem Fileserver in die Bandsicherung einbezogen.

Der Nutzen der hier vorgestellten Lösungen wird mir nicht klar. IMHO ist es doch nicht so vorteilhaft, wenn bei jedem Schließen der DB eine lokale Datei mit neuem namen erstellt wird, wenn ich das 10mal am Tag mit einer 300MB grossen DB mache...

Desweiteren ist der Laufwerkspfad fest im Code hinterlegt:
Result = apiCopyFile(CurrentDb.Name, "D:\erich_" & Format(Now(), "dd.mm.yyyy_hh-mm") & ".mdb", False)

was dazu führt das die DB nur auf Rechnern mit Laufwerk D läuft. Ist D z.B. das CD-Rom, muß ich im Modul herumfriemeln.

Laßt mich nicht dumm sterben...

Pragmat
20.01.2003, 11:37
Hallo Mattes!

So wie Du die Angelegenheit schilderst, gebe ich Dir Recht.
Doch angenommen es handelt sich um einen Kleinbetrieb mit einem minimalen Windows Netzwerk, sieht die Sache anders aus. Man kann auch auf die (in vielen Fällen sinnvolle) Datumserweiterung verzichten, dann ist das Bandlaufwerk nicht gleich voll.

Es läßt sich an der sehr guten Function von Erich auch noch etwas herumfriemeln: So habe ich eine Tabelle/Formular, wo nur die grundsätzlichen Daten für die Datenbank hinterlegt sind. Hier kann eine Eingabe für die Pfadangabe des Bandlaufwerks gemacht werden.

Die Function kann dann so aussehen:

Option Compare Database
Declare Function apiCopyFile Lib "kernel32" Alias "CopyFileA" (ByVal lpExistingFileName As String, ByVal lpNewFileName As String, ByVal bFailIfExists As Long) As Long
Option Explicit

Public Function neuesBackup()
Dim Result As Long
Dim LW As String

LW = DFirst("[pfad]", "grund")
Result = apiCopyFile(CurrentDb.Name, LW, False)
End Function

Hier wird der Pfad aus der Tabelle "grund" vom ersten Datensatz geholt. Die Bezeichnung für das Textfeld, in dem der Pfad eingetragen wird, heißt "Pfad".

Jetzt muß ich noch sehen, wie erkannt wird, daß ein Band eingelegt ist. Dann ist die Sache fast perfekt.

Gruß
Pragmat

Mattes
20.01.2003, 12:29
:eek: :eek: :eek:

ALso jetz versteh ich gar nichts mehr :stupid:


Du hast einen Kleinbetrieb mit Netzwerk. Du hast ein Bandlaufwerk. Du hast eine Datenbank.

Warum sicherst Du die Datenbank nicht einfach mit dem Bandlaufwerk? Voll wird das Band nicht, denn Du sicherst jeden Tag und überschreibst dabei die alte Version. Natürlich nimmst Du mindestens 5 Bänder, für jeden Tag der Woche eins. D.h Du kannst die daten bis zu einer Woche zurück wiederherstellen.

Versuch mir doch mal zu erklären warum Du eine Tabelle mit Pfaden füllst und per VBA prüfen willst ob ein Band eingelegt ist :confused:


Das was Du da vorhast kannst Du ganz simpel mit einer Batch Datei per geplanten Task erledigen.

Pragmat
20.01.2003, 12:50
Hallo Mattes!

Die Datenbank ist für einen blutigen Computerlaien. Er soll nur auf ein Knöpfchen drücken (vorher natürlich das Band einlegen) und die Sicherungskopie ist erstellt.
Dieser Mensch soll nicht mit diversen Sicherungsprogrammen überfordert werden.

Die Tabelle mit den grundsätzlichen Daten hat nur einen ersten Datensatz, insofern wird nicht viel Platz für den Pfad verschwendet.

Hoffe, daß Du die Angelegenheit jetzt nachvollziehen kannst.

Gruß
Pragmat

Mattes
20.01.2003, 14:05
Sorry, Nein.

Ist aber auch Egal, vielleicht halte ich mich daran zu sehr auf, aber wenn Du einen Rechner hast, der immer läuft und das mit der Sicherung vollautomatisch geht dann ist das der sicherste Weg, GERADE für einen Laien.

Ist aber ja auch egal wenn Du mit den Dir angebotenen Lösungen zurecht kommst, ich wollte halt nur noch mal zu denken geben.

Frohes Schaffen.....

Laui
20.01.2003, 14:45
Hi,

möchte mich mal ein wenig in Eure Diskusion einklinken.

Grundsätzlich sehe ich Die Datensicherung so wie Mattes. Was ist aber, wenn der Server kein Raid hat und Dir die Platte kurzvor Feierabend absemmelt. Gut, die Daten vom Vortag hat man auf Band, aber die aktuellen Änderungen??

Für kleine DB's also sinnvoll zusätzlich zu sichern.

Für große DB's könnte man ja nur die Daten sichern, die am heutigen Tag geändert bzw. eingegeben wurden.

Das kann ggf. ne Menge Tipparbeit sparen.

Sascha Trowitzsch
20.01.2003, 15:41
@Laui: Soll das heißen, dass der User alle 10 min aufs Sichern-Knöpfchen drücken soll?

Wenn die Daten so wichtig sind, dann sollte die Anschaffung eines hardwaremäßig sicheren Servers heutzutage kein großer Aufwand sein.

Zum Spaß kann man natürlich trotzdem aufs lokale Laufwerk kopieren.
Dann kann man im Notfall evtl. unabhängig vom Server weiterarbeiten.

Ciao, Sascha

Mattes
20.01.2003, 15:57
Na jetzt muß ich auch nochmal:


Nachteile der hier vorgestellten Lösungen:

Der Nutzen der hier vorgestellten Lösungen wird mir nicht klar. IMHO ist es doch nicht so vorteilhaft, wenn bei jedem Schließen der DB eine lokale Datei mit neuem namen erstellt wird, wenn ich das 10mal am Tag mit einer 300MB grossen DB mache...

und:

was dazu führt das die DB nur auf Rechnern mit Laufwerk D läuft. Ist D z.B. das CD-Rom, muß ich im Modul herumfriemeln.


Vorteile:

IMHO KEINE!


Es ist ein Bandlaufwerk und ein Netzwerk vorhanden!

Selbst Argumente die in Richtung Kostenersparnis oder Investitionsaufwand gehen kann man hier nicht gelten lassen.

@Laui:

Wenn ein Netz vorhanden ist gehe ich mal von einem "großen Betriebssystem" aus, also NT4, W2K oder XP, ob als WS oder Server.

Diese können eine Platte per Software spiegeln, und könnten sogar Raid 10! Eine IDE Platte um die 20 G kostet um die 70€. Also hier dürfte es keine Probleme geben.


Als Denkansatz möchte ich nochmal den Laien zitieren. Gerade hier ist es sehr anfällig wenn Du mehrere lokale Kopien hast. Was wenn der DAU aus Versehen eine DB öffnet die von vorgestern ist wo halt noch die alte Bankverbindung vom Kunden....


Neee, also eine Datensicherung, unabhängig von der Betriebsgrösse sollte vollautomatisch über ein Bandlaufwerk stattfinden. Art und Umfang ist natürlich variabel, aber alle anderen Lösungen rächen sich. ...früher oder später.....

Laui
20.01.2003, 16:38
@Sascha

Ne, er soll natürlich nicht alle 10 min. auf's Knöpfchen drücken. Man kann so eine Sicherung ja auch beim Beenden der Datenbank starten (oder auf welchem Ereignis auch immer).

Ich hatte oben auch schon geschrieben, dass grundsätzlich das Band das Richtige Medium ist. Bei mir läuft die Sicherung auch jede Nacht.

Was aber, wenn sich das Backend zerlegt. Die Spiegelung nützt das garnichts und die Daten vom Vortag sind ein paar Stunden zu alt.

Warum also nicht die aktuellen Daten vom heutigen Tag extra sichern???
Macht der SQL-Server IMO doch auch, oder??

Pragmat
20.01.2003, 16:40
Um nochmal von der Grundsatzdiskussion abzulenken:

Diese Funktion habe ich bei http://www.dr-bytes.de gefunden

Function FileExists(str_fname As String) As Boolean
Dim str_FileName As String
str_FileName = Dir(str_fname)
If str_FileName <> "" Then FileExists = True _
Else: FileExists = False
End Function

Das Ganze wird dann mit der o. a. Function und der Function "neuesbackup" von Erich in einer Ereignisprozedur zusammengefaßt:

Private Sub Befehl66_Click()

On Error GoTo Zeile1
Dim LL As String
LL = Left(DFirst("[pfad]", "grund"), 3)

Dim str_FileName As String
str_FileName = LL
If FileExists(str_FileName) = True Then GoTo Zeile2 Else GoTo Zeile1

Zeile1:
MsgBox "Bitte zur Datensicherung Band einlegen. Daten konnten nicht gesichert werden"
Exit Sub

Zeile2:
neuesbackup
MsgBox "Daten werden gesichert"

Exit Sub
End Sub

LL liefert z. B. "F:\"

Wenn das Laufwerk im Netz nicht gefunden wird, wird ein Laufzeitfehler provoziert (wir mit ON ERROR abgefangen). Am eigenen Computer ist das Ergebnis dann false.

So ist jetzt auch eine Auswertung möglich, ob Band eingelegt ist oder nicht.

Ralf222
30.01.2003, 11:11
Habt Ihr eigentlich auch mal bedacht das selbst in Großen Firmen wo zig Server nebst ordentlicher Bandsicherung vorhanden sind diese Funktion sinnvoll sein kann.
Bei werden die übergeordneten Admin Aufgaben von einer externen Firma gemacht. Wenn ich da auf eine Sicherung zurückgreifen will kann das schon mal bis zu 4 Werktage dauern.
Und bei einem solchen anfälligen Programm wie Access ist das kann schön stressig.
Also ich bin Froh das ich jeden Tag eine Sicherung auf der lokalen Festplatte hab und das im Rytmus für jeden Wochentag so kann man immer schnell auf eine Sicherung zurückgreifen und weiterarbeiten.

Schefti
30.01.2003, 11:34
Nur weil etwas falsch ist, wird etwas Falsches nicht richtig.

Hier liegt das Problem ja wohl bei der ext. Firma.

Tja, wer outsourct muß halt mit den Folgen leben.
Schade eigentlich, das es immer wieder Leute gibt, die solche Entscheidungen mit unnötiger Arbeit tragfähig machen.

Nur eine allg. Meinung zur IT-Landschaft;-)

gruß

Mattes
30.01.2003, 11:35
:entsetzt: ... und hat ggf. danach redundante oder inkonsitente Daten! Nein! Einzige vernünftige Möglichkeit ist eine zentrale Sicherung.

Ralf222
30.01.2003, 11:39
An Schefty
die Situatíon ist nun mal so, und ich hab das beste draus gemacht. Prinzipiel hast du natürlich Recht mit dem outsourcing aber diese Entscheidungen werden nur mit dem Geldbeutel gemacht und nicht mit dem Hirn.

an Mattes
die Backend zerschießt es ja nicht sondern nur die Frontend und somit fahre ich meine Sicherung hauptsächlich für die FE womit dieser Grund außen vor ist.

erwin
30.01.2003, 11:52
gegen "zerschossene" FE's gibt's doch als "Banalmittel" einen kleinen Batch, der jeweils von einem zentralen Share bei Aufruf der DB oder beim Login das dort liegende jungfräuliche FE auf ein lokales LW kopiert und dann startet. Läuft bei allen meinen Kunden so und "zerschossene" FE's gibt's damit eigentlich so gut wie nie.

so long Erwin...

Ralf222
30.01.2003, 12:20
Ja meinen Mitarbeitern passiert ja auch nichts, das sind nur Anwender und da gab es noch nie probleme. Aber bei mir dann doch schon öfter Ist man im VBA Code und irgendetwas läuft beim Testen instabil. Kommt anschließend die Fehlermeldung Netzwerkfehler..... welches ja ein bekannter Bug ist steht man ohne Sicherung der FE im Regen.
Mag ja auch sein das es elegantere Lösungen gibt aber diese Lösung wie ich sie praktiziere ist für mich tauglich.
Nichts destotrotz kannst Du mir ja mal die Batch zusenden.

Tschüß und Danke für heute muß zum Zahnartzt. :confused:

Labonga
14.02.2003, 09:05
Original geschrieben von erwin
... gibt's doch als "Banalmittel" einen kleinen Batch, der jeweils von einem zentralen Share bei Aufruf der DB oder beim Login das dort liegende jungfräuliche FE auf ein lokales LW kopiert und dann startet....

Das klingt gut, logisch und sicher und ich würd's auch gern mal probieren. Das mit dem kopieren bekomme ich zwar noch hin, aber irgendwie hängt's dann bei mir mit dem automatischen Start. Kannst Du mir vielleicht einen Tip geben, wie der Batch aussehen müsste?

Ralf222
14.02.2003, 09:10
Erwin hat mir leider bis jetzt nicht den Batch zukommen lassen. Also kann Ich dazu auch nichts sagen.

Gruß Ralf

Mattes
14.02.2003, 11:23
Hi Zusammen,

ich tippe mal "mit ner kleinen Batch" hat der Erwin eine einfache bat Datei gemeint ;)

z.B.

xcopy /E /Y C:\Programme\Benutzer\test.txt H:\Backup

Dies in eine Textdatei und dann umbenenen in*.bat.

Wenn ein Netzwerkbetriebssystem installiert ist besteht die Möglichkeit im Benutzerprofil ein Logonscript zu hinterlegen. Dazu muß die Datei auf dem Server im Verzeichnis Netlogon liegen.

Obiger Code würde beim Anmelden z.B. die Datei test.txt vom Client auf das Netzlaufwerk H ins Verzeichnis Backup kopieren.

Mehr is dat nich! :D


HTH, Mattes

Labonga
14.02.2003, 11:32
Ja, ich weiß schon so in etwa was er meint. Mein Problem ist wohl eher gar keins. Ich kopiere eine frontend.mdb vom Netzlaufwerk auf den lokalen Rechner. G: ist dabei das Netzlaufwerk C. logischer Weise das lokale:

Dim fso, f1
Set fso = CreateObject ("Scripting.FileSystemObject")

Set f1 = fso.GetFile("G:\frontend.mdb")
f1.Copy ("C:\frontend.mdb")

...so steht es in einer *vbs-Datei. Alles was mir noch fehlt ist eigentlich nur noch - was muß ich nun der *vbs hinzufügen, daß die frisch kopierte Datei auch ´sofort geöffnet wird?

Mattes
14.02.2003, 13:27
hmmm, mit dem Scripting Host kenn ich mich nicht aus, kann aber nicht viel sein. Das weiß bestimmte jemand hier :D

Stema
14.02.2003, 16:32
Nur um mal eine weitere Möglichkeit einzuwerfen, wenn mit all dem genannten nicht zufrieden ist:

Man könnte die Access-interne Replikation als Backup nutzen, indem man auf einem 2. Server oder eine 2. Platte repliziert. Und das ist nun wirklich kein Riesen-Act.

Mattes
14.02.2003, 16:34
...würd mich mal interessieren. Kannst Du etwas ausführlicher die Replikation beschreiben? :)

Stema
14.02.2003, 17:00
Naja, was soll man dazu sagen?
Über Tools->Replications kann man eine Replikations-DB erstellen.

Mit folgendem Code kann man dann die aktuelle DB mit dem Replikat synchronisieren. Habe ich bisher nur mit A97 gemacht.

Sub SendChangeToReplicaX()

Dim dbsNorthwind As Database

' Opens the replicable database Northwind.mdb.
Set dbsNorthwind = OpenDatabase("Northwind.mdb")

' Sends data or structural changes to the replica.
dbsNorthwind.Synchronize "Nwreplica.mdb", _
dbRepExportChanges

dbsNorthwind.Close

End Sub

Wobei das natürlich auch mit der CurrentDb möglich ist. Und das Replikat dann - wie schon erwähnt - auf einem anderen Server speichern.
Man kann dann im Replikat auch definieren, welche Tabellen repliziert werden sollen.

Labonga
14.02.2003, 22:05
Also sicher wäre das auch eine Möglichkeit. Da aber in meiner betreffenden Datenbank reichlich Autowerte für z.B. Vertrags- u. Rechnungsnummernkreise verwendet werden, und diese zwingend erhalten bleiben müssen, scheidet der Weg über eine replizierte DB leider aus.

Ich wundere mich allerdings, daß bei so vielen VB-Experten hier im Forum als aber auch im sonstigen Web zwar die unglaublichsten Lösungen für die abstrusesten Problemstellungen zu finden sind, sowas dämlich einfaches wie ein Dateiaufruf in einem VBS aber nirgends beschrieben ist. Gebe ja zu, bin selber nicht annähernd so versiert, wie es meine Aufgaben mitunter erfordern würden, aber auch wenn das Problem schier banal erscheint, wäre ich sehr um einen Hinweis dankbar.

Gruß Martin

Sascha Trowitzsch
14.02.2003, 23:26
Ich glaube, hier im Thread ging es eher um die Frage, wie sinnvoll ein solches Backup ist. Das wurde von vielen bestritten, und deshalb hat es auch nicht entspr. Lösungen gehagelt.
Dateien Kopieren kann man mit verschiedensten Methoden, von denen ein Shellaufruf einer .bat bzw. .cmd eine Möglichkeit ist, Copy mit Scripting eine andere und CopyFile per API eine von mir bevorzugte. (Suche im VB-Bereich oder Access-Archiv benutzen.)

Die Geschichte mit der Replikation erscheint mir absurd, nur um ein Backup anzulegen. Sie macht die DB langsamer, komplizierter und fehleranfälliger.

Ciao, Sascha

jmc
15.02.2003, 15:55
@Martin / labonga

im vbs musst du zum Starten nur noch

Return = Shell.Run(ProgName, MaximizedFocus, True)

einfügen, wobei ProgName folgendes enthalten muss:
LW:\Pfad\msaccess.exe LW:\Pfad\deineFE.mdb

Falls im Pfad oder sonstwo Leerstellen enthalten sind, dann musst du es in Anführungszeichen setzen:

"LW:\Microsoft Programme\msaccess.exe" "LW:\Meine Anwendungen\deineFE.mdb"

alles klar ?

Labonga
15.02.2003, 16:17
Hmm.. ich habe es jetzt mal so eingegeben, wie Du es geschrieben hast. Sieht dann so aus:

Dim fso, f1
Set fso = CreateObject ("Scripting.FileSystemObject")

Set f1 = fso.GetFile("G:\EchoDat-Server\EchoDat 1.0\data\frontend_be.mdb")
f1.Copy ("F:\echodat.mdb")

Return = Shell.Run("F:\Programme\Microsoft Office\Office10\msaccess.exe" "F:\echodat.mdb", MaximizedFocus, True)


jetzt gibt's die Fehlermeldung:
Zeile: 7
Zeichen: 1
Fehler: Objekt erforderlich: 'Shell"
Code: 800A01A8
Quelle: Laufzeitfehler in Microsoft VBScript

hab ich was falsch verstanden?

jmc
15.02.2003, 16:34
Hallo Martin

sorry, die Shell-Objekt-Variable muss natürlich noch initialisiert werden, wie 'fso', also bei mir sieht es so aus :

' Shell und FileSystemObject initialisieren:
Set Shell = CreateObject("Wscript.Shell")
' FileSystemObject-Objekt instantiieren
Set fso = CreateObject("Scripting.FileSystemObject")

den Return kann nach dem Shell.Run kannst du noch abfragen, ob alles OK ist:
If Return <> 0 Then
fRun = False
strMsg = "Start oder Ausführung von " & vbCrLf
strMsg = strMsg & Progname & vbCrLf
strMsg = strMsg & "ist fehlgeschlagen!"
MsgBox strMsg, vbCritical, cMsgTit
End If

:top:

Labonga
15.02.2003, 16:51
Hihi.. also möglicherweise stelle ich mich wohl gerade super blöd an, aber jetzt sagt er, daß er die angegebene Datei nicht finden kann. Die ist aber genau da, wo sie laut Script sein sollte. ???


Dim fso, f1
Set fso = CreateObject ("Scripting.FileSystemObject")

Set f1 = fso.GetFile("G:\EchoDat-Server\EchoDat 1.0\data\echodat.mdb")
f1.Copy ("G:\EchoDat-Server\EchoDat 1.0\test.mdb")

Set Shell = CreateObject("Wscript.Shell")
Set fso = CreateObject ("Scripting.FileSystemObject")

Return = Shell.Run("F:\Programme\Microsoft Office\Office10\MSACCESS.EXE"
"G:\EchoDat-Server\EchoDat 1.0\test.mdb", MaximizedFocus, True)

jmc
15.02.2003, 17:11
Hi Martin

Ich vermute mal, dass es beim Shell.Run ist.
Schreib mal das ganze zuerst in eine Variable, also so:

ProgName = """F:\Programme\Microsoft Office\Office10\msaccess.exe"""
ProgName = ProgName & """ G:\EchoDat-Server\EchoDat 1.0\test.mdb"""
Return = Shell.Run(ProgName, MaximizedFocus, True)

Da in der Variablen Anführungszeichen sein müssen, müssen diese doppelt angegeben werden. Sieht etwas komisch aus, ist aber richtig so. Achtung auch auf das Leerzeichen in der zweiten Zeile vor G:\...


PS: bin jetzt weg für den Rest des Abends - Ausgang :grinange:

Labonga
16.02.2003, 10:04
Hallo Jean,

erst einmal vielen Dank bis hier her. Das hat schonmal prima weitergeholfen. Es gibt keine Fehlermeldung mehr und das Script scheint ausführbar. Eine Kopie wird im Zielverzeichnis erstellt, access wird gestartet und auch die neu erstellte mdb wird geöffnet (zu sehen an der ldb, die kurz drauf im Verzeichnis auftaucht.

Das einzige... es ist kein Fenster zu sehen. Muß das Script noch irgendwie beendet oder abgeschlossen werden? Im Taskmanager finde ich nach ausführen immer noch den Task WScript.exe. Oder kann das noch an etwas anderem liegen?

Gruß Martin

jmc
16.02.2003, 14:44
Hallo Martin

ich habe angenommen, dass du dich ein wenig mit VBScript beschäftigt hast ...
Ich denke es fehlt noch die Variable MaximizedFocus, somit wird dort der Wert 0 genommen, was 'Hide' bedeutet, also deine Access-Anwendung ist 'versteckt'. Das solltest du eigentlich auch im Task-Manager sehen (msaccess.exe). Definiere gleich am Anfang des Scripts noch:
Const MaximizedFocus = 3

Labonga
16.02.2003, 16:34
Hallo Jean,

beschäftigt schon, aber eben immer nur so am Rande. Gründliches einarbeiten schiebe ich schon ewig vor mir her. Es läuft nun so, wie es soll, Dank Deiner unermüdlichen Hilfe und Geduld. Vielen Dank nochmal. Für alle mit dem gleichen Problem hier noch mal der fertige Code:


Const MaximizedFocus = 3
Dim fso, f1
Set Shell = CreateObject("Wscript.Shell")
Set fso = CreateObject ("Scripting.FileSystemObject")

Set f1 = fso.GetFile("G:\EchoDat-Server\EchoDat 1.0\frontend.mdb")
f1.Copy ("C:\Programme\echodat\test.mdb")

ProgName = """F:\Programme\Microsoft Office\Office10\msaccess.exe"""
ProgName = ProgName & """C:\Programme\echodat\test.mdb"""
Return = Shell.Run(ProgName, MaximizedFocus, True)