Access-o-Mania

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

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

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.

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

Zitatden/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.

Also das mit den CodePage war ja nur ein Ansatz.

DD

Zitat von: DD am März 10, 2023, 15:56:26Der 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.

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

ZitatDie 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).

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.

ZitatGleichlautend 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

Hallo Phil,

ZitatDu 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

Zitatdass 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.

Zitat"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.

Zitataber 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:

Zitatwenn 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?

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.


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

Danke
DD

Hallo,
ist das ein deutsches Access ?
Wenn ja dann so:
test: Ersetzen([Kennung]"³";"ü")Statt Komma Semikolon und deutscher Funktionsname (wird aber automatisch gändert).

Zitat von: DD am März 10, 2023, 16:57:04Wenn 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.

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:

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

Das Zeichen kann ich wie folgt umwandeln, aber halt nicht mit der Funktion.

In der Funktion könnte ich auch mit CHR(xxx) arbeiten aber die Zahl krieg ich auch nicht raus.

Hier was ich rausgefunden habe
UTF-8 dezimal
226 150 128
UTF-8 hex
E2 96 80
.html Entity
▀
.html dezimal
#9600
.html hexadezimal
#x2580
Unicode Block
2580-259F
Unicode dezimal
9600
Unicode hexadezimal
U+2580
UTF-8 länge
3
UTF-8 binär
11100010 10010110 10000000


Danke
DD

Hallo,
Vor ca. 20 Jahren bekam ich mal dieses
Option Compare Database
Option Explicit
'Dieses Modul stammt von Norbert Kammer aus einer Access-Newsgroup

Declare Function OemToChar Lib "user32" Alias "OemToCharA" _
        (ByVal lpszSrc As String, _
        ByVal lpszDst As String) As Long

Declare Function CharToOem Lib "user32" Alias "CharToOemA" _
        (ByVal lpszSrc As String, _
        ByVal lpszDst As String) As Long

Public Function Dos2Ansi( _
        ByVal cDos As String) As String

    Dim cErg As String
    Dim X    As Long
   
    cErg = Space$(Len(cDos & vbNullString))
    X = OemToChar(cDos, cErg)
   
    Dos2Ansi = cErg

End FunctionIch habe das seinerzeit für den Import der Leitdaten (DHL) verwendet. Die letzte Nutzung
liegt jetzt aber auch schon bestimmt 10 Jahre zurück. Über verwendete Codepages kann ich
leider nichts mehr sagen.
Vielleicht ist es einen Versuch wert.

gruss ekkehard

Zitat von: Beaker s.a. am März 12, 2023, 10:56:25Vielleicht ist es einen Versuch wert.

Das OEM Character Set meint nach meinem Verständnis CP437 ("OEM United States").
Schön, wenn es hilft. - Aber man könnte halt auch diese Code Page in der Importspezifikation festlegen, anstatt erstmal Quark zu importieren, den man nachträglich bereinigt.

Westeuropäisch (DOS): DOS steht ja irgendwie für Anfänge, wo Ressourcen noch drastisch schmaler waren und man sich zweckmäßig oft auf ASCII-Codes <= 127 beschränkte.
Da müsste mir einer seine Fixierung auf DOS erst einmal ausführlich begründen.

Guten Morgen,

leider können wir beim Großrechner Export keinen Unterschied feststellen, denn eine Datei geht ja und eine andere nicht. Laut Export am Großrechner ist alles gleich (ausser natürlich der überwiegende Teil der Felder).

Ich danke Euch allen trotzdem für die Hilfestellungen. Ich werde hier wohl mit dem "Fehler" leben müssen.


Wie gesagt trotzdem herzlichen Dank

DD

Zitat von: DD am März 13, 2023, 12:17:43Laut Export am Großrechner ist alles gleich (ausser natürlich der überwiegende Teil der Felder).

Für genau dieses potenzielle Ergebnis hatte ich dir ober den folgenden Absatz geschrieben:

Zitat von: PhilS am März 11, 2023, 18:34:37Wenn 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.

Das wäre natürlich noch keine Lösung des Problems, aber es wäre eine nachvollziehbare Erklärung. Eine solche zu haben wäre mir jedenfalls lieber, als mit irgendwelchen mysteriösen Fehlern unklarer Herkunft leben zu müssen.

Hallo Philip, hallo Eberhard,

Ich weiss nicht ob ihr die Leitdatendatei, die seinerzeit von der Post/DHL zur
Verfügung gestellt wurde, kennt. Das war eine riesige Textdatei (460Mb) in der
ca. ein Dtzd. Tabellen mit unterschiedlichen Datensatzlängen (definiert durch
feste Feldlängen) vereint waren. Über eine Kennung waren die zwar zu isolieren,
aber mit Importspezifikation war da nix. Jedenfalls nicht mit meinen damaligen,
schmalen Fähigkeiten. Wüsste aber heute auch noch nicht, wie man da per IS die
einzelnen Tabellen verknüpfen könnte. Inzwischen brauch ich es aber auch schon
lange nicht mehr.
Der Import an sich funktionierte dann auch nur sequentiell.

gruss ekkehard

P.S. Das war mein erster Kontakt zu Importen. Und seit ich das damals mit Hilfe
der "Altgurus" aus den Access-Newsgroups hinbekommen hatte, habe ich keine
Probleme mehr mit Importen, - da hab ich seitdem so ziemlich alles reinbekommen.

Zitat von: PhilS am März 13, 2023, 12:54:25

Zitat von: DD am März 13, 2023, 12:17:43Laut Export am Großrechner ist alles gleich (ausser natürlich der überwiegende Teil der Felder).

Für genau dieses potenzielle Ergebnis hatte ich dir ober den folgenden Absatz geschrieben:

Zitat von: PhilS am März 11, 2023, 18:34:37Wenn 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.

Das wäre natürlich noch keine Lösung des Problems, aber es wäre eine nachvollziehbare Erklärung. Eine solche zu haben wäre mir jedenfalls lieber, als mit irgendwelchen mysteriösen Fehlern unklarer Herkunft leben zu müssen.

Ja, prinzipiell hast Du recht, aber wenn ich in Einer Datei das Feld Kennung habe und es richtig läuft und bei der anderen das gleiche Feld Kennung nehme und es hier falsch läuft, aber die Aussage der Kollegen lautet die CodePages sind die gleichen, dann kann ich da auch nichts mehr machen.

Nach Rückfrage bei einem anderen Kollegen, der die Datei auch benutzt nur nicht in Access, und diese dort auch importiert hat der dieselben Probleme. Warum die Kollegen das vom Großrechner nicht anders hinbekommen, da habe ich keine Ahnung. Aber wie gesagt Danke nochmal und ich muss damit leben ( 2025 soll das System abgelöst werden ;))))         ).

DD

Zitat von: DD am März 13, 2023, 13:18:01die Aussage der Kollegen lautet die CodePages sind die gleichen, dann kann ich da auch nichts mehr machen.

Wenn man konkret belegen kann, dass diese Aussage nicht stimmt, könnte das anders aussehen...

Aber am Ende ist es natürlich deine Sache, ob das erfolgversprechend ist und wie du mit dem Problem weiter umgehst.

Zitatdie Aussage der Kollegen lautet die CodePages sind die gleichen

Und welchen Namen tragen die Codepages (klingt zudem nach mehr als einer ...?)?
Wenn man es wüsste, sollte man es doch laut sagen können.
Wenn Ihr auch noch zusammenarbeitet: Warum kann es zu solch einem Rumgeeiere kommen? Miteinander reden ist mehr als sich gegenseitig Worte zuzuwerfen.

@ekkehard: Mehrere Tabellen in einer Datei? Dann müsste man die Tabellen auf einzelne Dateien trennen und dann pro Tabelle/Datei die richtige IS zuordnen. Hoffentlich gibt es da Standards/Regelmäßigkeiten.

Ich hatte mal eine Textdateivariante, da waren mit Bindestrichen und Pipes echte Tabellen gemalt (so zum richtig schönen Anschauen), das Ganze mit festen Längen, wobei sich aber von Datei zu Datei die festen Längen änderten, weil sie sich nach den Textlängen von Inhalten richteten.
Dort habe ich mit einer IS gearbeitet, die jeweils per VBA an die Datei angepasst wurde.
Wenn man zeilenweise liest und auswertet, ist ja der Aufwand keinesfalls kleiner.

Hallo Eberhard,
Wie geschrieben brauch ich jetzt eh nicht mehr, aber auf den Ansatz die Datei
vor dem Import auf einzelne Dateien aufzuteilen, auf die man dann eine IS hätte
anwenden können, hat man mich damals nicht gebracht, und um selber drauf zu
kommen war ich damals noch zu "grün".
Inzwischen komme ich aber mit den meisten, ich sag mal "ungewöhnlichen", Text-
importen ziemlich gut zurecht.

gruss ekkehard