DBF zu PostgreSQL
Moderator: Moderatoren
DBF zu PostgreSQL
Guten Tag liebe X-Baseler,
wir haben vor kurzer Zeit noch die alte Version 1.9 verwendet , sind jetzt aber auf Version 2 umgestiegen.
Jetzt meine Frage gibt es wo eine einfache Beschreibung wie man dies umsetzten kann:
"PostgreSQL ISAM Datenbank-Upsizing aus bestehenden dbf-/ntx-/cdx-basierte Anwendungen werden mit wenigen Änderungen echte PostgreSQL Client/Server-Lösungen".
Danke für eure Hilfe,
Grüße Siggy
wir haben vor kurzer Zeit noch die alte Version 1.9 verwendet , sind jetzt aber auf Version 2 umgestiegen.
Jetzt meine Frage gibt es wo eine einfache Beschreibung wie man dies umsetzten kann:
"PostgreSQL ISAM Datenbank-Upsizing aus bestehenden dbf-/ntx-/cdx-basierte Anwendungen werden mit wenigen Änderungen echte PostgreSQL Client/Server-Lösungen".
Danke für eure Hilfe,
Grüße Siggy
- brandelh
- Foren-Moderator
- Beiträge: 15689
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 65 Mal
- Danksagung erhalten: 33 Mal
- Kontaktdaten:
Re: DBF zu PostgreSQL
Ich meine die zeigen das im Beispiel der M$ Anwendung ... northwind-customers
eingene Dokumente:
C:\Users\...\Documents\Xbase++\source\samples\sql\xbpbrowse
wobei ich den Upsize nicht nutze.
eingene Dokumente:
C:\Users\...\Documents\Xbase++\source\samples\sql\xbpbrowse
wobei ich den Upsize nicht nutze.
Gruß
Hubert
Hubert
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2513
- Registriert: Mi, 28. Jul 2010 17:16
- Hat sich bedankt: 12 Mal
- Danksagung erhalten: 77 Mal
Re: DBF zu PostgreSQL
Hallo Siggy
UpSize bezw. die Beispiele wurden für eine mittelerweile überholte Postgres Version erstellt. Je nach Server-Plattform ist diese z.T. sogar nicht mehr verfügbar. Durch die änderungen in den Postgres Versionen funktioniert das upsize Tool nicht mehr einwandfrei bezw. gar nicht. Auch das öffnen einer grossen Datenbank kann mit der Postgres DBE von Alaska durchaus bis zu 30 Sekunden dauern.
ich würde momentan bei DBE/NTX oder ADS bleiben oder den Postgres / SQL Datenbankzugriff mit DLL-Aufrufen bezw. mit Hilfe der libpq4xb (findest du hier im Bord) als Grundlage auf native Art erstellen.
Der native Weg ist sehr steil und beschwerlich aber du wirst mit einer Performance belohnt die du dir jetzt gar nicht vorstellen kannst. Ein mit "set filter" vergleichbarer Aufruf auf eine Datenbank mit über 1 Mio. Datensätze bringt dir die gefunden 15 Datensätze in 3/100 Sekunden. Zudem lernst du so das Konzept von SQL Kennen und kannst jederzeit über sämtliche Postgres Funktionen verfügen welche dir die PGDBE gar nicht nicht bietet.
Die Postgres DBE bringt leider momentan nur mit kleinen Datenbeständen aktzeptable Resultate, wenn du denn das UPSize geschaft hast ......
Gruss Carlo
UpSize bezw. die Beispiele wurden für eine mittelerweile überholte Postgres Version erstellt. Je nach Server-Plattform ist diese z.T. sogar nicht mehr verfügbar. Durch die änderungen in den Postgres Versionen funktioniert das upsize Tool nicht mehr einwandfrei bezw. gar nicht. Auch das öffnen einer grossen Datenbank kann mit der Postgres DBE von Alaska durchaus bis zu 30 Sekunden dauern.
ich würde momentan bei DBE/NTX oder ADS bleiben oder den Postgres / SQL Datenbankzugriff mit DLL-Aufrufen bezw. mit Hilfe der libpq4xb (findest du hier im Bord) als Grundlage auf native Art erstellen.
Der native Weg ist sehr steil und beschwerlich aber du wirst mit einer Performance belohnt die du dir jetzt gar nicht vorstellen kannst. Ein mit "set filter" vergleichbarer Aufruf auf eine Datenbank mit über 1 Mio. Datensätze bringt dir die gefunden 15 Datensätze in 3/100 Sekunden. Zudem lernst du so das Konzept von SQL Kennen und kannst jederzeit über sämtliche Postgres Funktionen verfügen welche dir die PGDBE gar nicht nicht bietet.
Die Postgres DBE bringt leider momentan nur mit kleinen Datenbeständen aktzeptable Resultate, wenn du denn das UPSize geschaft hast ......
Gruss Carlo
Valar Morghulis
Gruss Carlo
Gruss Carlo
- Werner_Bayern
- Der Entwickler von "Deep Thought"
- Beiträge: 2120
- Registriert: Sa, 30. Jan 2010 22:58
- Wohnort: Niederbayern
- Hat sich bedankt: 29 Mal
- Danksagung erhalten: 70 Mal
Re: DBF zu PostgreSQL
Was ich zu Carols Ausführungen anmerken darf: Das Thema Geschwindigkeit gilt nur in Verbindung mit der ISAM-Emulation und großen Datenmengen.
Man muss aber nicht über
Bei Upsize kann ich auch mit der aktuellen PostgreSQL-Version 9.5 und 9.6 keine Probleme feststellen. Aber, bei großen Datenmengen stimme ich Carlo voll zu, ist ISAM-SQL derzeit nicht produktiv zu benutzen. Die Probleme habe ich aber bereits vor Monaten an Alaska gemeldet und die arbeiten dran. Einiges davon wurde inzwischen ja schon umgesetzt, siehe dazu die entsprechenden PDRs.
Man muss aber nicht über
gehen, dafür gibt es u. a. die sehr performante Xbase++ Klasse und FunktionDLL-Aufrufe oder libpq4xb
Code: Alles auswählen
DacSqlStatement
executeQuery
es grüßt
Werner
<when the music is over, turn off the lights!>
Werner
<when the music is over, turn off the lights!>
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2513
- Registriert: Mi, 28. Jul 2010 17:16
- Hat sich bedankt: 12 Mal
- Danksagung erhalten: 77 Mal
Re: DBF zu PostgreSQL
Hallo Werner
mit den
habe ich ganz am Anfang experimentiert. Hast du denn eine Beschreibung / Bespielcode wie mit diesen zu arbeiten ist?
Das was ich damals gefunden habe hat mich nicht wirklich vorwärts gebracht.
Für den Umgang mit der PGLIB bezw. DLL-Calls habe ich im Internet umfangreiche Beschreibungen in Deutscher Sprache zum arbeiten mit gefunden. In diesen fehlte der Alaska-Lieglings-Kürzel "TBD" dafür waren viele viele Beispiele verfügbar. Leider bin ich nicht Hellseher und konnte darum nicht mit den oben erwähnten Klassen und Funktionen arbeiten......... deshalb mein Tip die DLL zu verwenden.
Als ich damals upsize verwendet habe hat sich upsize gehängt, die sobald ein Feld tsvector (Volltextsuche) enthalten war. Dies, wie ich nach einigem Suchen herausfand, upsize einen den Feldtyp falsch anlegte was unter Postges 9.6 nicht mehr erlaubt war. Mit der aktuellen Xbase++ Version habe ich mehr versucht.
Vielleicht sind ja nun beide Probleme gelöst ......... Es gibt eine gute Beschreibung/Beispiele und upsize kennt die 9.6 Regeln.
Gruss Carlo
mit den
Code: Alles auswählen
DacSqlStatement
executeQuery
Das was ich damals gefunden habe hat mich nicht wirklich vorwärts gebracht.
Für den Umgang mit der PGLIB bezw. DLL-Calls habe ich im Internet umfangreiche Beschreibungen in Deutscher Sprache zum arbeiten mit gefunden. In diesen fehlte der Alaska-Lieglings-Kürzel "TBD" dafür waren viele viele Beispiele verfügbar. Leider bin ich nicht Hellseher und konnte darum nicht mit den oben erwähnten Klassen und Funktionen arbeiten......... deshalb mein Tip die DLL zu verwenden.
Als ich damals upsize verwendet habe hat sich upsize gehängt, die sobald ein Feld tsvector (Volltextsuche) enthalten war. Dies, wie ich nach einigem Suchen herausfand, upsize einen den Feldtyp falsch anlegte was unter Postges 9.6 nicht mehr erlaubt war. Mit der aktuellen Xbase++ Version habe ich mehr versucht.
Vielleicht sind ja nun beide Probleme gelöst ......... Es gibt eine gute Beschreibung/Beispiele und upsize kennt die 9.6 Regeln.
Gruss Carlo
Valar Morghulis
Gruss Carlo
Gruss Carlo
- AUGE_OHR
- Marvin
- Beiträge: 12903
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 44 Mal
Re: DBF zu PostgreSQL
Upsize.EXE arbeitet mit eine XML Datei wo du deine DBF und Index Files aufführen musst.
aber bevor das geht musst du zunächst den PostgreSQL Server aufsetzten.
bin mir jetzt nicht sicher ob du auch eine "Datenbank" (mdidemo) anlegen musst für die neuen "Table" (<- DBF)
Upsize.EXE legt beim Import einer DBF "interne" Felder in der Table an.
dito für jeden Index TAG ein Field mit dem "Inhalt" von IndexKey()
die "internen" Felder werden für die ISAM Emulation nach Alaska Design benötigt.
---
das Tool PGU.EXE*** ist mit v1.9x Compiliert und ermöglich den Import von DBF Dateien nach PostgreSQL per native DLL. ähnlich wie DBU.EXE für DBF kann man damit auf PostgreSQL Table zugreifen und diese bearbeiten/modifizieren.
*** viewtopic.php?f=16&t=6322&p=103342
---
die Werbe Aussagen von Alaska lassen Xbase++ User "denken" das sie ihre Apps mittels PgDBE :
"... mit wenigen Änderungen echte PostgreSQL Client/Server-Lösungen" werden.
aber über die Performance sagt das nun nichts aus ... insbesondere der ISAM Emulation
nun sprach Werner Universal SQL an d.h. man nutzt "nur" die "Connection" wie bei der native Lösung.
man muss nun selbst den String für eine SQL-Query erstellen welche man dann an den SQL Server schickt.
dito muss man die "Antwort" (Resultset) selbst auswerten (z.b. in ein Array überführen)
wenn man SQL verwenden will dann sollte man SQL Syntax Grundbegriffe lernen.
ich benutzte dazu PgAdmin.EXE wo ich mein SELECT so lange probieren kann bis das Ergebnis passt.
und wenn ich gar nicht mehr weiter weiss dann frage ich in Foren die auf PostgreSQL oder MySQL spezialisiert sind
gruss by OHR
Jimmy
Jimmy
- Werner_Bayern
- Der Entwickler von "Deep Thought"
- Beiträge: 2120
- Registriert: Sa, 30. Jan 2010 22:58
- Wohnort: Niederbayern
- Hat sich bedankt: 29 Mal
- Danksagung erhalten: 70 Mal
Re: DBF zu PostgreSQL
Servus Carlo,
Gibt Dir eine Adressen.dbf (read only) zurück mit dem gewünschten Ergebnis, sortiert nach Alter.
Code: Alles auswählen
oStmt := DacSqlStatement(::oSession):FromChar("select * from mydbf where name = 'meier' order by alter")
oStmt:Build():Query(USQL_RESULT_WORKAREA, "Adressen")
es grüßt
Werner
<when the music is over, turn off the lights!>
Werner
<when the music is over, turn off the lights!>
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2513
- Registriert: Mi, 28. Jul 2010 17:16
- Hat sich bedankt: 12 Mal
- Danksagung erhalten: 77 Mal
Re: DBF zu PostgreSQL
Servus Werner
habe deine 2 Zeilen getestet, läuft tatsächlich gleich schnell wie meine Native Variante mit den Ergebissen in einem Array.
Das war das lesen.
Gibt es zum schreiben/anfügen auch Befehle der Klasse oder machst du das dann mit execute() gleich wie als native Variante?
Kennst du das Gäubodenfest?
Gruss Carlo
habe deine 2 Zeilen getestet, läuft tatsächlich gleich schnell wie meine Native Variante mit den Ergebissen in einem Array.
Das war das lesen.
Gibt es zum schreiben/anfügen auch Befehle der Klasse oder machst du das dann mit execute() gleich wie als native Variante?
Kennst du das Gäubodenfest?
Gruss Carlo
Valar Morghulis
Gruss Carlo
Gruss Carlo
- Werner_Bayern
- Der Entwickler von "Deep Thought"
- Beiträge: 2120
- Registriert: Sa, 30. Jan 2010 22:58
- Wohnort: Niederbayern
- Hat sich bedankt: 29 Mal
- Danksagung erhalten: 70 Mal
Re: DBF zu PostgreSQL
Code: Alles auswählen
oStmt := DacSqlStatement(::oSession):FromChar("insert into mydbf (name, vorname) values ('Meier', 'Carlo')")
nRueck := oStmt:Build():execute()
if nRueck == 0
fehler...
endif
Ist in meiner Nähe - 1 Std. Fahrzeit... War aber noch nie dort.Gäubodenfest
es grüßt
Werner
<when the music is over, turn off the lights!>
Werner
<when the music is over, turn off the lights!>
- Werner_Bayern
- Der Entwickler von "Deep Thought"
- Beiträge: 2120
- Registriert: Sa, 30. Jan 2010 22:58
- Wohnort: Niederbayern
- Hat sich bedankt: 29 Mal
- Danksagung erhalten: 70 Mal
Re: DBF zu PostgreSQL
Update funktioniert analog zu insert. Sieht in meiner Klasse einfach so aus:
Code: Alles auswählen
method WERNERSQL:update(cBefehl)
return ::insert(cBefehl, "update")
method WERNERSQL:insert(cBefehl, cWas, cCast)
es grüßt
Werner
<when the music is over, turn off the lights!>
Werner
<when the music is over, turn off the lights!>
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2513
- Registriert: Mi, 28. Jul 2010 17:16
- Hat sich bedankt: 12 Mal
- Danksagung erhalten: 77 Mal
Re: DBF zu PostgreSQL
Servus Werner
danke, also Schreiben/ändern mit Befehlszeile wie auf native Art. Werde mal einige Versuche auf diese Art und Weise mit DacSqlStatement() machen.
Wenn du noch nie an dem Fest warst ..... war es eine Verwechslung ....
Gruss Carlo
danke, also Schreiben/ändern mit Befehlszeile wie auf native Art. Werde mal einige Versuche auf diese Art und Weise mit DacSqlStatement() machen.
Wenn du noch nie an dem Fest warst ..... war es eine Verwechslung ....
Gruss Carlo
Valar Morghulis
Gruss Carlo
Gruss Carlo
- Werner_Bayern
- Der Entwickler von "Deep Thought"
- Beiträge: 2120
- Registriert: Sa, 30. Jan 2010 22:58
- Wohnort: Niederbayern
- Hat sich bedankt: 29 Mal
- Danksagung erhalten: 70 Mal
Re: DBF zu PostgreSQL
Servus Carlo,
ja, klappt alles relativ gut, wir haben einige Anwendungen damit schon draußen. Inhouse arbeiten wir schon länger damit.
Was macht ein Schweizer im niederbayrischen Gäubodenfest?
ja, klappt alles relativ gut, wir haben einige Anwendungen damit schon draußen. Inhouse arbeiten wir schon länger damit.
Was macht ein Schweizer im niederbayrischen Gäubodenfest?
es grüßt
Werner
<when the music is over, turn off the lights!>
Werner
<when the music is over, turn off the lights!>
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2513
- Registriert: Mi, 28. Jul 2010 17:16
- Hat sich bedankt: 12 Mal
- Danksagung erhalten: 77 Mal
Re: DBF zu PostgreSQL
Servus Werner
ganz einfach ich habe Kundschaft und Freunde in der Gegend um das Fest, da geht man seit vielen Jahren einige Tage im Jahr hin....... allerdings ich nicht in Lederhosen.....
Gruss Carlo
ganz einfach ich habe Kundschaft und Freunde in der Gegend um das Fest, da geht man seit vielen Jahren einige Tage im Jahr hin....... allerdings ich nicht in Lederhosen.....
Gruss Carlo
Valar Morghulis
Gruss Carlo
Gruss Carlo
- Werner_Bayern
- Der Entwickler von "Deep Thought"
- Beiträge: 2120
- Registriert: Sa, 30. Jan 2010 22:58
- Wohnort: Niederbayern
- Hat sich bedankt: 29 Mal
- Danksagung erhalten: 70 Mal
Re: DBF zu PostgreSQL
Sag Bescheid für dieses Jahr, dann schau ich mir das als Niederbayer auch mal an
es grüßt
Werner
<when the music is over, turn off the lights!>
Werner
<when the music is over, turn off the lights!>
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2513
- Registriert: Mi, 28. Jul 2010 17:16
- Hat sich bedankt: 12 Mal
- Danksagung erhalten: 77 Mal
Re: DBF zu PostgreSQL
Servus Werner
ich weiss noch nicht welche Tage es dieses Jahr sind....
Ich habe mich nochmals mit dem dacSqlStatement() beschäftigt.
In der nicht gerade üppigen Beschreibung steht:
Gruss Carlo
ich weiss noch nicht welche Tage es dieses Jahr sind....
Ich habe mich nochmals mit dem dacSqlStatement() beschäftigt.
In der nicht gerade üppigen Beschreibung steht:
Sehe ich das richtig, dacSqlStatement darf mehrmals verwendet werde, ist aber nicht gleichzeitig in verschiedenen Threads, also z.b. nicht geeignet für einen Web-Server der mehrere Anfragen parallel verarbeitet?The statement may be used multiple times, but cannot be used concurrently from different threads.
Gruss Carlo
Valar Morghulis
Gruss Carlo
Gruss Carlo
- Werner_Bayern
- Der Entwickler von "Deep Thought"
- Beiträge: 2120
- Registriert: Sa, 30. Jan 2010 22:58
- Wohnort: Niederbayern
- Hat sich bedankt: 29 Mal
- Danksagung erhalten: 70 Mal
Re: DBF zu PostgreSQL
Servus Carlo,
so würde ich das auch lesen. Also wäre dacSqlStatement() nicht threadsave? Ich verwende das aber inzwischen aus versch. Threads, meist sogar mit der gleichen Connection. Ich frag mal bei Alaska an, wie das genau gemeint ist.
so würde ich das auch lesen. Also wäre dacSqlStatement() nicht threadsave? Ich verwende das aber inzwischen aus versch. Threads, meist sogar mit der gleichen Connection. Ich frag mal bei Alaska an, wie das genau gemeint ist.
es grüßt
Werner
<when the music is over, turn off the lights!>
Werner
<when the music is over, turn off the lights!>
- brandelh
- Foren-Moderator
- Beiträge: 15689
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 65 Mal
- Danksagung erhalten: 33 Mal
- Kontaktdaten:
Re: DBF zu PostgreSQL
Nicht Threadsave kann ich mir nicht vorstellen, die erstelle Verbindung hingegen darf nur in einem Thread verwendet werden, eine andere dort erstellte sollte erlaubt sein.
Aber Alaska fragen ist immer besser
Aber Alaska fragen ist immer besser
Gruß
Hubert
Hubert
Re: DBF zu PostgreSQL
@AUGE_OHR:
Wurde die PGu.exe mit der 9.6 Version des Postgres schon getestet?
Beim ausführen der .exe kommt bei mir immer die Fehlermeldung "Unable to load libpq.dll", ich habe die .dll jedoch in den Ordner reinkopiert.
Gruss Siggy
Wurde die PGu.exe mit der 9.6 Version des Postgres schon getestet?
Beim ausführen der .exe kommt bei mir immer die Fehlermeldung "Unable to load libpq.dll", ich habe die .dll jedoch in den Ordner reinkopiert.
Gruss Siggy
- AUGE_OHR
- Marvin
- Beiträge: 12903
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 44 Mal
Re: DBF zu PostgreSQL
bei der native Version ist es egal welche PostgreSQL Version du nimmst ... die API ändert sich NICHT (wird höchstens erweitert)
Frage : hast du eine 32bit DLL Version genommen ?
gruss by OHR
Jimmy
Jimmy
- Werner_Bayern
- Der Entwickler von "Deep Thought"
- Beiträge: 2120
- Registriert: Sa, 30. Jan 2010 22:58
- Wohnort: Niederbayern
- Hat sich bedankt: 29 Mal
- Danksagung erhalten: 70 Mal
Re: DBF zu PostgreSQL
Hier die Antwort von Alaska:
auf ein Sesssion-Objekt darf zwar für bestimmte Szenarien von unterschiedlichen Threads aus zugegriffen werden, für die meisten Anwendungszenarien ist dies jedoch nicht ratsam. Bedenken Sie zum Beispiel, dass die Session den Transaktionskontext für eine Operation bereitstellt und sich unterschiedliche Threads so gegenseitig beeinflussen können, wenn ein Session-Objekt konkurierend verwendet wird.
Jedes SQL-Statement-Objekt ist ebenfalls implizit oder explizit an eine Session geknüpft und besitzt aus diesem Grunde für normale Szenarien thread-lokalen Scope!
es grüßt
Werner
<when the music is over, turn off the lights!>
Werner
<when the music is over, turn off the lights!>
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2513
- Registriert: Mi, 28. Jul 2010 17:16
- Hat sich bedankt: 12 Mal
- Danksagung erhalten: 77 Mal
Re: DBF zu PostgreSQL
Servus Werner
Danke für deine Nachfrage und die Antwort von Alaska.
Ich bin inszwischen aus andern Gründen eigentlich auch (erneut) darauf gekommen die PG von Alaska NICHT weiter zu verwenden. Ganz einfach wegen der spärlich Dokumentierten Funktionen die z.T nicht mal funktionieren und den TBD die es überall noch gibt.
So liefert der Code
der Code
Ich entschied mich sämtliche mit dem Upsize Tool erstellten PG-Datenbanken zu löschen und neu zu erstellen diesmal ohne Upsize Tool sondern Nativ so dass auch die vielen Alaska Tabellen und Variablen eliminiert sind. Die auf Gundlage der libpg4xb erstellen Funktionen und Klassen sind absolut Thread-Save (jeder Thread hat jedoch ein eigenes Handle) funktionieren sehr schnell und bieten ohne Einschränkung alle Möglichkeiten von PG. Sicher anfangs mehr Arbeit, ich kann aber auch nicht warten bis a) die Alaska-Funktionen das tun was Sie sollten und b) auch alle Dokumentiert sind. Ich muss meine Arbeit jetzt erledigen, die erwähnte Lösung über libpq4xb steht jetzt bereit und funktioniert auch ......... und tausende Seiten Deutsche Doku der DLL Funktionen usw gibts auch.
Gruss Carlo
Danke für deine Nachfrage und die Antwort von Alaska.
Ich bin inszwischen aus andern Gründen eigentlich auch (erneut) darauf gekommen die PG von Alaska NICHT weiter zu verwenden. Ganz einfach wegen der spärlich Dokumentierten Funktionen die z.T nicht mal funktionieren und den TBD die es überall noch gibt.
So liefert der Code
tatsächlich eine Workarea "Adressen" mit dem Inhalt zurück.oStmt:Build():Query(USQL_RESULT_WORKAREA, "Adressen")
der Code
liefert in b "QUERY" zurück aber kein Resultat in aResultb := oStmt:Build():Query(USQL_RESULT_ARRAY, @aResult )
Ich entschied mich sämtliche mit dem Upsize Tool erstellten PG-Datenbanken zu löschen und neu zu erstellen diesmal ohne Upsize Tool sondern Nativ so dass auch die vielen Alaska Tabellen und Variablen eliminiert sind. Die auf Gundlage der libpg4xb erstellen Funktionen und Klassen sind absolut Thread-Save (jeder Thread hat jedoch ein eigenes Handle) funktionieren sehr schnell und bieten ohne Einschränkung alle Möglichkeiten von PG. Sicher anfangs mehr Arbeit, ich kann aber auch nicht warten bis a) die Alaska-Funktionen das tun was Sie sollten und b) auch alle Dokumentiert sind. Ich muss meine Arbeit jetzt erledigen, die erwähnte Lösung über libpq4xb steht jetzt bereit und funktioniert auch ......... und tausende Seiten Deutsche Doku der DLL Funktionen usw gibts auch.
Gruss Carlo
Zuletzt geändert von ramses am Do, 13. Jul 2017 12:26, insgesamt 1-mal geändert.
Valar Morghulis
Gruss Carlo
Gruss Carlo
- brandelh
- Foren-Moderator
- Beiträge: 15689
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 65 Mal
- Danksagung erhalten: 33 Mal
- Kontaktdaten:
Re: DBF zu PostgreSQL
Im Zuge einer Datenmigration musste ich Access Daten nach SQL bringen (bei uns ist das wohl ein IBM SQL Server, kann mich aber auch täuschen).
Dazu lies ich mir die Ladeanweisung der Daten als SQL Text geben. Eine Textdatei die die auf dem HOST per Admin einlesen ...
Diese Datei habe ich um die Zeilen (alles reine Texte ... ) ergänzt, welche die Daten beschreiben. Bei MySQL wäre das eine komplette Sicherung.
Andere Quellen lieferten CSV Dateien.
Diese Dateien können riesig sein, die will man nicht per Xbase++ Satzweise übertragen. Außerdem bekam ich gar keinen Zugriff auf die Hauptserver.
Danach habe ich mal Spaßeshalber die Daten per SQLexpress auf MySQL und PostGreSQL importiert. Das dauerte .... ewig (gefühlt).
Beim MySQL konnte ich 10 Datensätze auf einmal anlegen, das ging etwas schneller, aber immer noch langsam (gut 10 Millionen Datensätze).
Danach habe ich die oben erwähnte SQL Datei eingespielt mit dem Admintool. Die genaue Zeit weiß ich nicht mehr, aber etwa 100 bis 1000 der anderen.
Solange man NATIVE bleibt, kann man sowas auch nutzen.
Wer UPSIZED, muss den langsamen Weg gehen.
Dazu lies ich mir die Ladeanweisung der Daten als SQL Text geben. Eine Textdatei die die auf dem HOST per Admin einlesen ...
Diese Datei habe ich um die Zeilen (alles reine Texte ... ) ergänzt, welche die Daten beschreiben. Bei MySQL wäre das eine komplette Sicherung.
Andere Quellen lieferten CSV Dateien.
Diese Dateien können riesig sein, die will man nicht per Xbase++ Satzweise übertragen. Außerdem bekam ich gar keinen Zugriff auf die Hauptserver.
Danach habe ich mal Spaßeshalber die Daten per SQLexpress auf MySQL und PostGreSQL importiert. Das dauerte .... ewig (gefühlt).
Beim MySQL konnte ich 10 Datensätze auf einmal anlegen, das ging etwas schneller, aber immer noch langsam (gut 10 Millionen Datensätze).
Danach habe ich die oben erwähnte SQL Datei eingespielt mit dem Admintool. Die genaue Zeit weiß ich nicht mehr, aber etwa 100 bis 1000 der anderen.
Solange man NATIVE bleibt, kann man sowas auch nutzen.
Wer UPSIZED, muss den langsamen Weg gehen.
Gruß
Hubert
Hubert
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2513
- Registriert: Mi, 28. Jul 2010 17:16
- Hat sich bedankt: 12 Mal
- Danksagung erhalten: 77 Mal
Re: DBF zu PostgreSQL
Hallo Hubert
aktuelle Zeit für dbf to PG --> 1.5 Mio Datensätze mit 26 Feldern und 8 Indexe ca. 6 Min.
Gruss Carlo
aktuelle Zeit für dbf to PG --> 1.5 Mio Datensätze mit 26 Feldern und 8 Indexe ca. 6 Min.
Gruss Carlo
Valar Morghulis
Gruss Carlo
Gruss Carlo
- Werner_Bayern
- Der Entwickler von "Deep Thought"
- Beiträge: 2120
- Registriert: Sa, 30. Jan 2010 22:58
- Wohnort: Niederbayern
- Hat sich bedankt: 29 Mal
- Danksagung erhalten: 70 Mal
Re: DBF zu PostgreSQL
Servus Carlo,
bitte gerne.
Ja, DacSqlStatement unterstützt m. W. n. noch nicht USQL_RESULT_ARRAY und USQL_RESULT_SINGLE_VALUE.
Letzteres kann man leicht simulieren und statt Array nimm USQL_RESULT_OBJECTS (hab ich aber noch nicht getestet).
bitte gerne.
Ja, DacSqlStatement unterstützt m. W. n. noch nicht USQL_RESULT_ARRAY und USQL_RESULT_SINGLE_VALUE.
Letzteres kann man leicht simulieren und statt Array nimm USQL_RESULT_OBJECTS (hab ich aber noch nicht getestet).
es grüßt
Werner
<when the music is over, turn off the lights!>
Werner
<when the music is over, turn off the lights!>