Bulk-Import

[hoefi]

Hallo jobo,

hier mein Ansatz.
1. Erzeugen der CSV-Datei (hier aus einer HANA-DB) in Delphi:

Delphi-Quellcode:

    laenge[0]  := 8;     // Laengenvorgabe der Ausgabefelder
    laenge[1]  := 12;
    laenge[2]  := 8;
    laenge[3]  := 8;
    laenge[4]  := 4;
    laenge[5]  := 16;
    laenge[6]  := 32;
    laenge[7]  := 24;
    laenge[8]  := 160;
    laenge[9]  := 80;
    laenge[10] := 12;
    laenge[11] := 8;
    laenge[12] := 8;
    laenge[13] := 8;
    datei := 'C:\temp\qamv1.csv'; // Ausgabedatei
    AssignFile(dd,datei);
    REWRITE(dd);
    WITH H2R_Query DO
      BEGIN
       CLOSE;
       SQL.CLEAR;
       SQL.Add('SELECT C.PRUEFLOS, C.VORGLFNR, C.MERKNR, C.SATZSTATUS, C.QPMK_WERKS, C.VERWMERKM, C.MKVERSION, C.KURZTEXT, C.DUMMY20, C.MASSEINHSW, C.SOLLWERT, C.TOLERANZOB, C.TOLERANZUN');
       SQL.Add('FROM QALS Q, QAMV" C');
       SQL.ADD('WHERE Q.WERK = ''XXXX'' AND');
       SQL.ADD(' C.PRUEFLOS = Q.PRUEFLOS AND');
       SQL.ADD(' Q.ERSTELDAT >= TO_DATE(''01.01.2010'',''dd.mm.yyyy'')');
       OPEN;                     // holen der Daten
       i := 0;
       WHILE NOT EOF DO
         BEGIN
           s  := IntToStr(i);
           WHILE LENGTH(s) < 8 DO s := '0' + s;      // ID als Integer darstellen
           st := '';
           FOR j := 0 TO Fields.Count - 1 DO                            // Felder anpassen
             BEGIN
               st := Fields[j].AsString;
               WHILE LENGTH(st) < lae[j+1]  DO st := st + ' ';
               IF Fields[i].DataType IN [ftFloat, ftCurrency, ftSingle]
                 THEN WHILE POS(',',st) > 0 DO st[POS(',',st)] := '.'; // numerische Felder einen Punkt als Dezimaltrenner geben
               s := s +  st;
             END;
             WRITELN(dd,s);
           INC(i);
           IF i = max_anz THEN BREAK;
           NEXT;
         END;
      END;
    CloseFile(dd);

2: Definition der externen Tabelle in FB:

SQL-Code:

CREATE TABLE QAMV_TEXT EXTERNAL 'C:\TEMP\QAMV1.CSV' (
    ID          CHAR(8),
    PRUEFLOS    CHAR(12),
    VORGLFNR    CHAR(8),
    MERKNR      CHAR(8),
    SATZSTATUS  CHAR(4),
    QPMK_WERKS  CHAR(16),
    VERWMERKM   CHAR(32),
    MKVERSION   CHAR(24),
    KURZTEXT    CHAR(160),
    DUMMY20     CHAR(80),
    MASSEINHSW  CHAR(12),
    SOLLWERT    CHAR(8),
    TOLERANZOB  CHAR(8),
    TOLERANZUN  CHAR(8),
    LFCR        CHAR(2)
);

3: Definition der Zieltabelle in FB:
CREATE TABLE QAMV (
    ID          INTEGER,
    PRUEFLOS    CHAR(12),
    VORGLFNR    INTEGER,
    MERKNR      INTEGER,
    SATZSTATUS  VARCHAR(4),
    QPMK_WERKS  VARCHAR(16),
    VERWMERKM   VARCHAR(32),
    MKVERSION   VARCHAR(24),
    KURZTEXT    VARCHAR(160),
    DUMMY20     VARCHAR(80),
    MASSEINHSW  VARCHAR(12),
    SOLLWERT    DOUBLE PRECISION,
    TOLERANZOB  DOUBLE PRECISION,
    TOLERANZUN  DOUBLE PRECISION,
    LFCR        CHAR(2)
);

4: Stored Procedure für das Übertragen der externen Tabelle in die Zieltabelle:

SQL-Code:

create or alter procedure QAMV_WANDELN
as
begin
  insert into qamv
    select * from QAMV_TEXT;
end

Was ich nicht berechnet habe, ist das anschließende Erzeugen des Indexes.
Werde heute mal probieren, weitere Tabellen ebenso zu übertragen.

[jobo]

Brauchst Du die CRLF Spalte wirklich im Ziel? Das ist doch eine Import Krücke oder?

Die ID kannst Du doch auch innerhalb der DB erzeugen, das spart extra Programmcode und macht es flexibler.

Und was die Konvertierung angeht, auch die würde ich bereits im Select Statement machen, bei Zahlen gleich mit der Längenformatierung, bei Text mit Padding, spart noch mehr Code und macht das Codestück universeller.

[hoefi]

Hallo jobo,

in der Zieltabelle ist das LFCR-Feld nicht nötig, sondern praktisch, wenn man die StoredProcedure mit "SELECT *" verwenden will. Falls man die Felder für den Select und Insert ausschreibt, kann man darauf verzichten.

Die ID habe ich absichtlich nicht per Trigger und Generator automatisch erzeugen lassen, da ich die Geschwindigkeit erreichen will und erstmal auf alles Reduzierende verzichte.

[jobo]

Zitat:

Zitat von hoefi (Beitrag 1455687)

in der Zieltabelle ist das LFCR-Feld ..praktisch, wenn man die StoredProcedure mit "SELECT *" verwenden will. ..

Die ID habe ich absichtlich nicht per Trigger und Generator automatisch erzeugen lassen, da ich die Geschwindigkeit erreichen will und erstmal auf alles Reduzierende verzichte.

Ok, praktisch find ich gut. :)
Das kann ja für jeden anders ausfallen.

Zur Performance:
Ich kann mir nicht vorstellen, dass die Nutzung einer Sequenz sich negativ auswirkt. Z.B. so (ohne ID as dem Textfile, sondern aus der Sequenz):

Code:

insert into qamv 
  select NEXT VALUE FOR <SequenceName> ,qt.* from QAMV_TEXT qt;

Ein Trigger ist für den reinen Import unnötig. Das zu importierende Textfile dürfte ohne ID sogar ein gute Stück kleiner sein.

[mkinzler]

Zitat:

Zur Performance:
Ich kann mir nicht vorstellen, dass die Nutzung einer Sequenz sich negativ auswirkt. Z.B. so (ohne ID as dem Textfile, sondern aus der Sequenz):

Da es wohl weitere Tabellen gibt u.U. auch FK verwendet werden würde ich auch die vorhandenen mitnehmen und die Sequenzen anschliessend händisch setzen.

Zitat:

Werde heute mal probieren, weitere Tabellen ebenso zu übertragen.

[jobo]

Ich meine, im Export-Code hätte er eine ID erzeugt. Das ginge halt auch billiger.
Wenn Refconstraints da sind, müssen si enatürlich so wie sie vorliegen importiert werden.

[himitsu]

Bei
[SQL]INSERT INTO tabelle
SELECT ...[/SQL]
Müssen natürlich auch die Felder der Quelle und des Ziels übereinstimmen, vor allem in Anzahl und Reihenfolge.
Die Zielfelder mit anzugeben kann da auch nie schaden.

[mkinzler]

Zitat:

Zitat von himitsu (Beitrag 1455720)

Bei
[SQL]INSERT INTO tabelle
SELECT ...[/SQL]
Müssen natürlich auch die Felder der Quelle und des Ziels übereinstimmen, vor allem in Anzahl und Reihenfolge.
Die Zielfelder mit anzugeben kann da auch nie schaden.

Ist gegeben Siehe #11

[himitsu]

Aber auch nur wenn beide Tabellen gleichzeitig erstellt werden, bzw. die neue Tabelle beim Erstellen den Aufbau der Anderen erbt.
Es wurde ja nirgends gesagt, ob das Ziel nicht eine bereits bestehende Tabelle/Datenbank sein könnte, wo über die Jahrzehnte fleißig Felder ein-/ausgebaut wurden (ALTER TABLE). :angle:

[jobo]

Es geht ja offensichtlich um einen adhoc Prozess und anhand der Antworten des TE darf man annehmen, dass die Problematik geläufig ist.