DBF zu PostgreSQL

Hier dreht es sich um den PostGre Server

Moderator: Moderatoren

Siggy
Cut&Paste-Entwickler
Cut&Paste-Entwickler
Beiträge: 20
Registriert: Mo, 18. Jan 2016 14:05

DBF zu PostgreSQL

Beitrag von Siggy »

Guten Tag liebe X-Baseler,

wir haben vor kurzer Zeit noch die alte Version 1.9 verwendet :roll: , 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
Benutzeravatar
brandelh
Foren-Moderator
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

Beitrag von brandelh »

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.
Gruß
Hubert
ramses
Der Entwickler von "Deep Thought"
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

Beitrag von ramses »

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
Valar Morghulis

Gruss Carlo
Benutzeravatar
Werner_Bayern
Der Entwickler von "Deep Thought"
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

Beitrag von Werner_Bayern »

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
DLL-Aufrufe oder libpq4xb
gehen, dafür gibt es u. a. die sehr performante Xbase++ Klasse und Funktion

Code: Alles auswählen

DacSqlStatement
executeQuery
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.
es grüßt

Werner

<when the music is over, turn off the lights!>
ramses
Der Entwickler von "Deep Thought"
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

Beitrag von ramses »

Hallo Werner

mit den

Code: Alles auswählen

DacSqlStatement
executeQuery
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
Valar Morghulis

Gruss Carlo
Benutzeravatar
AUGE_OHR
Marvin
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

Beitrag von AUGE_OHR »

Siggy hat geschrieben: Fr, 07. Jul 2017 13:28Jetzt meine Frage gibt es wo eine einfache Beschreibung wie man dies umsetzten kann:
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. :badgrin:

aber über die Performance sagt das nun nichts aus ... insbesondere der ISAM Emulation [-X

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
Benutzeravatar
Werner_Bayern
Der Entwickler von "Deep Thought"
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

Beitrag von Werner_Bayern »

Servus Carlo,

Code: Alles auswählen

oStmt := DacSqlStatement(::oSession):FromChar("select * from mydbf where name = 'meier' order by alter")
oStmt:Build():Query(USQL_RESULT_WORKAREA, "Adressen")
Gibt Dir eine Adressen.dbf (read only) zurück mit dem gewünschten Ergebnis, sortiert nach Alter.
es grüßt

Werner

<when the music is over, turn off the lights!>
ramses
Der Entwickler von "Deep Thought"
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

Beitrag von ramses »

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
Valar Morghulis

Gruss Carlo
Benutzeravatar
Werner_Bayern
Der Entwickler von "Deep Thought"
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

Beitrag von Werner_Bayern »

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
Gäubodenfest
Ist in meiner Nähe - 1 Std. Fahrzeit... War aber noch nie dort.
es grüßt

Werner

<when the music is over, turn off the lights!>
Benutzeravatar
Werner_Bayern
Der Entwickler von "Deep Thought"
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

Beitrag von Werner_Bayern »

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!>
ramses
Der Entwickler von "Deep Thought"
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

Beitrag von ramses »

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
Valar Morghulis

Gruss Carlo
Benutzeravatar
Werner_Bayern
Der Entwickler von "Deep Thought"
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

Beitrag von Werner_Bayern »

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?
es grüßt

Werner

<when the music is over, turn off the lights!>
ramses
Der Entwickler von "Deep Thought"
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

Beitrag von ramses »

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
Valar Morghulis

Gruss Carlo
Benutzeravatar
Werner_Bayern
Der Entwickler von "Deep Thought"
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

Beitrag von Werner_Bayern »

Sag Bescheid für dieses Jahr, dann schau ich mir das als Niederbayer auch mal an :wink:
es grüßt

Werner

<when the music is over, turn off the lights!>
ramses
Der Entwickler von "Deep Thought"
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

Beitrag von ramses »

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:
The statement may be used multiple times, but cannot be used concurrently from different threads.
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?


Gruss Carlo
Valar Morghulis

Gruss Carlo
Benutzeravatar
Werner_Bayern
Der Entwickler von "Deep Thought"
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

Beitrag von Werner_Bayern »

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.
es grüßt

Werner

<when the music is over, turn off the lights!>
Benutzeravatar
brandelh
Foren-Moderator
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

Beitrag von brandelh »

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 ;-)
Gruß
Hubert
Siggy
Cut&Paste-Entwickler
Cut&Paste-Entwickler
Beiträge: 20
Registriert: Mo, 18. Jan 2016 14:05

Re: DBF zu PostgreSQL

Beitrag von Siggy »

@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
Benutzeravatar
AUGE_OHR
Marvin
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

Beitrag von AUGE_OHR »

Siggy hat geschrieben: Mo, 10. Jul 2017 16:44Wurde die PGu.exe mit der 9.6 Version des Postgres schon getestet?
bei der native Version ist es egal welche PostgreSQL Version du nimmst ... die API ändert sich NICHT (wird höchstens erweitert)
Siggy hat geschrieben: Mo, 10. Jul 2017 16:44Beim ausführen der .exe kommt bei mir immer die Fehlermeldung "Unable to load libpq.dll",
ich habe die .dll jedoch in den Ordner reinkopiert.
Frage : hast du eine 32bit :!: DLL Version genommen ?
gruss by OHR
Jimmy
Benutzeravatar
Werner_Bayern
Der Entwickler von "Deep Thought"
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

Beitrag von Werner_Bayern »

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!>
ramses
Der Entwickler von "Deep Thought"
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

Beitrag von ramses »

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
oStmt:Build():Query(USQL_RESULT_WORKAREA, "Adressen")
tatsächlich eine Workarea "Adressen" mit dem Inhalt zurück.

der Code
b := oStmt:Build():Query(USQL_RESULT_ARRAY, @aResult )
liefert in b "QUERY" zurück aber kein Resultat in 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
Benutzeravatar
brandelh
Foren-Moderator
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

Beitrag von brandelh »

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.
Gruß
Hubert
ramses
Der Entwickler von "Deep Thought"
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

Beitrag von ramses »

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
Valar Morghulis

Gruss Carlo
Benutzeravatar
brandelh
Foren-Moderator
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

Beitrag von brandelh »

OK, das ist deutlich schneller, als meine Erinnerung ...
Gruß
Hubert
Benutzeravatar
Werner_Bayern
Der Entwickler von "Deep Thought"
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

Beitrag von Werner_Bayern »

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).
es grüßt

Werner

<when the music is over, turn off the lights!>
Antworten