PostgreSQL "INSERT "

Alles zum SQL-Dialekt

Moderator: Moderatoren

Antworten
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 11298
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg

PostgreSQL "INSERT "

Beitrag von AUGE_OHR » Sa, 30. Jun 2012 8:31

hi,

ich sehe in Hector Code

Code: Alles auswählen

METHOD XbTable:Insert( )
local cSql   :=   "INSERT INTO " + ::cTable + " ("
soweit klar und dann kommt

Code: Alles auswählen

      IF  aData[i] <> nil .AND. !(nAND( ::aStructSql[i][MYSQL_FS_FLAGS], AUTO_INCREMENT_FLAG) == AUTO_INCREMENT_FLAG)
          cSql +=  ::aStructSql[i][MYSQL_FS_NAME] +","
      endif
wie bekomme ich "das" den nach PostgreSQL ... oder haben SQL Table dafür "intern" ein "Feld" ?

Frage : wenn man nun eine ganze DBF nach SQL "schieben" will ... muss ich für jeden Record "einzeln" ein "INSERT " machen oder gibt es da noch was anderes ?
gruss by OHR
Jimmy

Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 11298
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg

Re: PostgreSQL "INSERT "

Beitrag von AUGE_OHR » Di, 03. Jul 2012 7:09

hi,

es sieht wohl so aus das Hector die MySQL Flags benutzt aber die für PostgreSQL nicht relevant sind.
das was ich für "interne" PG Fields ( die "__"fields) hielt sind wohl vom DbfUpsize.EXE Tool angelegt worden.

btw. schon mal DbfUpsize.EXE auf eine grössere DBF losgelassen ? es werden mehrere Progressbar angezeigt ...

leider "versagt" es bei mir ( mit Thread Problemen ? ) sodass ich doch per "INSERT ..." jeden Record einzeln einfügen muss.
die Geschwindigkeit beim "INSERT ..." ist dabei erstaunlich schnell ... normale HD, keine SSD.
ok ohne "Index" aber auch das kopieren der grossen DBF auf eine andere HD würde nicht viel schnell sein ... PG Cache ?
gruss by OHR
Jimmy

Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 11298
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg

Re: PostgreSQL "INSERT "

Beitrag von AUGE_OHR » Mi, 04. Jul 2012 18:44

hi,

ich bekomme jetzt ja nun eine DBF in eine PostgreSQL Table. nun hab ich ein Logfile mitlaufen lassen und sehe ja für jeden "Record" mein "INSERT ..." Befehl.

Code: Alles auswählen

INSERT INTO FSICHER2 VALUES(560818, '24415', '05', 1024, '2309E', 'Curry, Englisch', 1.00, 'Pkt', 9.95, '1kg', 7, '2', 9.95, 0.00, '12', '04', '05', '12', 'Liefer Datum vom 04.05.12', 'N', '01198', 'L', '', '201201688')
Frage : wenn ich von einer andern Application z.b. Excel die Daten haben möchte wie mache ich auf eine XLS einen "Import" ?

ich meine jetzt ohne Xbase++.
wenn ich Excel, per Macro, dazu bringe die "INSERT " Befehle in eine Datei zu schreiben ... dann könnte ich doch jede Zeile einzeln als SQL Befehl abschicken, oder ?
gruss by OHR
Jimmy

Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 14466
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Kontaktdaten:

Re: PostgreSQL "INSERT "

Beitrag von brandelh » Do, 05. Jul 2012 0:59

Hallo Jimmy,

wenn man aus dem Verwaltungsprogramm vom SQL Server heraus einen Komplettbackup der Datenbank erzeugt,
erhält man zumindest bei MySQL ein SQL Script, das die DB anlegt und alle Datensätze einliest.
Wenn man nun viele Daten einlesen will, braucht man nur die Erzeugung der DB und die vorhandenen Datensätze weglassen.
Die Syntax der Datenübernahme mit den neuen Daten und der Server kann die Daten importieren - atemberaubend schnell :D
Gruß
Hubert

Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 11298
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg

Re: PostgreSQL "INSERT "

Beitrag von AUGE_OHR » Do, 05. Jul 2012 1:48

brandelh hat geschrieben:Die Syntax der Datenübernahme mit den neuen Daten und der Server kann die Daten importieren - atemberaubend schnell :D
gut, genau darauf wollte ich hinaus.

in meiner ersten Import Version hatte ich eine ähnliche Geschwindigkeit wie DbfUpsize.EXE (mit einem Thread).
nachdem ich jedoch weitere Abfragen wegen "Umlauten", "€" Euro Zeichen oder "\" eingebaut habe wird es immer langsamer.
( ca. 800 statt >1400 Rec/sec, 33 Felder mit 278 byte/Rec., P4 3GHz )

ich hatte zunächst angenommen das ein falsche "INSERT ..." Befehlt einen "Absturz" verursachen sollte...
tut er nicht und es sind dann auch keine Daten in der Table. vielmehr gibt er immer .T. zurück
dann entdeckte ich die PG "Logfiles" und das "\" Problem ...

ein solche Problem beim Import zu identifizieren könnte schwierig werden.
Wenn ich ein "Skript" dazwischen schiebe könnte ich wohl auch schneller identifizieren in welchem Teil das Problem liegt.

mal sehen was pgDBE dann "bringt" wenn APPEND / DbCommit funktioniert mit mehr als "paar" Datensätzen hintereinander
( einzelnes "save" klappt soweit ) und wie Alaska das "\" Problem löst.
gruss by OHR
Jimmy

Antworten