Abbruch beim txtFile Import.

[Debus]

Halo, ich importiere aus etlichen txt Dateien Daten nach Access per

Code [Auswählen] Erweitern

DoCmd.TransferText transferType:=acImportFixed, specificationname:="import01", tablename:="01", FileName:=strFileTo, hasfieldnames:=True
Das klappt auch soweit fast problemlos.

Es sind in der Datei ca 80.000 Datensätze.

Der erste Ausstieg ist beim Datensatz 48563. Nur zur Erklärung auch davor gab es schon Datensätze wo alle Umlaut vorgekommen sind, und diese wurden importiert. Dies nur weil  bei allen Fehlern immer ein Umlaut mit enthalten ist.

Ich hänge auch mal die Datei an wo die ersten drei Aussteige vorkommen.

Der obere wird jeweils noch importiert und der darunter nicht. Lösche ich diesen unteren raus, importiert er weiter bis zum nächsten Fehler.

Nun meine Frage.

1. erkennt jemand einen Fehler im Datensatz den man dann ändern kann oder
2. was muss man einstellen, dass er trotz Fehler weiter importiert.

Danke für Euere Hilfe

DD

[ebs17]

Bei Standardimporten wird eigentlich eine Importfehlertabelle angelegt. In diese könnte man reinschauen.

Zu 2): Um einen Knopf zu drehen, muss man eigentlich die Schalttafel vor Auge und Hand haben.

Daneben würde ich die Textdatei nur verlinken und die Inhalte per Abfrage übertragen. Abfragen sind mir nicht fremd, so würde sie mir bei Ausführung mitteilen, was ihr nicht passt.

[Debus]

Hallo Eberhard.

Ich muss diese Dateien importieren, das es sich um Großrechner Tabellen handelt, auf die ich nicht immer Zugriff habe!

Wenn ich den Import laufen lassen und von UTF8 auf Westeuropäisch (DOS) umstelle, dann läuft es durch, nur es werden halt die Umlauf nicht sauber dargestellt.

Daher wäre UTF8 schon deutlich besser.

Wenn ich das ganze importiere mit UTF8 kommt immer der Fehler

Nicht analysierbarer Datensatz.

Kann man das Aussteigen beim Import denn verhindern? Das er also einfach den/die defekten DS überspringt und den Rest importiert?

Danke
DD

[ebs17]

den/die defekten DS überspringt

Absichtlich die Datenintegrität zerstören? Ist Deine Vermögensschadenshaftpflicht ausreichend und bezahlt?

Von der totalen Unwissenheit bist Du jetzt auf die Wahl der Codepage gewichen. Die bestehende Auswahl ist größer als zwei.
Idealerweise bestimmt man, was man konkret vorliegen hat. Oder man fragt nach, ein Großrechner hat ja auch Standards.

[Debus]

Also das mit den CodePage war ja nur ein Ansatz.

DD

[PhilS]

Der erste Ausstieg ist beim Datensatz 48563. Nur zur Erklärung auch davor gab es schon Datensätze wo alle Umlaut vorgekommen sind, und diese wurden importiert. Dies nur weil  bei allen Fehlern immer ein Umlaut mit enthalten ist.

Ich hänge auch mal die Datei an wo die ersten drei Aussteige vorkommen.

Ich vermute, in der problematischen Datei ist an der Stelle ein (oder mehrere) Zeichen vorhanden, die entweder Access als Ende der Datei interpretiert, oder die einen Fehler verursachen der zum Abbruch des Imports führt.

Die von dir angehängte Datei sieht in dieser Hinsicht unverdächtig aus. - Das hat aber wenig zu bedeuten, weil du die Daten sicherlich mit Copy&Paste aus der Originaldatei zusammengestellt hast und dabei problematische Zeichen evtl. nicht kopiert wurden.

Du solltest dir die Originaldatei mal in einem Hex-Editor anschauen, ob an den problematischen Stellen unerwartete Zeichen stehen. Das wäre dann die Ursache, eine Lösung müsste man dann abhängig von dem konkreten Problem erarbeiten.

[Debus]

Hallo Phil,

danke für den Ansatz, das wäre nun mein nächster Versuch gewesen. Die Batch zum erstellen der Datei zu kontrollieren, weil ich eine andere Datei mit den selben Namen  problemlos einlesen kann. Hier sind nur andere Zahlen dahinter.
Ich werde mir die Datei aber wie von Dir angeregt zuerst mal mit einem HEX Editor anschauen.  Danke für den Ansatz.

Aber trotzdem mal die Frage. Würde mich halt wirklich mal interessieren, kann man den bei Fehler weiter einlesen also so dass der nicht aussteigt.  Geht das oder nicht?

Und an den Datensätzen an sich kann es auch nicht liegen, weil ich die drei Sätze mal rausgelöscht und von Hand hinten angehangen habe, und dann werde diese Sätze auch eingelesen. Aber ich werde es mal mit dem Hex kontrollieren.

Danke

DD

[ebs17]

Die Batch zum erstellen der Datei zu kontrollieren

Du erstellst die problematische Datei selber? Da sollte man doch dort nachsehen und alles gleich richtig und verwertbar gestalten.

Den Hinweis mit der Importfehlertabelle ignorierst Du.

Gleichlautend ignorierst Du die Verknüpfung als Tabelle. Die Betrachtung dieser Tabelle würde zeigen, ob denn alle Datensätze erst einmal erfasst und angezeigt werden (Prüfung auf Datenfehler).
Im zweiten Schritt des Imports müssen Daten so angeboten werden, dass sie von den Zielfeldern aufgenommen werden können (Datentyp, Einhaltung Gültigkeitsregeln, keine Verstöße gegen eindeutige Indizierung / RI).

[Debus]

Hallo Eberhard,

1. Nein, die Datei erstelle ich nicht selber, aber ich kann mit den Kollegen reden, wenn man die Richtung weiß woher etwas kommt. Sorry falls es sich anders angehört hat  -  ich erstelle die Datei nicht selber!

2. Den Hinweis mit der ImportFehlertabelle habe ich nicht ignoriert, sondern schon danach gegoogelt. Es steht dort folgendes bei dem Datensatz drin, wo der Import "aussteigt"

"Nicht analysierbarer Datensatz"

3.

Gleichlautend ignorierst Du die Verknüpfung als Tabelle. Die Betrachtung dieser Tabelle würde zeigen, ob denn alle Datensätze erst einmal erfasst und angezeigt werden (Prüfung auf Datenfehler).
Im zweiten Schritt des Imports müssen Daten so angeboten werden, dass sie von den Zielfeldern aufgenommen werden können (Datentyp, Einhaltung Gültigkeitsregeln, keine Verstöße gegen eindeutige Indizierung / RI).

Hier kann ich nur sagen, dass mit dem Verknüpfen ist nicht einfach möglich, da die Daten von Kollegen genutzt werden, die aber auf den Speicherort keinen Zugriff haben, da es dort noch andere Daten gibt, worauf die keinen Zugriff haben dürfen.
Die Gültigkeitsregel und Verstöße liegen glaube ich nicht vor, da wenn ich den Import nicht mit UTF- 8 mache, ich die Fehler ja nicht bekommen.

Es tut mir leid, wenn das nicht so klar rüber kam

Trotzdem noch ein schönes Wochenende

DD

[Debus]

Hallo Phil,

Du solltest dir die Originaldatei mal in einem Hex-Editor anschauen, ob an den problematischen Stellen unerwartete Zeichen stehen. Das wäre dann die Ursache, eine Lösung müsste man dann abhängig von dem konkreten Problem erarbeiten

Leider sehe ich auch im Hex Editor keinen Unterschied. Vielleicht übersehe ich da aber was. 

Ich habe mal ein Screenshot angehangen wo der Import aussteigt. Braun.Jac wird noch importiert und danach ist er raus.

Danke
DD

[ebs17]

dass mit dem Verknüpfen ist nicht einfach möglich

In der Situation, wo man Importieren kann, kann man auch Verknüpfen. In beiden Fällen ist ein Zugriff der gleiche.
Mit Verknüpfen meine ich natürlich temporär Verknüpfen, also für die Dauer der Nutzung.

"Nicht analysierbarer Datensatz"

Heißt also Problem beim Lesen. Vergleiche zeichengenau mit den Notwendigkeiten, die per Importspezifikation definiert sind. Vielleicht sind da irgendwelche Steuerzeichen eingestreut (die man nicht offensichtlich wahrnehmen und sehen kann).
Daher also einen besseren Editor zur Betrachtung hernehmen oder die komplette Zeile zeichenweise als ASCII-Code ausgeben und analysieren.
Solche Steuerzeichen können auch die fixierten Längen beeinflussen.

aber ich kann mit den Kollegen reden

Das wäre faktisch fast das Gleiche. Prozess der Erstellung analysieren und korrigieren statt nachträglich Würgarounds veranstalten zu müssen.

//Edit:

wenn ich den Import nicht mit UTF- 8 mache, ich die Fehler ja nicht bekommen

Sollte nicht eine Codepage ausgewählt werden können, die Umlaute anzeigt?

[Debus]

Auch wenn ich die Analyse am Montag, wenn ich mit den Kollegen redenkann wegen der Datei etc, hier mal noch eine Frage, die mich interessiert aber hier hinpasst.

Wie kann ich im Nachgang die Umlaut ändern,
Bei einer Abfrage will er es auch nicht machen Hier kommt immer die Meldung, es fehlt eine Klammer oder ein Zeichen ist nicht in "" geschrieben
Oder wie / wo kann ich diese "Sonderzeichen" ansonsten ersetze.

Code [Auswählen] Erweitern

test:Replace([Kennung]"³","ü")
Wie würde man das machen

Danke
DD

[MzKlMu]

Hallo,
ist das ein deutsches Access ?
Wenn ja dann so:

Code [Auswählen] Erweitern

test: Ersetzen([Kennung]"³";"ü")Statt Komma Semikolon und deutscher Funktionsname (wird aber automatisch gändert).

[PhilS]

Wenn ich den Import laufen lassen und von UTF8 auf Westeuropäisch (DOS) umstelle, dann läuft es durch, nur es werden halt die Umlauf nicht sauber dargestellt.

Ich glaube zunehmen, dass dein(e) Problem(e) mit dem Zeichensatz zu tun haben.

Die Textdatei, die du hier hochgeladen hast, war tatsächlich UTF8-codiert. - Das kann aber beim Copy&Paste in eine neue Datei, beim Hochladen, durch das Forum, oder sonstwie bei der Übermittlung passiert sein und ist daher nicht wirklich aussagefähig.

Wenn die Umlaute mit Auswahl von UTF8 in Access sauber importiert werden, aber sonst nicht, spricht das schon für eine UTF8-codierte Datei.
Aber(!), dein Screenshot der Datei im Hex-Editor zeigt das ü codiert als 0xFC. Das ist nicht UTF8, sondern CP850 (Westeuropa DOS), oder CP1252 (Westeuropa Windows).

Du solltest mit den Leuten sprechen, die die Datei erzeugen, und in Erfahrung bringen welche Codepage sie (glauben zu) verwenden.
Wenn das noch nicht weiterhilft, solltest du mal im Hex-Editor ein "ü", das erfolgreich importiert wurde, mit einem "ü" in einem problematischen Datensatz vergleichen. Möglicherweise sind die verschiedenen Datensätze im Quellsystem mit verschiedenen Zeichensätzen kodiert, und der Export spuckt die Daten einfach 1:1 aus, was dann zu verschiedenen Codierungen innerhalb einer Datei führt.

[Debus]

Hallo Klaus,

Danke für den Hinweis, das klappt auch super und wäre halt mein Notnagel.

Nur bei Kennungen mit ß klappt das nicht
Die Kennungen sehen wie im Beispiel aus :"Bu▀berg"

Hast Du da eine Idee.

übrigens habe ich das ganze dann noch wie folgt gemacht


SQL = "SELECT [01-1].*, umwandeln([Kennung1]) AS Kennung INTO 01 FROM [01-1];"


und folgende Function:

Code [Auswählen] Erweitern

Function umwandeln(source As String) As String

 source = Replace(source, "÷", "ö")
 source = Replace(source, "¯", "ß")
 source = Replace(source, "³", "ü")
 source = Replace(source, "õ", "ä")
 clearSpecialSigns = source

End Function
Danke nochmal aber was mache ich nun mit dem ß

DD