Inoffizielles deutsches Xbase-Forum

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

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.

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

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
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.

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

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.

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

Servus Carlo,
Gibt Dir eine Adressen.dbf (read only) zurück mit dem gewünschten Ergebnis, sortiert nach Alter.

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

Gäubodenfest

Ist in meiner Nähe - 1 Std. Fahrzeit... War aber noch nie dort.

Update funktioniert analog zu insert. Sieht in meiner Klasse einfach so aus:

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

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?

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

Sag Bescheid für dieses Jahr, dann schau ich mir das als Niederbayer auch mal an

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

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.

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

@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

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 ?

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!

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

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.

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

OK, das ist deutlich schneller, als meine Erinnerung ...

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).