Office: (Office 2010) Textdatei zeilenweise einlesen

Hallo zusammen,

ich habe eine Textdatei Test.txt die folgendermassen aussieht:

#1 Name;Vorname;Text1;Text2;Datum;Code;
#2 Mustermann;Anna;;Test;16.09.2012;AV2-G;
#3 Mustermann;Max;;;;AV3-G;
.
.
.

Ich habe ebenfalls eine Tabelle tbl_Test in Access angelegt, mit den Feldern:

Name
Vorname
Text1
Text2
Datum
Code

Nun zum automatisierten Import von Textdateien per TransferText weiß ich bescheid und bekomme das auch geregelt mit Importspezifikation etc.

Allerdings würde ich gerne mal einen anderen Weg gehen und die Textdatei zeilenweise importieren.

Dim strText As String

Open "C:\Test.txt" For Input As #1
Do While Not EOF(1)
Line Input #1, strText

So hier sollte nun wohl der Teil kommen, wo ich anfange die Zeile in Felder zu splitten. Also:

strText = Split(Instr(strText, ";")

Ich werde wohl auch noch einen Recordset erstellen müssen mit der Tabelle um dann noch per rs.addnew die daten anzufügen an meine Accesstabelle... nur wie stelle ich das an, das die gesplitten Felder der Textdatei nun im zugehörigen Tabellenfeld landen, das mit einem .addnew und .update und das für alle Zeilen in der Textdatei?

Loop
Close #1

Bin für jeden Hinweis dankbar *biggrin.gif*

:)

 

Moin Sebastian.
Willkommen im Forum.

Zuallererst solltest Du Dir angewöhnen, den Code in Tags zu verpacken, damit man ihn besser lesen kann.
Dann solltest Du Dir die Syntax der Funktion Split() in der OnlineHilfe zu Gemüte ziehen. Es braucht erstens nicht den Einsatz der Funktion Instr() und zweitens ist es nicht förderlich, die Stringvariable strText mit dem Aufruf der Split() Funktion zu überschreiben. Das kannst Du nämlich nur einmal machen ;-)
Für die Speicherung des Ergebnisses von Split() braucht es weiterhin keine "normale" Variable, sondern ein Array.
Das könnte dann so aussehen (ungetestet): Code:

Selbstverständliche Voraussetzung ist, dass "deine_tabelle" die passende Anzahl Felder beinhaltet ...

 

Dir ist aber schon bewusst, dass ein Import per SQL/Standardimport der schnellste Weg ist?

Massendatenverarbeitung schlägt prozedurale Einzelverarbeitung.

 

\@Eberhard: Sebastian hat uns ja nicht verraten, warum er mal einen anderen Weg gehen will. Kommt es denn immer nur auf Geschwindigkeit an? Ein Ansatz könnte ja sein, sich die einzelnen Felder und ihre Werte beim Import genau betrachten zu wollen um sie ggf. zu manipulieren? Unter diesem Gesichtspunkt schlägt die prozedurale Einzelverarbeitung den Massenimport.

 

Wertmanipulationen und einiges mehr sind auch im Rahmen einer Abfrage möglich, beim Betrachten bleibt der Import stehen.

Nein, Ausführbarkeit und Fehlerfreiheit sind noch wichtiger. Dann aber dürfte schon der Aspekt der Performance kommen, vor allem weil man im Zusammenhang mit Datenbanken schnell von größeren Datenmengen ausgehen kann, deren Verarbeitung dann ihrerseits Zeit kostet. Ein Import könnte sich zusätzlich so darstellen, dass nicht nur ein pures Anfügen erfolgt, sondern z.B. nur neue Datensätze anzufügen wären und/oder vorhandene Daten zu aktualisieren wären. Dann erweitert man eine Einzelverarbeitung auch auf die Suche/Prüfung in der Zieltabelle.

Aber eigentlich wollte ich das Bewusstsein auf performante Methoden - das Du selber mit der Rückfrage bestätigst - für den Leser herausstellen. In Excel geht es vergleichsweise auch schneller, wenn man einen Bereich (Range) im Stück verarbeitet statt seiner einzelnen Zellen in Schleife, siehe Vorwort + Schleifen die keiner braucht.

Und da die meisten, die ein Auto, einen Fernseher, eine Brille oder eine Versicherung kaufen, immer prinzipiell das Beste, Günstigste usw. haben wollen, würde ich auch bei Datenbankaktionen nicht von Vornherein potentiell effektive Verfahren zur Seite legen, sondern erst bei Bedarf (wenn es zu schnell ist) eine Bremse einlegen. Das ist dann regelmäßig einfacher, als bei Bedarf die Performance anheben zu wollen.

Die Verbreiterung des eigenen Repertoires ist natürlich ein maßgeblicher Grund zur Beschäftigung mit weiteren Methoden, schon weil diverse kreative Gestaltungen von Datenaustauschdateien einen Standardimport nicht zulassen. Hier sehe ich es als variablere Alternative zum zeilenweisen Lesen, dass man den Textdateiinhalt komplett in eine Stringvariable lädt und daraus verarbeitet. Hier hätte man einfacher die Möglichkeit, Informationen aus mehreren Zeilen zu einem Datensatz zusammenzufassen.

 

Hallo ihr beiden,

vielen Dank für die Hinweise. Werde ich morgen gleich mal testen.

@ebs:

Code:

und dann ein Insert per sql wäre sicherlich schneller. Allerdings gelang es mir hierbei bisher nur durch eine Koma getrennte Dateien zu Verarbeiten, nicht durch ein Semikolon. Liegt aber vielleicht auch daran das ich mich mit den anderen Methoden außer TransferText etc. erst jetzt beschäftige.

Ich möchte einfach auch die anderen Methoden kennen und sie mir zu eigen machen, denn man kann nie wissen wozu man diese braucht.

LG
Sebastian

 

In den Leerraum zwischen den beiden Semikolons bei den Verbindungsdaten kann man den Namen einer erstellten Importspezifikation einsetzen und dann analog zu TransferText arbeiten. Mit einer Importspezifikation kann man auf verschiedene Trennzeichen oder Trennungen (feste Längen) reagieren, Datentypen und Formate von Werten definieren u.ä.

 

Also im Prinzip das gleiche wie bei der Methode TransferText... sind wohl dann die gleichen Spezifikationen auf die man da zurück greift, richtig? Ich finde das es mit den Spezifikationen nur den Nachteil hat, das man dies für jede Datenbank entweder exportieren/importieren muss oder diese immer neu anlegen muss.

 

Ja genau.
Die Spezifikationen sind in zwei Systemtabellen definiert, vergleiche Importspezifikation einer DB in VB erstellen. In Access gibt es dann einen zusätzlichen Assistenten, der einem ein einfaches händisches Anlegen bzw. Editieren ermöglicht.

 

\@Eberhard: Der Link mit dem Code zum Erstellen einer Importspezifikation hatte mir noch gefehlt. Danke.
Gibt es eigentlich eine Möglichkeit eine bestehende Spezifikation zu ändern?
Ich meine: ohne den Importassistenten komplett aufzurufen, Datei auswählen usw ...

 

Nun, wenn man die Tabellen selber per Anweisung erstellen kann sowie auch Inhalte eintragen kann, sollte man auch Inhalte ändern können, und das im Normalfall wie üblich in einer Datenbank per Abfrage oder Recordsetanweisung.
Praktisch habe ich das aber noch nicht ausprobiert.

Wenn man den obigen Gedanken ausbaut, sollte man auch ganze Spezifikationen, also Datensätze, in eine andere Datenbank übertragen können bzw. die ganzen Tabellen.
Im Normalfall kopiert man aber das ganze Frontend, dass die Spezifikationen inkl. dieser Systemtabellen enthält.