Upsize und ISAM-Emulation

Alles zum PostgreSQL-Server

Moderator: Moderatoren

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

Re: Upsize und ISAM-Emulation

Beitrag von AUGE_OHR » Di, 09. Jul 2019 18:44

Jan hat geschrieben:
Di, 09. Jul 2019 6:10
warum lenkst Du dermaßen vom Thema ab? DU hattest mit den DO angefangen, nicht ich - ich hab lediglich darauf hingewiesen daß das nicht zum Thema gehört. Merkst Du das Du Dich da mit Deinen SQL-Beiträgen irgendwo verrannt hast und versuchst nun, das alles irgendwie noch zu retten?
ich habe NIE von DO gesprochen ... [-X

den Code für die gezeigten Beispiele entstammen aus meinen Apps die schon seit einiger Zeit im Einsatz sind.
hat irgend jemand mit der PgDBE schon eine App bei Kunden laufen (der sich nicht über die Geschwindigkeit beschwert) :?:
gruss by OHR
Jimmy

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

Re: Upsize und ISAM-Emulation

Beitrag von AUGE_OHR » Di, 09. Jul 2019 18:46

ramses hat geschrieben:
Di, 09. Jul 2019 9:26
Deshalb kann ich dir deine Fragen nicht beantworten.
ich dachte nur das du vielleicht den Test gemacht hast.

hat jemand anderes es mal auf dem Weg versucht, also Upsize nur DBF und dann die Indexe anlegen :?:
wird inzwischen dabei auch ein "echter" PostgreSQL Index erzeugt :?:
gruss by OHR
Jimmy

ramses
Programmier-Gott
Programmier-Gott
Beiträge: 1370
Registriert: Mi, 28. Jul 2010 17:16

Re: Upsize und ISAM-Emulation

Beitrag von ramses » Di, 09. Jul 2019 19:56

AUGE_OHR hat geschrieben:
Di, 09. Jul 2019 18:46
ramses hat geschrieben:
Di, 09. Jul 2019 9:26
Deshalb kann ich dir deine Fragen nicht beantworten.
ich dachte nur das du vielleicht den Test gemacht hast.
hat jemand anderes es mal auf dem Weg versucht, also Upsize nur DBF und dann die Indexe anlegen :?:
Ja, den habe ich schon gemacht. Upsize in ISAM Mode ohne Index geht schnell. Unter einer Stunde. Das erstellen des Index dauert dann aber auch mehrere Stunden. Und der wichtigte Punkt: Die Performance ist danach auch nicht besser.

Ich habe Upsize im SQL Mode gemeint. Das habe ich beendet.
Valar Morghulis

Gruss Carlo

Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 13413
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Kontaktdaten:

Re: Upsize und ISAM-Emulation

Beitrag von Jan » Di, 09. Jul 2019 20:27

AUGE_OHR hat geschrieben:
Di, 09. Jul 2019 18:44
ich habe NIE von DO gesprochen ... [-X
Jimmy,

Dein Kurzzeitgedächtnis ist schon phänomenal schlecht:
AUGE_OHR hat geschrieben:
Mo, 08. Jul 2019 22:29
@Jan:
warum soll ich was benutzen was ich nicht benötige.

statt DataObject nutze ich lieber Array denn API Function verstehen kein DataObject !
echte DataObject unter Windows hat man bei COM DragDrop was Alaska uns nicht anbietet. [-X
Und natürlich immer wieder die Nase hoch, bist halt ein Genie, das wir ständig nur mißverstehen... Du kannst es halt nicht lassen.
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.

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

Re: Upsize und ISAM-Emulation

Beitrag von AUGE_OHR » Di, 09. Jul 2019 22:47

Jan hat geschrieben:
Di, 09. Jul 2019 20:27
AUGE_OHR hat geschrieben:
Di, 09. Jul 2019 18:44
ich habe NIE von DO gesprochen ... [-X
Dein Kurzzeitgedächtnis ist schon phänomenal schlecht:
mir war nicht klar das du mit DO = DataObject meinst und nicht das "DO" bei einem SQL Server von dem wir hier sprechen.
gruss by OHR
Jimmy

Benutzeravatar
steffen.pirsig
Rookie
Rookie
Beiträge: 10
Registriert: Fr, 04. Nov 2011 12:09
Wohnort: Eschborn, Deutschland
Kontaktdaten:

Re: Upsize und ISAM-Emulation

Beitrag von steffen.pirsig » Fr, 12. Jul 2019 17:19

Hallo Carlo,

ich finde ein "RIP PG EMU" ganz schön anmaßend. Du führst Tests durch, stellst eine schlechte Performance fest und legst die DBE beiseite. Dann findest du raus, dass die Xbase++ PostgreSQL DBE mit einer sich als 8.3 meldenden angepassten libpq (libpqex) ausgeliefert wird und erklärst, dass das alles Mist ist.

Hast du mal den Support von Alaska Software zu diesen Performance Problem kontaktiert? Nein - Oha! Wir stehen mit vielen Firmen in Kontakt und analysieren deren Rückmeldungen. Und das hat diese Anwendungen und Szenarien sämtlich auf einen guten Weg gebracht. Und woher weißt du, dass die libpq 8.3 so schlecht ist? Mutmaßungen oder einfach die alte Weisheit, was neu ist, muss besser sein? War es vielleicht eine Ableitung von Annahmen und anschließendem konkludieren?

Eventuell - das müsste man dann analysieren - muss in deinem Fall die postgresql.conf angepasst werden. Die Default Werte einer PostgreSQL Server Installation sind nicht gerade von Vorteil, wenn man Tabellen mit 100 Feldern oder mehr upsized. Hast du derart große Tabellenstrukturen?

Oder hast du den DbfUpsizer auf einer Client-Station laufen lassen? Dann verändert sich die Performance auch, da die einzelnen Batchtransaktionen mehr Zeit benötigen.

Sicher ist aber, das die libpq ein Protocol Layer ist, der - vereinfacht gesagt - nichts weiter macht als SQL Commands via TCP/IP an den Server zu senden und Ergebnismengen zurückbekommt. Da ändert sich über Jahre bis auf Kommentare, Code Bereinigungen bzw. Security fixes so ziemlich nix.

Also nochmal klargestellt:
- Wir haben tausende Manntage in der PostgreSQL Engine sowie die ISAM Emulation investiert
- Alleine die Unittests für die ISAM Emulation haben mehr als 63.000 Testfälle
- Mit den letzten Updates wurden Performance und Kompatibilität signifikant verbessert, in manchen Bereich um mehr als 1000%.
- Wir wissen, dass es hier und da noch offene Punkte auch mit der Performance oder der 100% Kompatibilität gibt.

Wir bei Alaska Software sind motiviert diese offenen Punkte zu bereinigen und eine super ISAM Emulation, die DBF/CDX im Netzbetrieb schlägt, zu erarbeiten - das ist und bleibt unser Ziel. Zum Verständnis, die PostgreSQL DatabaseEngine in Xbase++, implementiert zum einen ISAM/navigationsorientierten Datenzugriff á la Clipper/FoxPro/ADS, sowie einen SQL/mengenorientierten Datenzugriff. Der DbfUpsizer überträgt ein ISAM Datenmodel in ein SQL Datenmodel, was natürlich nicht mit einem einfachen Load von CSV/SQL Dump zu vergleichen ist. Mitnichten ist die ISAM Emulation für neue Anwendungen im Allgemeinen gedacht. Wenn es aber darum geht bestehende Investitionen (Source Code und/oder Mitarbeiter Knowhow) zu sichern, dann ist die ISAM Emulation unserer Meinung nach die beste Wahl. Idealerweise sollte aber der nächste Schritt dann sein, vor allem im Query Bereich auf reines SQL zu setzen und Schritt für Schritt die ISAM Kodierung zurückzudrängen.

Wir sind aber als Hersteller, zumindest was die Performance Aspekte anbetrifft, auf ein konstruktives und nicht destruktives Zusammenarbeiten mit unseren Kunden angewiesen. Letzteres ist - zum Glück - aber sehr selten anzutreffen. Leider aber nicht selten genug - sonst müsste ich diesen Post nicht schreiben.

Und damit sind wir auch schon am Punkt, dieser Post richtet sich an all diejenigen, die diesen Thread lesen - er hat das Ziel eine informelle Balance zu schaffen, um dem Destruktiven die Kraft zu nehmen.

In diesem Sinne, mit lieben Grüßen
Steffen F. Pirsig
Alaska Software Inc.

PS: PGLIB ist eine Python Wrapper Library für die LIBPQ und hat nichts mit Xbase++ zu tun, dies nur so am Rande :)

ramses
Programmier-Gott
Programmier-Gott
Beiträge: 1370
Registriert: Mi, 28. Jul 2010 17:16

Re: Upsize und ISAM-Emulation

Beitrag von ramses » Fr, 12. Jul 2019 20:31

Hallo Steffen

du sprichts mich mit deinem Beitrag direkt an. Daher gehe ich nun eigentlich ungewollt, nochmals auf das Thema ein.

Ich wollte die PG-ISAM-EMU wirklich ernsthaft einsetzen und wartete auch einige Wochen auf die neue Version. Die neue Version war auch Pt.1 der Argumente um meine Sub zu verlängern.

Um den letzten Teil einer App und deren Umfangreiche Datenbestände auf Postgres zu migrieren setzte ich grosse Hoffnung auf die von euch angekündigte Super-Performance des PG-ISAM-EMU.

Damit hätte der Code der betreffenden bereits lange bestehenden App nicht verändert werden müssen. Der grosse Teil der restlichen App wurde über die letzten Jahre Stück für Stück überarbeitet und die Daten auf PG migriert.

Bei Beginn dieser Arbeiten gab es gar noch keine PGDBE so dass dazu eigene Klassen und Funktionen die direkt auf der libpq.dll (PostgreSQL Access Library) Aufbauen erstellt wurden.
Aktuelle ist die Version dieser Lib 11.0.X. Es ist das Modul welches die Kommunikation mit dem PG-Server erledigt. Auch beim Server ist die Version 11 aktuell.
Die von euch unter anderm Namen verwendete Version dieses Moduls ist die Version 8.3. Dieser Release von Client und Server stammt aus dem Jahre 2008 und wird seit mehreren Jahren nicht mehr unterstüzt und hat den Status "End of Life".

Idealerweise passt das Clientmodul zum Server hat also die selbe Version.

Bis vor kurzem war ein Upsize mit dem Upsize Tool zu einem aktuellen Postgres Server gar nicht möglich es stürzte ab. Es funktionierte nur mit einem alten Server 8.3.

Diese veraltete Serverversion steht für das von uns verwendete Unix System schon längst nicht mehr zur Verfügung.

Sie, die angesprochenen Tests sollten nun zeigen ob nun ein Upsize überhaupt möglich und wie es mit der Performance des ISAM-EMU's aussieht.

Die Tests wurde auf einem dem Zielsystem entsprechender Ausrüstung durchgeführt.

Zu Test wurden z.B. eine Datenbank DBF-File mit einem Index und ca. 535'000 Datensätzen in 10 Feldern verwendet.
Der Transfer mit dem Upsize Tool hatte Anfangs, zu beginn des Transfers eine bessere Performance nach ca. 230'000 Datensätzen wurden noch ca. 25 Datensätze/Sek. übertragen
und sank weiter auf 10 Datensätze/Sek. bis ich den Versuch abbrach.

Sicher könnte man die Daten ohne Index upsizen das geht schneller und den Index danach erstellen. Das dauert dann nur einige Stunden.

Dies ist aber nicht einmal das Hauptproblem! Das Hautproblem ist die Performance nach dem Upsize. So wie es auch andere User in diesem Thread beschrieben haben.

Der Kunde wartet doch nicht 1 Minute bis die Datenbank im ISAM-EMU Mode 100 Positionen einer Bestellung weggeschieben hat!

Was soll ich da Ihren Support kontaktieren? Wie kann mir der Support hier helfen?

Mit den oben beschriebenen Tools dauerte das Wegschreiben in eine normale PG Datenbank (die keine Alaska spezifischen Felder/Trigger hat) 0.1 Sekunden. Wie gesagt haben die Performance Probleme auch andere User in Ihren Beiträgen festgestellt.

Ich muss alle Daten bis Ende Jahr auf Postgres bringen. Nach diesen Tests mit dem PG-ISAM-EMU stand für mich fest dass ich das gesetzte Ziel nur auf anderen Wegen, nicht mit dem PG-ISAM-EMU erreichen kann. Denn der Termin ist fix und nicht änderbar. Mit den vorhandenen und mir bekannten Tools ist dieses Ziel auch mit überarbeiten des Code noch gut erreichbar. Zeit für weitere Experimente ist da aber nicht mehr vorhanden.

Deshalb soll der PG-ISAM-EMU in den tiefen MEINER Festplatten in Frieden Ruhen. Er wird von mir nicht benötigt ich muss den Zeitplan einhalten und deshalb zwingend andere Wege gehen.. RIP-ISAM-EMU

Ich bin sicher dass Ihr einige Zeit in die Entwicklung der PGDBE (nicht nur den EMU) gesetzt habt.
Es sind dabei sicher viele, viele viele gute und schöne Funktionen und Möglichkeiten entstanden und nun enthalten.

Ich würde diese auch gerne nutzen!! Nur WIE? Ihr entwicklt viele viele neue, schöne Funktionen nur gibt es dazu aber weder ausreichend Code-Bespiele noch eine Dokumenation. Viele Punkte der Doku enthalten wenn überhaupt vorhanden nur "TBD"

Lieber Steffen, wie benutzt du etwas von dem du:
a) nicht weisst dass es vorhanden ist
b) du gar keine Doku mit den zum Einsatz nötigen Infos hast
c) keine Code Bespiele zum "lernen" hast.

Möglich dass du Hellseher bist und diese Infos zum Arbeiten nicht benötigst. Leider fehlt mir die Fähigkeit des Hellsehens....
ich finde ein "RIP PG EMU" ganz schön anmaßend. Du führst Tests durch, stellst eine schlechte Performance fest und legst die DBE beiseite.
Nein. Ich finde dies nicht anmassend. Nur MEINE Entscheidung für MICH. Sie ist jetzt an meinen Aufgaben und dem gesetzten / geforderten Ziel und den heute vorhandenen Möglichkeiten orientiert.

Nachdem diese jetzt anstehende Aufgabe erledigt ist stehe ich gerne für weitere Tests zur Verfügung.....
Valar Morghulis

Gruss Carlo

Benutzeravatar
steffen.pirsig
Rookie
Rookie
Beiträge: 10
Registriert: Fr, 04. Nov 2011 12:09
Wohnort: Eschborn, Deutschland
Kontaktdaten:

Re: Upsize und ISAM-Emulation

Beitrag von steffen.pirsig » Fr, 12. Jul 2019 21:42

Hallo Carlo,
Die von euch unter anderm Namen verwendete Version dieses Moduls ist die Version 8.3. Dieser Release von Client und Server stammt aus dem Jahre 2008 und wird seit mehreren Jahren nicht mehr unterstüzt und hat den Status "End of Life".
1.) Die von uns ausgelieferte libpq ist eine geänderte/angepasste libpq und nicht nur umbenannt. Es gibt also technische Gründe für unser Vorgehen. Der dieser libpq zugrundeliegende Quellcode hat definitiv kein EOL sonst wäre jede libpq der Version 11 oder höher auch EOL.
Bis vor kurzem war ein Upsize mit dem Upsize Tool zu einem aktuellen Postgres Server gar nicht möglich es stürzte ab. Es funktionierte nur mit einem alten Server 8.3.
2.) Das ein Upsize auf >8.3 allgemein nicht ging ist falsch, es ging nur nicht bei >= 9.2 wenn Full-Text-Search mit char columns versucht wurde. Das ist ein bedeutender Unterschied zu deinem Postulat und hat vor allem rein gar nichts mit der unserer libpq zu tun. Sondern mit einer Server seitig eingeführten Inkompatiblität für die es im übrigen bereits ein "Issue" auf seiten des PostgreSQL Servers gibt.
Diese veraltete Serverversion steht für das von uns verwendete Unix System schon längst nicht mehr zur Verfügung.
3.) Kleiner Hinweis, auch die aktuelle PGDBE nutzt die "alte" libpq macht aber nichts und funktioniert trotzdem mit dem neuesten Server - komisch oder?
Die Tests wurde auf einem dem Zielsystem entsprechender Ausrüstung durchgeführt. Zu Test wurden z.B. eine Datenbank DBF-File mit einem Index und ca. 535'000 Datensätzen in 10 Feldern verwendet. Der Transfer mit dem Upsize Tool hatte Anfangs, zu beginn des Transfers eine bessere Performance nach ca. 230'000 Datensätzen wurden noch ca. 25 Datensätze/Sek. übertragen und sank weiter auf 10 Datensätze/Sek. bis ich den Versuch abbrach.
4.) Tja da hasst du doch tolle Messdaten. Vor allem dokumentieren diese eines: Der Server kommt in eine "race condition" und wird immer langsamer. Darf eigentlich nicht sein, es sei es sei denn die Konfiguration des Servers ist nicht entsprechend des Ressourcenbedarfes angepasst. Wie bereits erwähnt die PostgreSQL ist "default" sehr konservativ konfiguriert.
Der Kunde wartet doch nicht 1 Minute bis die Datenbank im ISAM-EMU Mode 100 Positionen einer Bestellung weggeschieben hat! Was soll ich da Ihren Support kontaktieren? Wie kann mir der Support hier helfen?
5.) Rechnen wir doch mal, 100 Positionen, per default auto-commit, also gilt jede Position stellt eine Tansaktion dar, d.h. das ganze darf durchaus 1-2 Sekunden kosten. Der Support hätte dir den Tip gegeben, die Operation in eine Transaktion zu kapsel - als einfach :beginTransaction()/:endTransaction vor dem Schreiben der 100 Position und danach. Dann wäre alles super schnell und außerdem hast du nie mehr inkonsistente Positionen.
Mit den oben beschriebenen Tools dauerte das Wegschreiben in eine normale PG Datenbank (die keine Alaska spezifischen Felder/Trigger hat) 0.1 Sekunden. Wie gesagt haben die Performance Probleme auch andere User in Ihren Beiträgen festgestellt.
Nur mal Rechnen, 0.1 Sekunden sind 100ms, wenn mit der PostgreSQL ISAM Emulation vorher 100 Transaktionen 2 Sekunden gekostet haben, sollte eine Transaktion bei circa 20ms max liegen, ich würden sage wenn du einen Transaktionskontext für deine 100 Position aufgebaut hättest dann sollte die Performance vergleichbar/ähnlich sein und du hättest dir die ganze Arbeit sparen können.

Abschliessend:
a) nicht weisst dass es vorhanden ist
Evtl. einfach beim Support anfragen? Es gibt tatsächlich Kunden die Melden sich beim Support und Fragen nach wie Sie welche Aufgabe am besten bewerkstelligen können. Wir haben mehr als 5.000 Seiten Dokumentation da kann es schon vorkommen das etwas vorhanden ist aber nicht gefunden wird. Außerdem erfahren wir nur so was eventuell fehlt in der Doku.
b) du gar keine Doku mit den zum Einsatz nötigen Infos hast
Das ist doch so nicht richtig, gerade beim Upsizing und der Emulation sowie der Konfiguration ist sehr viel erklärt. Und ja die Doku hat an ein paar Stellen noch TBD, aber genau deshalb: Frag mal den Support.
c) keine Code Bespiele zum "lernen" hast.
Siehe meine Antworten zu a+b. Im übrigen ist ein "Upsizing" Beispiel mit dem MDI Demo dabei das die Grundzüge und das vorgehen Schritt für Schritt erklärt. Aber natürlich deine speziellen Fragen sowie die dazugehörigen Antworten finden sich nicht in unsere Dokumentation - aber dafür gibt es ja den Support der kann nicht immer aber durchaus manchmal helfen.


Wie aus meinen Antworten 1-5 ersichtlich ist, bleibt meiner Meinung nach, sehr wenig bis gar nichts, substantiiertes übrig welches für dein Vorgehensmodell spricht.

Die mit besten Grüßen
Steffen F. Pirsig
Alaska Software Inc.

HaPe: Quoting repariert.

ramses
Programmier-Gott
Programmier-Gott
Beiträge: 1370
Registriert: Mi, 28. Jul 2010 17:16

Re: Upsize und ISAM-Emulation

Beitrag von ramses » Fr, 12. Jul 2019 23:00

Hallo Steffen
4.) Tja da hasst du doch tolle Messdaten. Vor allem dokumentieren diese eines: Der Server kommt in eine "race condition" und wird immer langsamer. Darf eigentlich nicht sein, es sei es sei denn die Konfiguration des Servers ist nicht entsprechend des Ressourcenbedarfes angepasst. Wie bereits erwähnt die PostgreSQL ist "default" sehr konservativ konfiguriert.
Also gut. Einen mache ich noch. Wie sollte denn die "optimal" angepasste Konfiguration des PG Servers aussehen damit die Geschwindigkeit so genial wird wie du sagts?

Ich habe ein Sub. ohne Support. Wie reagiert denn da euer Support wenn ich da Anrufe und dauernd nach Dingen Frage die eigentlich in der Doku und Code Beispielen stehen sollten?
Valar Morghulis

Gruss Carlo

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

Re: Upsize und ISAM-Emulation

Beitrag von AUGE_OHR » Fr, 12. Jul 2019 23:53

steffen.pirsig hat geschrieben:
Fr, 12. Jul 2019 21:42
Wir haben tausende Manntage in der PostgreSQL Engine sowie die ISAM Emulation investiert
Frage : warum :?:
oder noch konkreter warum die Interen FIELD mit den Ausdrücken des IndexKey() :roll:

hat das vielleicht damit zu tun das ein IndexKey() über mehrere Felder gehen kann aber unter SQL ein FIELD verwendet wird :?:

Code: Alles auswählen

   CREATE INDEX cIndex_Name ON cTable_Name (cField_Name)
steffen.pirsig hat geschrieben: vor allem im Query Bereich auf reines SQL zu setzen und Schritt für Schritt die ISAM Kodierung zurückzudrängen.
dann braucht man auch nicht mehr den ganzen Overhead der Internen FIELD mit den Ausdrücken des IndexKey(), oder :?:
steffen.pirsig hat geschrieben: Hast du mal den Support von Alaska Software zu diesen Performance Problem kontaktiert ?
wieso sollen WIR diejenigen sein welche die "Kommunikation" herstellen müssen :?:
wir können nur beurteilen was wir von Alaska geliefert bekommen

vielleicht sollte der Support mal in die Alaska Newgroup sehen denn da tauchen die selben Fragen auf.
steffen.pirsig hat geschrieben: Wir haben mehr als 5.000 Seiten Dokumentation
WOW ... und wie viel davon betrifft PgDBE :?:
steffen.pirsig hat geschrieben: Der Support hätte dir den Tip gegeben, die Operation in eine Transaktion zu kapsel - als einfach

Code: Alles auswählen

:beginTransaction()/:endTransaction()
wieso macht das die PgDBE nicht automatisch :?:
steffen.pirsig hat geschrieben: PS: PGLIB ist eine Python Wrapper Library für die LIBPQ und hat nichts mit Xbase++ zu tun, dies nur so am Rande
es gibt den Wrapper für PostgreSQL von Phil Ide aus 2003 für Xbase++ welche PGLIB heisst ...

Frage : gibt es für PDR 7146 schon eine Lösung oder Workaround :?:
gruss by OHR
Jimmy

Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 13413
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Kontaktdaten:

Re: Upsize und ISAM-Emulation

Beitrag von Jan » Sa, 13. Jul 2019 7:33

Steffen,

erstmal Danke für die Erläuterungen. Rückt manches in ein etwas anderes Licht.

Aber: Manches davon wäre hier eventuell nicht so hoch gekocht bei einer besseren oder umfagngreicheren Doku. Du hattest vor 3 1/2 oder 4 1/2 Jahren auf der dFPUG-Konferenz gesagt, Ihr hättet eine der besten SQL-Dokus, die es gäbe, erstellt. 150 Seiten lang. Muß noch finalisiert werden und käme dann im Frühjahr raus. Wenn es die wirklich endlich gäbe, dann wäre doch sicher manches sehr viel einfacher. Für uns als Entwickler weil wir da mehr Wissen über SQL in Xbase++ raus ziehen könnten. Und für Euch, weil ihr Euch nicht mit immer den gleiche Fragen im Suport rumschlagen müsstet.

Zu der "alten" libpq: Ich hatte Euch vor gut einem Jahr mal angemailt weil Ihr auch beim ADS die uralten dll für den ADS 7 mitliefert (da gab es von Euch übrigens niemals auch nur ein Wort als Antwort dazu, aber das ist hier nicht das Thema). Das ist schlecht, denn ich nutze Funktionen aus aktuelleren ADS-Bibliotheken. Und muß jetzt bei jedem Update tierisch aufpassen, das ich nicht Eure Runtimes als komplettes Verzeichnis mit rüber kopiere. Denn sonst würden diese Funktionsaufrufe ins Leere laufen. Und auch sonst habt Ihr einige veraltete dll in Euren Runtimes. Da ist ein Stolpern über eine real oder vorgeblich veraltete libpq ja nur naheliegend.

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.

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

Re: Upsize und ISAM-Emulation

Beitrag von AUGE_OHR » So, 14. Jul 2019 3:03

um noch mal auf eine "alte" libpg zu kommen :
die ist nur für die "Kommunikation" zuständig und sendet die Qwery an den Server.
Sicher ist aber, das die libpq ein Protocol Layer ist, der - vereinfacht gesagt - nichts weiter macht als SQL Commands via TCP/IP an den Server zu senden und Ergebnismengen zurückbekommt. Da ändert sich über Jahre bis auf Kommentare, Code Bereinigungen bzw. Security fixes so ziemlich nix.
Was "in" einer Qwery steht ist der Schnittstelle "egal" und was vom Server zurück kommt hängt davon ab ob der Server die Qwery "verstanden" hat.
Ein v8.x Server wird keine SQL Function der v9.x in einer Qwery verstehen [-X

und die restlichen *.DLL > v8.x
solange man keine Verschlüsselung der Qwery benötigt braucht man keine "weitere" API (die zum verschlüsseln).
gruss by OHR
Jimmy

Benutzeravatar
Werner_Bayern
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 1657
Registriert: Sa, 30. Jan 2010 22:58
Wohnort: Niederbayern

Re: Upsize und ISAM-Emulation

Beitrag von Werner_Bayern » So, 14. Jul 2019 23:34

AUGE_OHR hat geschrieben:
So, 14. Jul 2019 3:03
Was "in" einer Qwery steht ist der Schnittstelle "egal" und was vom Server zurück kommt hängt davon ab ob der Server die Qwery "verstanden" hat.
Ein v8.x Server wird keine SQL Function der v9.x in einer Qwery verstehen [-X
Servus Jimmy,

nichts anderes hat Steffen geschrieben! Warum hackst Du immer auf der 8.3 rum? Was fehlt Dir? Du nutzt doch nicht mal die 2.0er Xbase++-Version mit der PGDBE?
Wir setzen die (8.3er) PGDBE erfolgreich mit der 64bit-Version des PostgreSQL-Servers 11.2 ein, nutzen auch SQL-Funktionen, die es in der 8.3-Version noch nicht gab.

Also nochmal: Was fehlt Dir konkret?
es grüßt euch

Werner

Benutzeravatar
Werner_Bayern
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 1657
Registriert: Sa, 30. Jan 2010 22:58
Wohnort: Niederbayern

Re: Upsize und ISAM-Emulation

Beitrag von Werner_Bayern » So, 14. Jul 2019 23:39

steffen.pirsig hat geschrieben:
Fr, 12. Jul 2019 21:42
Im übrigen ist ein "Upsizing" Beispiel mit dem MDI Demo dabei das die Grundzüge und das vorgehen Schritt für Schritt erklärt.
Servus Steffen,

das kann ich nicht nachvollziehen, hab Euch eh gestern dazu ein angepasstes MDIDEMO geschickt, weil in der Originalversion zwar die mdidemo.upsize mitgeliefert, diese aber im Quellcode nicht genutzt wird. Wenn man das Teil also mit dem USE_POSTGRES - Schalter benutzt, bekommt man nur die Meldung, dass ein Connect nicht möglich ist, da die mdidemo-Database nicht existiert. Den Code für das Upsizing muss man selber implementieren.
es grüßt euch

Werner

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

Re: Upsize und ISAM-Emulation

Beitrag von AUGE_OHR » Mo, 15. Jul 2019 1:45

Werner_Bayern hat geschrieben:
So, 14. Jul 2019 23:34
nichts anderes hat Steffen geschrieben!Warum hackst Du immer auf der 8.3 rum? Was fehlt Dir? Du nutzt doch nicht mal die 2.0er Xbase++-Version mit der PGDBE?
Wir setzen die (8.3er) PGDBE erfolgreich mit der 64bit-Version des PostgreSQL-Servers 11.2 ein, nutzen auch SQL-Funktionen, die es in der 8.3-Version noch nicht gab.

Also nochmal: Was fehlt Dir konkret?
bitte unterscheide bei der PgDBE den libpq Teil und den ISAM Teil.

ich sage nichts gegen den libpq Teil denn der kann sich (noch) immer mit jeder Server Version "verbinden"
dem libpq Teil ist es egal was "in" einer Qwery steht. es kommt auf der Server Version an ob er die SQL Function "versteht"

---
der ISAM Teil muss alles in eine SQL Qwery "übersetzen" damit es der PostgreSQL Server "versteht".

nun sagst du das du SQL Function von der v11.2 verwendest ... und meine Frage wäre : Du oder PgDBE :?:
wenn PgDBE solche SQL Function nutzt dann muss das "in" der PgDBE codiert sein ... aber woher "weisst" du dann von einer solchen SQL Function :roll:

---
es wäre natürlich interessant welche SQL Function > 8.3 du meinst die man mit xBase nutzen kann :?:
es gibt haufenweise Interessante SQL-Befehle für eine eigene SQL Qwery aber dann ist die Frage ob man den ISAM Teil für das Result-Set noch braucht :?:

für meine native Version nutze ich ROW_NUMBER() und OFFSET zum "navigieren" ala "ISAM" und formulieren meine Qwery selbst.
es löst z.b. das DbPosition() Problem ... wenn man einen "Skipper" nutzt.

---
wie Steffen schon schrieb
vor allem im Query Bereich auf reines SQL zu setzen und Schritt für Schritt die ISAM Kodierung zurückzudrängen.
also werde ich mir den "Hybrid" Schritt sparen und benötige "nur" den libpq Teil ohne ISAM und das geht native mit der libpq.dll
gruss by OHR
Jimmy

Benutzeravatar
steffen.pirsig
Rookie
Rookie
Beiträge: 10
Registriert: Fr, 04. Nov 2011 12:09
Wohnort: Eschborn, Deutschland
Kontaktdaten:

Re: Upsize und ISAM-Emulation

Beitrag von steffen.pirsig » Mo, 15. Jul 2019 10:35

Hallo,
Werner_Bayern hat geschrieben:
So, 14. Jul 2019 23:39
steffen.pirsig hat geschrieben:
Fr, 12. Jul 2019 21:42
Im übrigen ist ein "Upsizing" Beispiel mit dem MDI Demo dabei das die Grundzüge und das vorgehen Schritt für Schritt erklärt.
Servus Steffen,

das kann ich nicht nachvollziehen, hab Euch eh gestern dazu ein angepasstes MDIDEMO geschickt, weil in der Originalversion zwar die mdidemo.upsize mitgeliefert, diese aber im Quellcode nicht genutzt wird. Wenn man das Teil also mit dem USE_POSTGRES - Schalter benutzt, bekommt man nur die Meldung, dass ein Connect nicht möglich ist, da die mdidemo-Database nicht existiert. Den Code für das Upsizing muss man selber implementieren.
bitte einfach die Xbase++ Workbench starten, unter Help -> View Help die Hilfe starten. Dann dort nach "Database Engines -> PostgreSQL Database Engine -> Samples and use cases -> Upsizing MDIDEMO -> Upsizing your data" navigieren und das Kapitel lesen/durcharbeiten. Dort wird Schritt für Schritt aufgezeigt wie die Daten migriert werden und wie die korrekte Migration mittels PGAdmin formal geprüft wird.

Ja ich weiß unsere Dokumentation ist nicht perfekt aber Sie ist bei weitem nicht so schlecht wie hier immer behauptet wird. Ganz nebenbei, nahezu ein viertel aller Supportfälle können mit einem Verweis auf die Dokumentation erledigt werden.

Gruss
Steffen F. Pirsig
Alaska Software Inc.

Benutzeravatar
Werner_Bayern
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 1657
Registriert: Sa, 30. Jan 2010 22:58
Wohnort: Niederbayern

Re: Upsize und ISAM-Emulation

Beitrag von Werner_Bayern » Mo, 15. Jul 2019 12:31

Servus Steffen,

so hatte ich es gemacht, die Hilfe ist - was das Upsizing betrifft - m. M. n. komplett, gut klärend und umfangreich.
es grüßt euch

Werner

Benutzeravatar
Werner_Bayern
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 1657
Registriert: Sa, 30. Jan 2010 22:58
Wohnort: Niederbayern

Re: Upsize und ISAM-Emulation

Beitrag von Werner_Bayern » Mo, 15. Jul 2019 12:48

AUGE_OHR hat geschrieben:
Mo, 15. Jul 2019 1:45
nun sagst du das du SQL Function von der v11.2 verwendest ... und meine Frage wäre : Du oder PgDBE :?:
wenn PgDBE solche SQL Function nutzt dann muss das "in" der PgDBE codiert sein ... aber woher "weisst" du dann von einer solchen SQL Function :roll:
Ich, mit der PGDBE mittels Pass-through! 8)

Code: Alles auswählen

   oStmt := DacSqlStatement(::oSession):FromChar(cBefehl)
   nRows := oStmt:Build():execute()
oder eben mit :executeQuery().

Z. B. gabs mit der 11er Version eine Syntax-Änderung beim insert, wenn nur eine Spalte angesprochen wird. Oder neue Funktionen:

Code: Alles auswählen

pg_create_restore_point()
Oder die CONFLICT-Klausel beim insert, oder die IF EXISTS-Klausel beim alter - möchte ich nicht mehr missen.
Woher ich das weiß? Na aus der jeweiligen PG-Doku. 8)
es grüßt euch

Werner

Antworten