Office: (Office 2003) TXT-Datei automatisiert importieren

Dann hoffen wir mal, das er genug Papier im Drucker hat *wink.gif*

Die Funktion zum einlesen sollte nicht innerhalb sondern ausserhalb der Prozedur platziert werden!
Die Nachfragen bei den Aktionsabfragen kannst Du mit SetWarnings "umgehen".
Ich persönliche halte das aber für eine "dreckige" Lösung; eleganter und sauberer ist es m.E. das ganze z.B. per CurrentDB.Execute (bzw. CurrentDbC.Execute) auszuführen...

Hier der angepasste Code
Code:

 

Super, vielen Dank.
Das hilft mir sehr weiter!

Wie würde die "saubere Lösung" aussehen?
So?

CurrentDB.Execute "UPLOAD_TXT_Löschabfrage"
CurrentDbC.Execute "UPLOAD_TXT_Anfügeabfrage"

Code:

Wieso das C bei CurrentDbC?

 

per CurrentDB.Execute kannst Du die Abfrage selbst nicht ausführen; hier müsste das entsprechende SQL-Statement ermittelt werden (z.B. aus der gespeicherten Abfrage, etc.)
Hilfe dazu findest Du in der OnlineHilfe (Cursor auf CurrentDB und F1)

CurrentDbC ist eine Variante zu CurrentDB; Infos hierzu findest Du über die Forumssuche.

 

Meinst du das so?

Code:

Wie lasse ich nach ausführen der IF Funktion das aktuelle Datum in der Tabelle eintragen? Ich müsste doch das alte Datum immer überschreiben oder?

 

Bei der Datenmenge wird ein regelmäßiges Komprimieren erforderlich, auch schon durch das Löschen und Neuanlegen der Datensätze.
Daher wäre vermutlich die Verwendung eines zusätzlichen Backends für genau diese Tabelle sinnvoll, um den eigentlichen Tabellen diese Bewegungsspielchen zu ersparen.

Dann würde sich folgender Ablauf ergeben:
1) Löschabfrage zum Leeren der verknüpften Tabelle
2) Löschen der Verknüpfung der Tabelle
3) Komprimieren dieses Backends
4) Neusetzen der Verknüpfung zur Tabelle
5) Anfügeabfrage

Vielleicht würde es genügen, in einem zusätzlichen Feld der Zieltabelle den Importzeitpunkt zu hinterlegen. Dann könnte man eine Abfrage im Sinne von "wurde heute schon importiert" verwenden.

Dazu hätte ich aber noch einmal eine Rückfrage:
Löschen und Neuanlegen klingt einfach, ist aber datenmäßig ein erheblicher Aufwand mit Auswirkungen auf benötigte Zeit und Datenbankaufblähung.

Vermutlich werden die Änderungen in der Textdatei nicht so massiv sein. Dann könnte man über Abfragen
- bestehende Datensätze aktualisieren,
- nur neue Datensätze einfügen und
- ggf. überflüssige Datensätze löschen bzw. für diese eine Löschmarkierung setzen.
Das wären dann 2-3 Abfragen gegenüber 2 Abfragen, deutlich weniger bewegte Daten und deutlich geringere Auswirkungen auf das Datenbankaufblähen.

 

Die Tabelle in ein zusätzliches BackEnd zu verlagern halte ich grundsätzlich für gut. Verstehe allerdings deinen Ablauf 1-5 nicht ganz. Wieso "Löschen der Verknüpfung der Tabelle"?

Dafür habe ich eine extra Tabelle mit nur einem Feld (Datum) angelegt.

Die bestehenden Datensätze zu aktualisieren halte ich nicht für so gut. Es ändern sich sicherlich nicht täglich alle Daten, aber ich habe wenig vertrauen das Access diese Aufgabe auf Dauer problemlos ausführt. Ist aber sicherlich ein Versuch wert.

Mir fällt gerade noch etwas ein. Wenn man nach der Löschabfrage die Datenbank komprimiert, das müsste doch schneller gehen, als wenn man die Komprimierung erst nach der anschließenden Anfügeabfrage ausführt. Oder?

 

Mal zur Begrifflichkeit, da ich glaube dass hier noch Unklarheiten herrschen.
Eine Löschabfrage löscht keine Tabelle sondern deren Inhalte
Eine Anfügeabfrage fügt keine Tabelle sondern Inhalte an die Tabelle an
Eine Aktualisierungsabfrage aktualisiert nicht die Tabelle selbst sondern deren Inhalt

Klar soweit?
Somit sollte eine Löschabfrage für die Tabelle so aussehen:
DELETE * FROM TableX
Unabhängig davon wo die Tabelle ist.

@Eberhard: Das auslagern der Tabelle in ein eigenes BackEnd finde ich natürlich optimal; wollte hier nur erstmal bei der ursprünglichen Thematik bleiben *wink.gif*

 

Primär geht es darum, dass beim Komprimieren ein Zugriff auf die Tabellen dieses Backends ausgeschlossen ist, also weder über DLookups, Recordsets, gebundene Formulare o.ä.
Man könnte auch ein Startformular verwenden, das völlig ungebunden ist.

//Edit:
Die Problematik des Verknüpfens und des Löschens der Verknüpfung hast Du evtl. auch beim eigentlichen Import:
- Wird die Textdatei per TransferText acImport temporär importiert und per Anfügeabfrage in die Zieltabelle überführt, erzeugt man Temp-Müll.
- Wird die Textdatei per TransferText acLink verknüpft, hat man das Verknüpfungsproblem.
- Daneben könnte man direkt aus der Texttabelle importieren, siehe Acc2003 - Textfile importieren

Da kommt es weniger auf Access und viel mehr auf die Qualität des Entwicklers und seiner Anweisungen an - und auch davon, dass die Struktur der Textdatei gleich bleibt. Letzteres ist aber auch für die Anfügeabfrage über alles wichtig.
Wichtig wäre natürlich, dass es Schlüssel gibt, über die man entscheiden kann, ob ein Datensatz vorhanden oder neu ist.

 

Ich werde den bisher entwickelten Code erstmal einfügen. Wenn es läuft und die Entwicklung der Datenbank weiter fortgeschritten ist und ich mehr Zeit habe, dann werde ich mich mit der Thematik weiter auseinandersetzen.

Könnt Ihr mir bitte noch sagen, wie ich den Code erweitern kann, dass nach ausführen der IF Funktion das aktuelle Datum in der Tabelle eingetragen wird? Ich müsste doch das alte Datum immer überschreiben oder?
Zudem würde ich gerne die Funktion um eine 2. Bedingung erweitern.
Als weiteres AND Bedingung, dass die Txt-Datei min 40 MB groß sein muss, damit die IF-Funktion ausgeführt wird. Wie mache ich das?

 

Man kann auch das neue Datum als neuen Datensatz anfügen und dort per DMax identifizieren. Somit hätte man eine Importhistorie, vielleicht auch mal nützlich.

Code:

 

Klasse! Vielen vielen Dank!

Mir schwebt nun noch vor nach dem Einfügen des Datums die Datenbank zu komprimieren. Auf Dauer möchte ich alle Tabellen in ein BackEnd packen und nur diese zu komprimieren.

Ich habe mal gesucht und folgendes gefunden:
Code:

Ist es erfoderlich eine weitere IF Funktion zu erstellen, ob das Einlesen erfolgreich war? Ansonsten würde ich die Eingabe des Datums als letzten in der bestehenden IF-Funktion erledigen lassen.

Hierbei handelt es sich wahrscheinlich um Meldungen der Datumsangaben falls ein Fehler aufgetreten ist. Muss ich dafür lediglich das ' entfernen?

 

Backend komprimieren siehe crea-CompSave. Im Frontend gibt es wenig zum Komprimieren. Dies Komprimieren kann man über die Optionseinstellung "Beim Schließen komprimieren" erledigen lassen oder besser das Frontend durch ein sauberes Frontend (z.B. über einen Frontend-Updater) ersetzen lassen.

Jein. Der Datumseintrag in der Tabelle tblUpdate ist nur sinnvoll, wenn vorher die Abfragen sauber durchgelaufen sind. Eine Prüfung ist aber einfachst einzubauen:
Code:

Nein, das sind Angaben der Textdatei und hier nur ergänzt, weil oben mal die Rede vom Auslesen des Erstellungsdatums der Datei war und hier sowieso das FileSystemObject in Benutzung ist. Allerdings nutzen die Meldungen so nichts.

 

Ein abschließendes vielen Dank.
Ihr seid spitze!!!!!

 

Hallo zusammen,

der Code funktioniert ohne Probleme.
Nun möchte ich gerne noch einen Schritt weitergehen.
Ich habe die Datenbank in ein FrontEnd und BackEnd aufgeteilt.
Nun stelle ich mir vor, dass immer bei dem ersten Aufruf in einem Monat eine Sicherung der FrontEnd und BackEnd erstellt wird. Ich habe schon ein wenig recherchiert, allerdings nichts brauchbares gefunden.
Könnt Ihr mir helfen wie ich das umsetzen kann und worauf ich achten muss?
Danke im voraus.
killepitsch

Pfad der FrontEnd: \\abc\def\
Pfad der BackEnd: \\abc\def\Sicherung
Die Sicherungen der beiden Dateien sollen in folgendem Ordner geschehen:
\\abc\def\Sicherung\2011-01\
\\abc\def\Sicherung\2011-02\
Für jeden Monat soll ein Ordner angelegt werden \YYYY-MM\

 

Eine Frontend-Sicherung macht keinen Sinn. Ein Frontend kann man einfach mit einem einmalig gesicherten Original oder einem vorhandenen Setup/Update bei Bedarf ersetzen. Ein Update sollte an vorhandenen Daten nichts ändern und somit wiederholbar verwendbar sein. Ein Frontend ist Entwicklerarbeit - hier trägt dieser Verantwortung für die Bereitstellung.

Im Backend steckt die Arbeit des Datenbanknutzers und sollte aus dessen Sicht Schwerpunkt der Sicherung sein. Ob ein monatlicher Turnus der richtige ist - wer weiß. Wenn die Datenbank nur aller drei Monate angeworfen wird, ist der Turnus nicht einhaltbar. Wenn die Datenbank intensiv genutzt wird (5 Personen erfassen je täglich über 7 Stunden nur neue Daten), würde man vielleicht über eine halbtägliche Sicherung nachdenken.

Ich habe es für Einzelplatzlösung z.B. so umgesetzt, dass der User bei Schließen der Anwendung entscheiden kann, ob er sichern will oder nicht. Manchmal öffnet man eine Datenbank ja auch nur zum Nachschauen und Auswerten. Mit seiner Entscheidung zur Sicherung übernimmt der User die Verantwortung über seine Daten, die dann auch nicht mit dem Buttonklick endet. Sicherung auf eine (die gleiche?) Festplatte hilft noch nicht bei Festplattencrash, Diebstahl, Feuer u.ä. Risiken.

Bei der Anlage von Sicherungskopien braucht man auch Strategien,
- ob und wie man die Sicherung protokolliert,
- wieviele Kopien man anlegen möchte und was man mit überflüssigen macht,
- ob man packt oder verschlüsselt,
- ob man eine externe Lagerung (Webserver, Zentrale) organisieren will/kann u.ä.