Einfügen über externalTabelle funktioniert nicht richtig

[Dejan Vu]

Externe Tabellen sind nicht dazu da, die Daten in einer endgültigen Form zu enthalten. Sie dienen nur zum Import. Du beschreibst also mit dem 'CREATE TABLE' nur den Aufbau deiner Datei und importierst sie dann in eine andere Tabelle, wobei Du die notwendigen Transformationen vornimmst (Char => Integer, Float, DateTime etc.). Aus diesem Grund ist es auch überflüssig und falsch, einen Autoinc Wert in der externen Tabelle vorhalten zu wollen.

[blutigerAnfänger]

Zitat von Dejan Vu:

..., wobei Du die notwendigen Transformationen vornimmst (Char => Integer, Float, DateTime etc.). Aus diesem Grund ist es auch überflüssig und falsch, einen Autoinc Wert in der externen Tabelle vorhalten zu wollen.

Notwendige Transformationen sind das Stichwort.
String --> CHAR --> VARCHAR
INTEGER --> ??? --> INTEGER

Also Ich habe eine Tabelle mit 3 Feldern (Integer, String, String). Die Stringfelder werden als CHAR bezeichnet und in der endgültigen Firebird Tabelle zu VARCHAR transformiert. Wie mache ich das mit Integer?
INTEGER zu CHAR gibt es Konversionsfehler und INTEGER mit Längenbezeichnung zB. INTEGER(10) ist Blödsinn.

[jobo]

Zitat von Dejan Vu:

Externe Tabellen sind nicht dazu da, die Daten in einer endgültigen Form zu enthalten. Sie dienen nur zum Import. Du beschreibst also mit dem 'CREATE TABLE' nur den Aufbau deiner Datei und importierst sie dann in eine andere Tabelle, wobei Du die notwendigen Transformationen vornimmst (Char => Integer, Float, DateTime etc.). Aus diesem Grund ist es auch überflüssig und falsch, einen Autoinc Wert in der externen Tabelle vorhalten zu wollen.

Ich möchte noch ergänzen, dass das Bedürfnis nach einer eindeutigen ID natürlich legitim ist. Was und wie Du aber auch immer importierst, die zu importierenden Daten sollten über solch ein eindeutiges Merkmal bereits verfügen, notfalls über mehrere Felder und idealer Weise auch gegenüber den bereits importierten Daten. Ansonsten holst Du Dir die Leichen reihenweise in den Keller.

Schau Dir mal Literatur zum Thema ETL an. Ganz grob:
Daten temporär in der DB bereitstellen (z.B. via ExternalTable)
Daten aufbereiten (z.B. Dubletten entfernen, plus Rückmeldung / Log)
Daten dann mit System-/Produktivdaten abgleichen und ggF. importieren.
Dabei gehst Du sehr wahrscheinlich Satz für Satz durch die neuen Daten und schaust wo und wie Du sie unterbringst. (Wiederum mit Rückmeldung bzw. Log für automatisierte Prozesse)

Konvertierung:
Es ist stark anzunehmen, dass Deine CSV Daten im Klartext dort stehen und Integer bspw nicht 2 oder 4 Byte binär codiert sind.
Also Integer auch als Varchar einlesen mit Längenangabe entsprechend dem CSV.
P.S.: Wenn Du aus der DB dann auf die "integer" Daten zugreifst, musst Du konvertieren.
Also beim Insert in die Zieltabelle z.B..

[blutigerAnfänger]

Zitat von jobo:

Ich möchte noch ergänzen, dass das Bedürfnis nach einer eindeutigen ID natürlich legitim ist. Was und wie Du aber auch immer importierst, die zu importierenden Daten sollten über solch ein eindeutiges Merkmal bereits verfügen, notfalls über mehrere Felder und idealer Weise auch gegenüber den bereits importierten Daten. Ansonsten holst Du Dir die Leichen reihenweise in den Keller.

Schau Dir mal Literatur zum Thema ETL an. Ganz grob:
Daten temporär in der DB bereitstellen (z.B. via ExternalTable)
Daten aufbereiten (z.B. Dubletten entfernen, plus Rückmeldung / Log)
Daten dann mit System-/Produktivdaten abgleichen und ggF. importieren.
Dabei gehst Du sehr wahrscheinlich Satz für Satz durch die neuen Daten und schaust wo und wie Du sie unterbringst. (Wiederum mit Rückmeldung bzw. Log für automatisierte Prozesse)

Konvertierung:
Es ist stark anzunehmen, dass Deine CSV Daten im Klartext dort stehen und Integer bspw nicht 2 oder 4 Byte binär codiert sind.
Also Integer auch als Varchar einlesen mit Längenangabe entsprechend dem CSV.
P.S.: Wenn Du aus der DB dann auf die "integer" Daten zugreifst, musst Du konvertieren.
Also beim Insert in die Zieltabelle z.B..

Zum 1ten Absatz:
Also am besten mit einem 2ten Integer Feld (in dem bereits die Autoinc enthalten ist)??

zum 2ten Absatz:
Nenn mir doch mal eine deutschsprachige Literatur zum Thema ETL (externalTabelle?), welche möglichst einfach gehalten ist. Vielleicht gibt's da noch etwas was ich bei meiner Recherche übersehen habe.

zum 3tenAbsatz (Konvertierung):
Anbei zwei Screenshots, beide zeigen die Ergebnisse der external Tabelle aus IBexpert personnel.
Der eine Screenshot zeigt das Importergebnis von CHAR, der andere das Importergebnis von VARCHAR an beide mit Länge 10.

[mkinzler]

Und wie sieht die Datei aus?

[jobo]

Zitat von blutigerAnfänger:

Zum 1ten Absatz:
Also am besten mit einem 2ten Integer Feld (in dem bereits die Autoinc enthalten ist)??

zum 2ten Absatz:
Nenn mir doch mal eine deutschsprachige Literatur zum Thema ETL (externalTabelle?), welche möglichst einfach gehalten ist. Vielleicht gibt's da noch etwas was ich bei meiner Recherche übersehen habe.

zum 3tenAbsatz (Konvertierung):
Anbei zwei Screenshots, beide zeigen die Ergebnisse der external Tabelle aus IBexpert personnel.
Der eine Screenshot zeigt das Importergebnis von CHAR, der andere das Importergebnis von VARCHAR an beide mit Länge 10.

Ich weiß nicht, warum es ein 2tes Integerfeld sein muss. Was am besten ist, weiß ich auch nicht, es kommt auf Deine Daten an. Wenn die eindeutige Merkmale enthalten, kannst Du diese Spalten für den eindeutigen Zugriff nutzen

ETL beschreibt den Vorgang ExtractLoadTransform oft verwendet in Datawarehouse Systemen:
http://de.wikipedia.org/wiki/ETL-Prozess

Sieht so aus, als ob Deine Längenangaben nicht zur CSV Datei passen. Feld-Trennzeichen wird mitgelesen oder so.

[blutigerAnfänger]

Zitat von mkinzler:

Und wie sieht die Datei aus?

Zitat von jobo:

Ich weiß nicht, warum es ein 2tes Integerfeld sein muss. Was am besten ist, weiß ich auch nicht, es kommt auf Deine Daten an. Wenn die eindeutige Merkmale enthalten, kannst Du diese Spalten für den eindeutigen Zugriff nutzen

ETL beschreibt den Vorgang ExtractLoadTransform oft verwendet in Datawarehouse Systemen:
http://de.wikipedia.org/wiki/ETL-Prozess

Sieht so aus, als ob Deine Längenangaben nicht zur CSV Datei passen. Feld-Trennzeichen wird mitgelesen oder so.

Meine Testtabelle mit fixer Länge(wie external Table vorschreibt): Das erste Feld Integer mit 10 Zeichen Länge, Das zweite Feld STring bzw.Char(nach Vorschrift) mit Länge 50, Das dritte Feld String bzw. Char mit 250er Länge.

[Dejan Vu]

CSV? Ich lese immer CSV... Kann Firebird das denn? So wie ich das verstanden habe, muss die Textdatei feste Breiten haben... Oder geht das etwa?

[jobo]

Zitat von Dejan Vu:

CSV? Ich lese immer CSV... Kann Firebird das denn? So wie ich das verstanden habe, muss die Textdatei feste Breiten haben... Oder geht das etwa?

Ich glaube nur feste Breite. CSV ist scheinbar der schlampige Standardbegriff für alles was Daten lesbar in Textform enthält.

Mein Hinweis mit den micht berücksichtigten Spaltentrennzeichen war dementsprechend daneben.

Aber die Datei ist ja offenbar fixed length. Sollte also in Ordnung sein.
Eine Zeile 310 Bytes, mit Umbrauch 312.