Teile einer CSV Datei in Access Formular einfügen

ebs17 · Juli 01, 2016, 17:16:33

Vielleicht auch: Import Excel-Tabelle mit mehr als 255 Spalten

DF6GL · Juli 01, 2016, 17:23:05

Hallo,

zunächst würde ich die CSV-Daten analysieren und definieren, welche von den Feldern zu welchen (späteren ) Tabellen gehören müssen (--> Beachten der Normalisierungsregeln). Sodann zeilenweises Einlesen der Datei (mit Line Input, gibt aber auch andere Möglichkeiten) und Aufdröseln der Felder in ein Array (Split-Funktion) oder (vielleicht sogar besser, da anstelle eines Index-Wertes beliebige Namen verwendet werden können,) eine Collection-Auflistung.

Mit Hilfe von Recordsets (fände ich hier günstiger als direkte Anfüge-SQL-Strings, wobei eine reine SQL-Lösung auch denkbar wäre) die Collection-Elemente in die jeweiligen Tabellen (,die vorher zu erstellen sind und alle ein Autowert-ID-Feld und die restlichen Felder mit den korrekten Datentypen) haben müssen) schreiben/anfügen. Dabei kann auch der jeweilige Primärschlüssel-Wert "berechnet" und für die Fremdschlüsselfelder in anderen Tabellen (entspr. der Normalisierung) während deren "Befüllung" benutzt werden.

Das wäre meine Vorgehensweise .

Einiges könnte auch mit DDL abgedeckt werden, z. B. die Erstellung der Tabellen. Ob das im vorliegenden Fall von (zeitlichen) Vorteil wäre, kann ich so nicht beurteilen. Sinnvoll wäre es aber, wenn der Importvorgang öfters und auch mit unterschiedlicher CSV-Struktur durchgeführt werden muss.

crystal · Juli 01, 2016, 22:59:17

@ekkehard

Zitatfinde ich es so, mit "Feldnamen", einfacher diese Tabellen zu beschreiben,
als irgendwelche Verrenkungen mit abzählen zu veranstalten; - ich muss
mir einfach keine Gedanken um eine Reihenfolge zu machen.

Prinzipiell denke ich: hat man die Daten in einem Vektor oder Array, das man durch-loopen kann, so kann man natürlich auch Feldnamen "dynamisch" bzw. programmtechnisch zusammensetzen (feldname = "MeinFeld"&i). Da braucht man i nicht einmal formatieren...
Eine For-Next-Schleife über z.B. 457 Felder ist doch wohl leichter zu entwickeln und zu pflegen, als 457 Zeilen mit einzelnen Zuweisungen. Immerhin wären das im Sourcecode-Ausdruck ca. 6 DIN-A-4-Seiten....

Aber egal wie man es dreht, irgendwo muss man natürlich den Aufwand treiben, so viele Tabellen- und/oder Formular-Felder zu definieren. Ich gebe allerdings zu, dass 457 einzeln benannte Felder hier den Vorteil hätten, dass deren Namen auch "sprechend" verändert werden können, als sich mit einem Lauf-Index zu beschäftigen. Nach bekannter Datenlage scheinen solch sprechende Namen aber eher nicht vorzuliegen.

Nach wie vor fände ich meine Lösung Nr. 3 am ehesten geeignet, alle möglichen Eventualitäten zu berücksichtigen.

Mich würde ja interessieren, was der TS zu den Vorschlägen sagt. Eine Rückmeldung wäre schön, damit man sich selbst überprüfen kann, ob man in die passende Richtung gedacht hat, zumal die Aussagen über die Ausgangsdaten eher knapp sind...

Denn leider muss ich feststellen, das viele Threads vom Thread-Starter nicht mehr verfolgt werden und mögliche Lösungen einer Beurteilung harren, teilweise über Wochen. Das ist sehr schade und enttäuschend, wie vielleicht auch andere meinen, die sich in die jeweilige Problematik eindenken und ihre Beiträge leisten.

ebs17 · Juli 02, 2016, 08:16:40

Nebenbei sollte man auch immer eine Betrachtung in die Richtung führen, warum so eine - ich sag mal schwieriger zu verarbeitende - CSV-Datei überhaupt erst erzeugt wird und in Anwendung kommt.

Standardisierung und Einhalten von Standards bringt Einfachheit und Schwung in die Verarbeitung. Wenn heute immer noch jede Schraube und jede Mutter individuell von Hand geschnitzt würde, könnten sich nur die allerwenigsten ein Auto leisten (Protzwanderstock statt Protzauto).

Daher sollte man sich beim Erzeuger der CSV dafür interessieren, ob nicht auch etwas Standardgemäßes, was dann einfachst weiterzuverarbeiten ist, erzeugt werden kann. Gedankenlosigkeit und Unfähigkeit kommen durchaus nicht so selten vor, am Ende erzeugt vielleicht derjenige, der sich über die zusätzlichen Probleme ärgert und sie sowieso nicht beherrscht, selber solchen Datensalat.

Beaker s.a. · Juli 02, 2016, 14:43:57

Hallo crystal,

Viele Wege führen nach Rom. Wobei Eberhards sicher der kürzeste ist.

Bezügl. Rückmeldungen der TS kann ich dir nur zustimmen, finde ich
auch immer schade. Habe manchmal das Gefühl die geben zu schnell
auf, und machen dann doch mit Excel weiter.
In diesem Fall mag es auch sein, dass der TS einfach überfordert ist mit
den verschiedenen Vorschlägen und/oder sich nicht entscheiden kann,
welchen er für sich geeignet hält/weiterverfolgen soll.

gruss ekkehard

Sproket_1972 · Juli 06, 2016, 02:42:26

Hallo zusammen,
habe leider nicht mehr an der Diskussion teilnehmen können.
Ich bin auf Schichtarbeit und da kann man halt nicht immer Online sein.
Man muss auch mal schlafen und sich bei den Liebsten melden.
Also habe den Code mal laufen lassen:
habe den Pfad eingefügt und eine Tabelle2 erstellt.
Bricht aber ab bei :
rst.Fields("Feld1") = impRec.FELD1

mit Fehlermeldung: 3163
habe eine BMP angehängt.

Was geht denn da schief ?

Sproket_1972 · Juli 06, 2016, 04:32:35

Hallo nochmals Ich,
habe jetzt mal Antworten durchforstet.
Mir wäre daran gelegen eine einfache Vorgehensweise zu realisieren.
Die CSV Datei hat eine große Anzahl an Feldern von denen ich aber nur ca. 100 Felder
brauche.
Diese sollten dann in eine oder wenn nicht möglich in mehrere Access Tabellen eingefügt werden.
Diese CSV-Datei wird jeden Tag neu von eine anderen Fa. versendet und dann in dieser Access Tabelle oder Tabellen angehängt.
Daraus möchte ich dann eine Datenbank aufbauen, die man durchforsten kann.

Das wäre das Ziel !

Lachtaube · Juli 06, 2016, 09:21:13

Lade doch bitte eine gekürzte Original-Datei (sensible Daten ggf. anonymisieren) hoch und teile mit, welche Spalten (Namen, falls vorhanden bzw. Position in der Datei) für Dein Vorhaben benötigt werden. Wenn Du dann noch eine Access-Datenbank (möglichst im 2003-er Format) mit einer leeren Zieltabelle hinterlegst, findet sich bestimmt jemand, der Dir das zusammenbastelt.

ebs17 · Juli 06, 2016, 10:04:25

Dabei könntest Du zusätzliche Denkfragen beachten:

- Eine Tabelle mit 100 Feldern?
- Wie sieht die nachfolgende Verarbeitung der Daten aus?
(Man könnte auch über ein Datenmodell statt nur Sammeltabelle(n) nachdenken.)
- Neue Daten
-- ersetzen vorhandene Daten?
-- werden einfach angefügt?
-- aktualisieren vorhandene Datensätze, nicht vorhandene werden ergänzt?

MaggieMay · Juli 06, 2016, 10:12:33

Hi,

die Datensatzstruktur sollte schon passen, mit nur sechs Feldern wirst du nicht zum Ziel kommen.
Ich hatte das auch schon mal ausprobiert mit dem Binary Input, leider ohne Erfolg.
Eine Testdatei + DB wären also hilfreich.

Apropos:

Zitateine gekürzte Original-Datei

In der Länge Ja, nur nicht in der Breite. Ein paar Zeilen genügen schon, aber es sollten schon alle Spalten enthalten sein, damit es realistisch bleibt.

Beaker s.a. · Juli 06, 2016, 10:25:47

Hallo,

Zitatmit Fehlermeldung: 3163
habe eine BMP angehängt.

Finde die Fehlermeldung eigentlich ausnahmsweise zielführend.
Betrachte den Tabellenentwurf und schau welchen Datentyp (am
Anfang sagtest du "alles Text") das Feld hat. Wenn es Text ist,
stelle die Eigenschaft "Feldgrösse" auf 255.
Sollte das Feld einen anderen Datentyp haben, musst du dir die
zu importierenden Daten noch einmal anschauen, und den Typ
entsprechend anpassen, oder eine Konvertierung im Code vornehmen.
Z.B. wenn Feld1 vom Typ Zahl ist:

Zitatrst.Fields("Feld1") = VAL(impRec.FELD1)

gruss ekkehard

Sproket_1972 · Juli 08, 2016, 09:30:25

Habe die test Datei angehängt.
Musste diese aber als *.XLS abspeichern.

Zitat von: MaggieMay am Juli 06, 2016, 10:12:33
Hi,

die Datensatzstruktur sollte schon passen, mit nur sechs Feldern wirst du nicht zum Ziel kommen.
Ich hatte das auch schon mal ausprobiert mit dem Binary Input, leider ohne Erfolg.
Eine Testdatei + DB wären also hilfreich.

Apropos:
Zitateine gekürzte Original-Datei
In der Länge Ja, nur nicht in der Breite. Ein paar Zeilen genügen schon, aber es sollten schon alle Spalten enthalten sein, damit es realistisch bleibt.

Sproket_1972 · Juli 08, 2016, 09:34:53

habe den Code: "
Set rst = CurrentDb.OpenRecordset(Name:="Tabelle2")
Do Until EOF(intDateiNr)
'Do Until #intDateiNr.EOF '<- bei diesem Ausdruck bin ich nicht sicher
rst.AddNew
rst.Fields("Feld1") = impRec.FELD1
'rst.Fields("Feld2") = impRec.FELD2
rst.Update

Get #intDateiNr, , impRec

Loop
"
ausprobiert und es bricht entweder mit Fehlermeldung ab oder schreibt erst gar nicht in die Tabelle2 hinein.
Tabelle2 habe ich auf 255 zeilen eingestellt aber ohne Erfolg.

Sproket_1972 · Juli 08, 2016, 11:18:10

Zitat von: Lachtaube am Juli 06, 2016, 09:21:13
Lade doch bitte eine gekürzte Original-Datei (sensible Daten ggf. anonymisieren) hoch und teile mit, welche Spalten (Namen, falls vorhanden bzw. Position in der Datei) für Dein Vorhaben benötigt werden. Wenn Du dann noch eine Access-Datenbank (möglichst im 2003-er Format) mit einer leeren Zieltabelle hinterlegst, findet sich bestimmt jemand, der Dir das zusammenbastelt.

habe mal beide Dateien eingezipt.
Access und CSV Datei
Hoffe man kann damit was anfangen und man gibt mir einige Tipps wie ich die Access
VBA dazu bringe mir die CSV in die Tabelle2 zu schreiben !!??

Nachtrag: Habe versucht die Access Datei anzuhängen aber leider ist die 300 Kb ein Knackpunkt.
Es wäre mir wichtig das man aus der CSV beliebige Felder in Access importieren kann !!!
d.h. das man durch Änderung am Code weiter Felder hinzufügen kann.
das Ergebnis sollte etwa so wie in angehängter Access_Tabelle2 aussehen.

MaggieMay · Juli 08, 2016, 12:19:17

Hi,

hast du die Access-Datei komprimiert und gezippt vor dem Upload?

Neuigkeiten:

Teile einer CSV Datei in Access Formular einfügen