TFDBatchMove scheitert an korrekter PLZ erkennung

[fisipjm]

Hallo,

folgende Aufgabenstellung, die ich eigentlich für wahnsinnig simpel gehalten habe:

Importiere eine CSV Datei mit x Spalten in eine Tabelle einer MS SQL Datenbank.
Behandle die Daten entsprechend verschiedener vorgaben, erstelle Verknüpfungen in der Datenbank, bliblablub

Soweit so einfach.

Ich hab mir gedacht "hey Wahnsinn, wenn Delphi mit schon so tolle Komponenten zur Verfügungs stellt wie TFDBatchmove, TFDBatchMoveTextReader und TFDBatchMoveDatasetWriter" warum nutz ich die nicht einfach. Also alle komponenten auf die Form geschmissen, inkl. FDConnection und lSQL komponente um direkt eine Query auf den Dataset machen zu können (Die Zuordnung der Felder soll später dynamisch über die SQL Abfrage laufen also alla "Select AltesFeldInCSV as ZielFeldInMSDEDB from localDataset").

Folgendes Phänomen:
Die Batchmove Komponenten hat eine wunderbare Funktion die sich schimpft "FormatGuessing". Dabei wir die Date Analysiert und im Reader Autoamtisiert Felder angelegt und mit einem entsprechenden Datetyp versehen.
Woran der Reader kläglich Scheitert, ist es eine Simple PLZ korrekt zu analysieren.

Beispiel meiner PLZs

12345
54321
23451
01234
87654

Das Format erkennt er mit den als LongInt und schneidet mir bei dem 01234 die 0 ab, weil LongInt logisch. Da es nunmal eine deutsche Liste ist, gibt es leider keine Buchstaben. Ich habe keine Möglichkeit gefunden den Batchmove dazu zu überreden, mir das richtige Format rauszuspuken. (In meinen Augen, String)

Habt ihr Ideen, Vorschläge? Bin für alles offen.

[Uwe Raabe]

Das das GuessFormat zur Laufzeit durchgeführt wird, kannst du das Ergebnis auch nur per Code nachträglich anpassen. Angenommen das Feld heißt PLZ, dann kannst du das mit

Delphi-Quellcode:

BatchReader.DataDef.Fields.FieldByName('PLZ').DataType := atString

machen.

[fisipjm]

Zitat:

Zitat von Uwe Raabe (Beitrag 1502903)

Das das GuessFormat zur Laufzeit durchgeführt wird, kannst du das Ergebnis auch nur per Code nachträglich anpassen. Angenommen das Feld heißt PLZ, dann kannst du das mit

Delphi-Quellcode:

BatchReader.DataDef.Fields.FieldByName('PLZ').DataType := atString

machen.

Hallo Uwe,

das hab ich auch schon befürchtet. Ich verstehe nur nicht das die Zahl 01234 als Integer erkannt wird. Ja, es sind nur Zahlen, aber es wäre doch ein leichtes bei einer führenden 0 die Erkennung auf String zu setzen. In meinen Augen ein Bug im System.

[HolgerX]

Hmm..

CSV-Import ist immer so eine Sache..
Gerade z.B. Excel versucht immer die 'Werte' zu 'Deuten' und macht aus Zahlen auch gerne Datumsangaben.
Wahrscheinlich verendet hier MS-SQL die gleichen Routinen / Libs!

Woher hast Du die CSV?

Generell sollte schon bei der Erstellung der CSV am besten darauf geachtet werden, dass Stings (Text) immer in ".." gesetzt wird. Dann ist die Fehlerquote durch 'Falsch Interpretation' geringer.

Hierzu kommt:
PLZ sind keine (Integer) Zahlen!! Es werden nur in den meisten Ländern ausschließlich Ziffern hierfür verwendet. Gerade an der Führenden '0' zu erkennen, welche es bei einer richtigen Zahl nicht gibt (außer alleine direkt vor dem Komma).

Es sollte ein String in der DB (".." bei CSV) verwendet werden, da in anderen Länder nicht nur Buchstaben, sondern auch Bindestriche innerhalb verwendet werden. Auch ist die Länge Weltweit unterschiedlich und nicht immer 5 Ziffern.

https://de.wikipedia.org/wiki/Liste_der_Postleitsysteme

Meine Erfahrung mit CSV:
Wenn Du einen sauberen Import willst, dann mach in selber und verwende keine MS Routinen... ;)

[Uwe Raabe]

Zitat:

Zitat von fisipjm (Beitrag 1502996)

Ja, es sind nur Zahlen, aber es wäre doch ein leichtes bei einer führenden 0 die Erkennung auf String zu setzen. In meinen Augen ein Bug im System.

Also einen Bug würde ich das nicht nennen. Eine durchaus valide Erkennung auf Integer oder nicht könnte z.B. durch TryStrToInt erfolgen. Die von dir vorgeschlagene Methode würde ja bei lauter 0-Werten (zumindest in den zu analysierenden N Zeilen) auch nicht eindeutig zum Ziel führen. Man müsste dazu wohl auch noch prüfen, ob alle Einträge die gleiche Anzahl Ziffern haben. Ich sehe da schon eine sehr spezielle Anforderung für deinen Fall, die eine Verallgemeinerung wohl nicht rechtfertigt. Aber man kann das ja eben durch gezieltes Eingreifen lösen. Es heißt ja auch nicht umsonst nur GuessFormat.

[fisipjm]

Zitat:

Zitat von HolgerX (Beitrag 1503002)

Hmm..

CSV-Import ist immer so eine Sache..
Gerade z.B. Excel versucht immer die 'Werte' zu 'Deuten' und macht aus Zahlen auch gerne Datumsangaben.
Wahrscheinlich verendet hier MS-SQL die gleichen Routinen / Libs!

Woher hast Du die CSV?

Vom Kunden.

Zitat:

Zitat von HolgerX (Beitrag 1503002)

Generell sollte schon bei der Erstellung der CSV am besten darauf geachtet werden, dass Stings (Text) immer in ".." gesetzt wird. Dann ist die Fehlerquote durch 'Falsch Interpretation' geringer.

Die sind schon froh wenn Sie es so hin bekommen.

Zitat:

Zitat von HolgerX (Beitrag 1503002)

Hierzu kommt:
PLZ sind keine (Integer) Zahlen!! Es werden nur in den meisten Ländern ausschließlich Ziffern hierfür verwendet. Gerade an der Führenden '0' zu erkennen, welche es bei einer richtigen Zahl nicht gibt (außer alleine direkt vor dem Komma).

Es sollte ein String in der DB (".." bei CSV) verwendet werden, da in anderen Länder nicht nur Buchstaben, sondern auch Bindestriche innerhalb verwendet werden. Auch ist die Länge Weltweit unterschiedlich und nicht immer 5 Ziffern.

Meinen Post haste vorher aber schon mal gelesen oder? Das ist doch das was ich beschrieben habe :?:

Zitat:

Zitat von HolgerX (Beitrag 1503002)

Meine Erfahrung mit CSV:
Wenn Du einen sauberen Import willst, dann mach in selber und verwende keine MS Routinen... ;)

Den müsstest du mir erklären, in wie fern wären hier MS Routinen beteiligt?

[fisipjm]

Zitat:

Zitat von Uwe Raabe (Beitrag 1503004)

Zitat:

Zitat von fisipjm (Beitrag 1502996)

Ja, es sind nur Zahlen, aber es wäre doch ein leichtes bei einer führenden 0 die Erkennung auf String zu setzen. In meinen Augen ein Bug im System.

Also einen Bug würde ich das nicht nennen. Eine durchaus valide Erkennung auf Integer oder nicht könnte z.B. durch TryStrToInt erfolgen. Die von dir vorgeschlagene Methode würde ja bei lauter 0-Werten (zumindest in den zu analysierenden N Zeilen) auch nicht eindeutig zum Ziel führen. Man müsste dazu wohl auch noch prüfen, ob alle Einträge die gleiche Anzahl Ziffern haben. Ich sehe da schon eine sehr spezielle Anforderung für deinen Fall, die eine Verallgemeinerung wohl nicht rechtfertigt. Aber man kann das ja eben durch gezieltes Eingreifen lösen. Es heißt ja auch nicht umsonst nur GuessFormat.

Ich fände das beschriebene Vorgehen eigentlich recht logisch.
Folgende Beispiele:

0 = Integer
00= String
12= Integer
01= String

im Prinzip muss er mir immer wenn ich eine führende 0 hab das Teil als String interpretieren weil alles andere Datenverlust bedeuten würde.

[jobo]

Zitat:

Zitat von fisipjm (Beitrag 1502996)

.. Ja, es sind nur Zahlen, aber es wäre doch ein leichtes bei einer führenden 0 die Erkennung auf String zu setzen. In meinen Augen ein Bug im System.

Zitat:

Zitat von fisipjm (Beitrag 1503076)

.. haste vorher aber schon mal gelesen oder?

Was erwartest Du? Dass die Formatrate Funktion berücksichtigt, dass es nur Deutsche Städte in der Liste ergibt? "ach sie mal, Dresden, Köln, Berlin, ..alles Deutsche Städte, dann ist die Spalte hier bestimmt ne PLZ und die sind in D auch mit führender Null", weil Formatraten auch die Internationalen PLZ Regeln kennt?
Und was glaubst Du, was das Formatraten macht? Es prüft vermutlich, ob sich alle Werte in ein Integer oder Float verwandeln lassen. Vielleicht sogar nur bei einem Teil der Daten und nicht bei allen 50 oder 100T Records.

Und zuletzt, wenn Du das Format kennst, wieso lässt Du es raten?

[KodeZwerg]

Ich kenne mich mit der Komponente nicht aus, vielleicht kannst Du auch ein simples "str := Format('%.*d, [5, PlzInteger]);" um deine Zahlen immer als 5-stellig darzustellen dazwischen quetschen?

[fisipjm]

Zitat:

Zitat von jobo (Beitrag 1503079)

Zitat:

Zitat von fisipjm (Beitrag 1502996)

.. Ja, es sind nur Zahlen, aber es wäre doch ein leichtes bei einer führenden 0 die Erkennung auf String zu setzen. In meinen Augen ein Bug im System.

Zitat:

Zitat von fisipjm (Beitrag 1503076)

.. haste vorher aber schon mal gelesen oder?

Was erwartest Du? Dass die Formatrate Funktion berücksichtigt, dass es nur Deutsche Städte in der Liste ergibt? "ach sie mal, Dresden, Köln, Berlin, ..alles Deutsche Städte, dann ist die Spalte hier bestimmt ne PLZ und die sind in D auch mit führender Null", weil Formatraten auch die Internationalen PLZ Regeln kennt?
Und was glaubst Du, was das Formatraten macht? Es prüft vermutlich, ob sich alle Werte in ein Integer oder Float verwandeln lassen. Vielleicht sogar nur bei einem Teil der Daten und nicht bei allen 50 oder 100T Records.

Und zuletzt, wenn Du das Format kennst, wieso lässt Du es raten?

Moin,
Ich glaube du hast mich falsch verstanden. Ich will das es als String erkannt wird wenn eine führende 0 existiert. Man kann der Komponente sagen wie viele Sampels ich aus der Datei haben will, die kenne ich, ich weis ja wie lange die Datei ist wenn ich sie hab.
Das eine Zahl (Unabhängig ob PLZ oder was anderes) mit einer führenden 0 keinem Integer entspricht ist doch eigentlich nachvollziehbar oder? Natürlich kann man argumentieren "Es sind aber alles Zahlen und ich kann es in ein Integer Werfen".
Um es mal in die Reale welt zu bringen, wenn jemand kommt und wirft dir 500 ° ohne Skala Einheit an den Kopf kannst du ja trotzdem auch schon drauf schließen, dass es sich hier wahrscheinlich nicht um eine Winkelangabe handelt. Genau so sollte ein Guessing in der Lage sein zu erkkenen das eine Zahl mit einer Führenden 0 kein Integer ist!

Das Guessing mache ich weil ich das Format nicht kenne. Das waren nur Testdaten.