Datenverbindung zu täglich neu erstellter csv-Datei?

[Lascar]

Ich habe aus den ersten 3 Zeilen einen Dummy gemacht (ohne Formatierungen zu ändern).

[DbSam]

kurze Zwischenfrage:

Hallo Lascar,

bist Du Dir sicher, dass Du keine Formatierungen geändert hast?

Ich rede hier von den doppelten Anführungszeichen, diese sind so nicht korrekt gesetzt.
Ebenso enthält die Datei unterschiedliche Zeichensätze. Wobei ich davon ausgehe, dass der Zeichensatz der ersten Zeile der Originaldatei entspricht.

Bitte schicke eine csv-Datei welche nur die erste Zeile mit den Spaltennamen enthält.
Also nur die Zeilen löschen und sonst nicht drin herum malen!




Gruß Carsten

[shift-del]

Hier wäre mein Code:

Code:

let
    Quelle = Table.FromColumns({Lines.FromBinary(File.Contents("D:\Upload_artikel.csv"), null, null, 65001)}),
    #"Spalte nach Trennzeichen teilen" = Table.SplitColumn(Quelle,"Column1",Splitter.SplitTextByDelimiter(",", QuoteStyle.None),{"Column1.1", "Column1.2", "Column1.3", "Column1.4", "Column1.5", "Column1.6", "Column1.7", "Column1.8", "Column1.9", "Column1.10"}),
    #"Geänderter Typ" = Table.TransformColumnTypes(#"Spalte nach Trennzeichen teilen",{{"Column1.1", type text}, {"Column1.2", type text}, {"Column1.3", type text}, {"Column1.4", type text}, {"Column1.5", type text}, {"Column1.6", type text}, {"Column1.7", type text}, {"Column1.8", type text}, {"Column1.9", type text}, {"Column1.10", type text}}),
    #"Ersetzter Wert" = Table.ReplaceValue(#"Geänderter Typ","""","",Replacer.ReplaceText,{"Column1.1"}),
    #"Ersetzter Wert1" = Table.ReplaceValue(#"Ersetzter Wert","""""","",Replacer.ReplaceText,{"Column1.3", "Column1.4", "Column1.5", "Column1.6", "Column1.7", "Column1.8", "Column1.9", "Column1.10"}),
    #"Höher gestufte Header" = Table.PromoteHeaders(#"Ersetzter Wert1", [PromoteAllScalars=true]),
    #"Geänderter Typ mit Gebietsschema" = Table.TransformColumnTypes(#"Höher gestufte Header", {{"Datum", type date}}, "en-US"),
    #"Geänderter Typ mit Gebietsschema1" = Table.TransformColumnTypes(#"Geänderter Typ mit Gebietsschema", {{"Preis", type number}, {"Gebühr 1", type number}, {"Gebühr 2", type number}, {"Gebühr 3", type number}, {"Gebühr 4", type number}, {"Gebühr 5", type number}}, "en-US")
in
    #"Geänderter Typ mit Gebietsschema1"

Es gibt aber zwei Fehler:
In Spalte Preis steht ein Text. In Spalte Gebühr 1 steht ein Datum.

[Lascar]

@DbSam: Hm, wenn ich "Text in Spalten" mache nachdem ich die Dummy CSV in Excel geöffnet habe, passen alle Spaltenüberschriften zu den darunterstehenden Werten. Ich sehe auch kein doppeltes Anführungszeichen.

@shift-del: Danke für den Code! Ich nehme an der soll unter "Erweiterter Editor" eingefügt werden? Ich bekomme hier leider (ob mit "ü" oder mit "ü"): "Expression.Error: Die Spalte "Gebühr 1" der Tabelle wurde nicht gefunden.
Details:
    Gebühr 1"

Und sind die zwei von Dir angesprochenen Fehler in der zugrundeliegenden CSV oder nach Code-Ausführung?

[shift-del]

Du musst natürlich den Pfad und den Dateinamen anpassen.

Die beiden Fehler sind bereits in der CSV-Datei enthalten und werden im Query Editor nach der Code-Ausführung als Error gekennzeichnet.

[DbSam]

Hallo zurück,

wenn ich Deine hochgeladene Beispieldatei mit dem Editor öffne, dann sieht diese so aus:
   

... die Setzung der Anführungszeichen entsprechen nicht den Regeln einer CSV-Datei und ebenso ist die Textkodierung unterschiedlich.
Deshalb meine Frage/Bitte.

So wie die Anführungszeichen im Moment gesetzt sind, besteht die CSV-Datei aus einer einzigen Spalte.
Wenn man Textfelder mit Anführungszeichen begrenzt, dann müssen die Anführungszeichen am Anfang und Ende bei jedem Textfeld stehen, dann folgt das Trennzeichen. Doppelte Anführungszeichen werden nach dem Import als ein Anführungszeichen angezeigt.
Beispiel: "Gaststätte ""Zum Brummbär""" wird zu: Gaststätte "Zum Brummbär"

Ein Komma als Trennzeichen wird bei Dezimalzahlen problematisch. Deshalb wäre ein anderes Trennzeichen besser, oder man muss die Zahlen auch mit Anführungszeichen einrahmen und später konvertieren.

Also eine bessere, den CSV-Regeln entsprechend aufgebaute CSV-Datei macht Dir das spätere Einlesen wesentlich leichter.
Das wäre so meine Meinung zu Deiner Datei...



Gruß Carsten

[DbSam]

Die beiden Fehler sind bereits in der CSV-Datei enthalten und werden im Query Editor nach der Code-Ausführung als Error gekennzeichnet.

Hallo Umschalttastenlöscher,

Deine Code ist etwas fehlerhaft, weil Du anscheinend dieses Feld falsch einliest: ""Artikel2 Name, enthält Komma"" und dann mit den Spalten durcheinander kommst.
Wenn man die Spalten der CSV-Datei per Hand abzählt und die Anführungszeichen etwas willig auslegt, dann stimmen die Felder mit der Kopfzeile überein.

Der Aufbau der CSV-Datei widerspricht halt jeder gängigen Regel und da liegt das Problem.
Hier irgendwelche Workarounds zu integrieren ist falsch. Der Hebel muss weiter vorn bei der CSV Erstellung angesetzt werden. (Wenn die originale CSV-Datei ebenso katastrophal strukturiert sein sollte.)


Gruß Carsten

[shift-del]

Hallo Carsten

Ja, vermutlich sind deine Anmerkungen bezüglich der 'falschen' CSV-Struktur richtig und deshalb gibt es das Durcheinander.
Aber da muss der Fragesteller nachbessern.

[DbSam]

Hallo  S-Del,

ja, die ist zu 100% falsch.
Und gerade deshalb, weil mit Komma als Trennzeichen gearbeitet wird und Textfelder auch ein Komma enthalten dürfen.
Also muss ein Textfeld mit Texterkennungszeichen (dieses Zeichen ist auch definierbar) gekennzeichnet werden - und das aber richtig. Siehe dazu auch meine Ausführungen weiter oben.
Wenn die Texterkennung richtig gesetzt ist, dann muss man die Spalten nicht mit 'SplitTextByDelimiter' mühsam definieren müssen ...
 

Ich weiß eben nicht ob die Datei schon so falsch aussieht, oder ob dieser Fehler Lascar beim Aufbereiten der Datei passiert ist.

Deshalb wollte ich wenigstens mal die originale und unbearbeitete Kopfzeile sehen.




Gruß Carsten

[Lascar]

Hallo, danke für die Rückmeldungen, und sorry für das Chaos in der Dummy csv. Bezüglich des Codes hatte ich natürlich Pfad, Dateiname und Spaltennamen angepasst. Glaube hier könnte das "ü" Probleme machen - das ist dummerweise in der CSV so vorgegeben.

Diese Fehler mit doppelten Anführungszeichen sind in der originalen Datei nicht enthalten, die habe ich irgendwie produziert als ich die csv in Excel bearbeitet und als csv gepeichert habe. Excel macht das allerdings jedesmal beim Speichern als .csv, wenn ich die Anführungszeichen im Texteditor lösche meldet Excel im Anschluss dass es kein gültiges Format mehr sei.

Kopfzeile ist, wenn ich die Dummy-Datei in Excel öffne:
ID_1,ID_2,Name,Preis,Datum,"Gebühr 1","Gebühr 2","Gebühr 3","Gebühr 4","Gebühr 5","Gebühr 6",Menge

Excel kommt damit selbst offenbar zurecht. Wenn ich "Externe Daten abrufen" mache und den Text mit Trennzeichen Komma in Spalten aufteilen lasse, funktioniert ja auch alles. Keine Ahnung, warum Power Query dagegen die Werte um den Faktor 100 zu hoch ausgibt.

/€: Asche über mein Haupt. In der ursprünglichen Excel war bei Datenverbindungen aus irgendeinem Grund auf einmal der Haken bei "Beim Aktualisieren Dateinamen bestätigen" gesetzt - deswegen hat Excel vermutlich überhaupt erst nach der Quelle gefragt. Die ursprüngliche Fragestellung hat sich damit dann wohl erledigt. Das mit Power Query interessiert mich aber weiterhin: sowohl der Fehler dessen Ursache ich nicht verstehe, als auch Power Query an sich. Man will ja stetig seinen Horizont erweitern (: