PostgreSQL und XBPBrowse

Alles zum PostgreSQL-Server

Moderator: Moderatoren

PostgreSQL und XBPBrowse

Beitragvon psp » Di, 25. Okt 2016 10:33

Hallo,

ich wollte mal herumfragen, wie ihr das so handhabt.

In unserem Programm steht irgendwann mal die Umstellung auf SQL an, da Alaska ja so nett war eine native Unterstützung für PostgreSQL einzubinden, haben wir das auch mal getan. Man muss bedenken, dass wir eine lange Zeit zweigleisig mit DBF und PostgreSQL arbeiten müssen, da nicht jeder Kunde hierfür einen SQL-Server haben möchte.

Unsere Programme sind nach etwas Anpassungsarbeit sogar lauffäufig bis auf die XBPBrowse-Objekte. Das liegt an der fehlenden Unterstützung für die Funktion DBPosition() bei PostgreSQL.

Laut Alaska bekannt und man arbeitet schon gefühlt Jahre daran - habe den Fehler schon in der Beta moniert. Eine Lösung gibt es jedenfalls noch nicht.

Wie habt ihr das gelöst? Habe ich evtl. eine Alternative übersehen?

Gruß
psp
psp
Rekursionen-Architekt
Rekursionen-Architekt
 
Beiträge: 220
Registriert: Do, 22. Okt 2009 13:42

Re: PostgreSQL und XBPBrowse

Beitragvon brandelh » Di, 25. Okt 2016 10:38

Ich lade die Suchergebnisse (egal von von DBF oder sonstwo) in Arrays und zeige diese an.
Bei DBF speichere ich in einer unsichtbaren Spalte z.B. die Recno (ist ja kurzfristig) oder besser einen eindeutigen Schlüssel.

Änderungen werden dann auf diesen Satz durchgeführt.

Völlig unabhängig von der Datenbasis,
Anzahl der gefundenen Datensätze ist bekannt.
Sortieren über Array (Spaltenweise) ist einfach

Probleme könnten sich ergeben weil man Änderungen nicht live sehen kann !
Gruß
Hubert
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
 
Beiträge: 13498
Registriert: Mo, 23. Jan 2006 21:54
Wohnort: Germersheim

Re: PostgreSQL und XBPBrowse

Beitragvon psp » Di, 25. Okt 2016 11:27

Das Live-Problem könnte uns tatsächlich stören. Wir haben Kunden, die mit bis zu 15 Bearbeitern problemlos in der Software arbeiten können müssen, da ist natürlich die Aktualität der angezeigten Daten höchste Priorität.
psp
Rekursionen-Architekt
Rekursionen-Architekt
 
Beiträge: 220
Registriert: Do, 22. Okt 2009 13:42

Re: PostgreSQL und XBPBrowse

Beitragvon brandelh » Di, 25. Okt 2016 11:45

Der Browser kann aber auch nicht im 1/10 Sek. Takt die Anzeige refreshen und von Änderungen an anderer Stelle bekommt er auch nicht sofort was mit.

Entweder per Timer alle x Sek refreschen oder per Taste z.B. F5 im ie
Gruß
Hubert
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
 
Beiträge: 13498
Registriert: Mo, 23. Jan 2006 21:54
Wohnort: Germersheim

Re: PostgreSQL und XBPBrowse

Beitragvon psp » Di, 25. Okt 2016 11:57

Das wird schon automatisiert, spätestens beim Versetzen des Satzzeigers gemacht. Da bereits jetzt mit Scopes und Filtern gearbeitet wird, geht das auch in endlicher Zeit.

Die Frage wäre, wenn ich das auch über ein Array laufen lasse, müsste ich das ganze an ein Quickbrowse hängen? Refresh-Funktionen sind da und müssten parallel für SQL angepasst werden, dass er das Query notfalls neu ausführt. Könnten im Extremfall gleich mehrere sein.
psp
Rekursionen-Architekt
Rekursionen-Architekt
 
Beiträge: 220
Registriert: Do, 22. Okt 2009 13:42

Re: PostgreSQL und XBPBrowse

Beitragvon brandelh » Di, 25. Okt 2016 13:39

Ob Browse oder Quickbrowse kommt drauf an was man braucht.
Und ja egal ob mit oder ohne Array, jedes "nachfragen nach neuen aktuellen Daten" ist ein select, wobei ich nicht weis, was die PostGreSQL-DBE macht.
Ich nutze - falls überhaupt SQL - SQLExpress() und MySQL. Aber ohne die ganzen eingebauten Methoden (nur Select, Update und Insert Kommandos).

Georg hat da mehr Erfahrung.
Gruß
Hubert
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
 
Beiträge: 13498
Registriert: Mo, 23. Jan 2006 21:54
Wohnort: Germersheim

Re: PostgreSQL und XBPBrowse

Beitragvon Tom » Di, 25. Okt 2016 13:47

Sollte das DbPosition()-Problem nicht längst behoben sein? Als ich Steffen Pirsig vor anderthalb Jahren bei der eXpress++-DevCon in Idaho danach gefragt habe, hat er fast wortwörtlich gesagt, dass das bis zur Konferenzsaison im Herbst 2015 (!) "Geschichte" wäre. Jetzt befinden wir uns in der Konferenzsaison des Folgejahres. Hat er möglicherweise Fortsetzungsgeschichte gemeint? 8-[
Herzlich,
Tom
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
 
Beiträge: 6728
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin

Re: PostgreSQL und XBPBrowse

Beitragvon brandelh » Di, 25. Okt 2016 14:14

Ich frage ja auch regelmäßig in der Newsgroup nach einfachen Beispielen wie man Variablen in die Abfragen bekommt ... scheint schwer zu sein, kommen keine ;-)
Gruß
Hubert
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
 
Beiträge: 13498
Registriert: Mo, 23. Jan 2006 21:54
Wohnort: Germersheim

Re: PostgreSQL und XBPBrowse

Beitragvon psp » Di, 25. Okt 2016 15:35

Hab das Problem mit DBPosition auch beim Support angesprochen, mehrfach. Keine passende Antwort half mir bisher weiter.
psp
Rekursionen-Architekt
Rekursionen-Architekt
 
Beiträge: 220
Registriert: Do, 22. Okt 2009 13:42

Re: PostgreSQL und XBPBrowse

Beitragvon georg » Di, 25. Okt 2016 19:47

Hallo,


man kann das selbst regeln. Ist ein wenig aufwändig, aber wenn man es in einer Klasse kapselt, funktioniert es recht gut. Ich mache das so mit MySQL als Datenbankserver.

Ich versuche mal, das grob anzureissen. Ich arbeite mit einem Fenster innerhalb der Tabelle. Das "Fenster" umfasst 100 Sätze, die ich in ein Result Set lade. Innerhalb dieser Sätze kann der Anwender sich bewegen. Kommt er an den Anfang oder das Ende des "Fensters", wird geprüft, ob Sätze davor bzw. dahinter vorhanden sind. In diesem Fall verschiebe ich das Fenster.

Um das zu verdeutlichen nehmen wir eine nach Artikelnummer geschlüsselte Datei. Das Fenster umfasst die Sätze 1 bis 100. Will der Anwender über Satz 100 hinaus scrollen, werden die Sätze 51 bis 151 geladen. (Man könnte diese 100 Sätze natürlich auch in ein Array laden, oder mehr als 100 Sätze laden.)

dbPosition() bilde ich nun ab, indem ich folgende SQL-Statements absetze:

SELECT count(*) FROM ARTIKEL
SELECT count(*) FROM ARTIKEL WHERE artikelnummer < 1 (1. Satz im "Fenster")
SELECT count(*) FROM ARTIKEL WHERE artikelnummer > 100 (letzter Satz im "Fenster")

Da ich die Position des einzelnen Satzes im Result Set kenne, kenne ich damit auch die relative Position im Browse, und da ich die Gesamtzahl Sätze in der Tabelle kennen, kann ich die Position recht genau ermitteln und über meine SQLdbPosition() Funktion zurückliefern.

Da die Granularität von dbPosition() sich nur auf den Zahlenraum von 0 bis 100 beschränkt, kann man - gerade bei grossen Tabellen - auch ein wenig schätzen.

In meinem Fall ermittele ich die Werte immer dann, wenn ich ein neues Fenster einlese.

Komplex wird die Sache dann, wenn die Tabelle nach mehreren Feldern geschlüsselt ist. Auch in diesem Fall beschränke ich mich auf das erste Feld, nachdem sortiert wird.

Auf diese Weise verhindere ich auch den beliebten Fehler, mal ein "SELECT * FROM tabelle" abzusetzen - gerade dann, wenn die Tabelle extrem gross ist.

Ich hoffe, ich konnte den Lösungsansatz einigermassen verständlich rüberbringen?
Liebe Grüsse aus der Eifel,

Georg
georg
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
 
Beiträge: 1849
Registriert: Fr, 08. Feb 2008 22:29

Re: PostgreSQL und XBPBrowse

Beitragvon Werner_Bayern » Di, 25. Okt 2016 23:09

Servus psp,

wo liegt das Problem? Schau dir folgendes an: ..\Xbase++\source\samples\sql\XbpBrowse

Funktioniert bei mir einwandfrei, hab bereits unser Ticketsystem auf natives PostgreSQL (nicht ISAM) umgestellt.

Fast alle PDRs, die aus meinen Tests bei der Umsetzung entstanden, wurden inzwischen gelöst. Funktioniert ziemlich gut und schnell.
es grüßt euch

Werner
Benutzeravatar
Werner_Bayern
Programmier-Gott
Programmier-Gott
 
Beiträge: 1235
Registriert: Sa, 30. Jan 2010 23:58
Wohnort: Niederbayern

Re: PostgreSQL und XBPBrowse

Beitragvon Werner_Bayern » Di, 25. Okt 2016 23:10

brandelh hat geschrieben:Ich frage ja auch regelmäßig in der Newsgroup nach einfachen Beispielen wie man Variablen in die Abfragen bekommt ... scheint schwer zu sein, kommen keine ;-)

Servus Hubert,

was suchst Du?
es grüßt euch

Werner
Benutzeravatar
Werner_Bayern
Programmier-Gott
Programmier-Gott
 
Beiträge: 1235
Registriert: Sa, 30. Jan 2010 23:58
Wohnort: Niederbayern

Re: PostgreSQL und XBPBrowse

Beitragvon psp » Mi, 26. Okt 2016 8:32

@Werner_Bayern

Die XbpBrowse-Demo aus dem SQL-Verzeichnis habe ich nur mit viel Mühe zum Laufen bekommen.

Im Moment versuchen wir die Daten alternativ zu laden und nicht mehr über das DBUSEAREA, das treibt den Aufwand natürlich weit nach oben. Die Aussage, dass man SQL in wenigen Minuten und überschaubaren Aufwand nutzen kann, ist damit gestorben.

Ich möchte anmerken, dass das Programm mit DBFs noch genauso umgehen können muss wie mit SQL selbst auch, da nicht jeder Kunde einen Umstieg machen wird - liegt wohl an der Gesamt-Datenmenge, die von <20 MB bis über 4 GB gehen kann, die das Programm verwalten kann. Also muss man es immer doppelt machen, sorgt für neue Fehlerquellen und macht es noch komplizierter.
psp
Rekursionen-Architekt
Rekursionen-Architekt
 
Beiträge: 220
Registriert: Do, 22. Okt 2009 13:42

Re: PostgreSQL und XBPBrowse

Beitragvon brandelh » Mi, 26. Okt 2016 8:52

psp hat geschrieben:Im Moment versuchen wir die Daten alternativ zu laden und nicht mehr über das DBUSEAREA, das treibt den Aufwand natürlich weit nach oben. Die Aussage, dass man SQL in wenigen Minuten und überschaubaren Aufwand nutzen kann, ist damit gestorben.


Wenn man die Datenbeschaffung (in Arrays, egal von wo her) von der Anzeige trennt (also nur Arrays anzeigt), ist das einfacher ;-)
Bei all den Aktionen kann man dann auch verhindern, dass tatsächlich jemand 1.000.000 Datensätze in den Browse schaufeln will :D
Gruß
Hubert
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
 
Beiträge: 13498
Registriert: Mo, 23. Jan 2006 21:54
Wohnort: Germersheim

Re: PostgreSQL und XBPBrowse

Beitragvon Werner_Bayern » Mi, 26. Okt 2016 17:30

psp hat geschrieben:Ich möchte anmerken, dass das Programm mit DBFs noch genauso umgehen können muss wie mit SQL selbst auch, da nicht jeder Kunde einen Umstieg machen wird - liegt wohl an der Gesamt-Datenmenge, die von <20 MB bis über 4 GB gehen kann, die das Programm verwalten kann. Also muss man es immer doppelt machen, sorgt für neue Fehlerquellen und macht es noch komplizierter.

Das geht tatsächlich z. Z. nur mit einer Codeänderung, siehe Alaska-SQL-Beispiel. Damit funktioniert ein XbpBrowse. Wo hattest Du Probleme bei der Umsetzung?
Nicht vergessen: Wenn Du es über SQL-Select machst (Alaska-Beispiel), hast Du zwar im Prinzip auch eine normale DBF-Tabelle, die existiert jedoch nur im RAM und ist "schreibgeschützt".
es grüßt euch

Werner
Benutzeravatar
Werner_Bayern
Programmier-Gott
Programmier-Gott
 
Beiträge: 1235
Registriert: Sa, 30. Jan 2010 23:58
Wohnort: Niederbayern

Re: PostgreSQL und XBPBrowse

Beitragvon psp » Do, 03. Nov 2016 11:54

Ich versuche mich gerade an einem Workarround für mein Problem, das setzt aber voraus, dass die Anzahl der Datensätze korrekt ist.

In meinem Fall mache ich ein Query mit Filterbedingung und einer Sortierung, welches in pgadmin genau 28 Datensätze ausgibt. Wenn ich das gleiche Query über use ("") innerhalb meiner Anwendung ausführen lasse, habe ich den kompletten Bestand von 15000 Datensätzen in der Hand! Es ist auch kein weiteres Query auf die Tabelle gelaufen.

Was könnte ich übersehen haben?
psp
Rekursionen-Architekt
Rekursionen-Architekt
 
Beiträge: 220
Registriert: Do, 22. Okt 2009 13:42

Re: PostgreSQL und XBPBrowse

Beitragvon Werner_Bayern » Do, 03. Nov 2016 16:00

psp hat geschrieben:Was könnte ich übersehen haben?


Code: Alles auswählen
set deleted off

Siehe meine ganzen PDRs dazu.

Ansonsten mache ich das so:
Code: Alles auswählen
select COUNT(*) from Tablename
es grüßt euch

Werner
Benutzeravatar
Werner_Bayern
Programmier-Gott
Programmier-Gott
 
Beiträge: 1235
Registriert: Sa, 30. Jan 2010 23:58
Wohnort: Niederbayern

Re: PostgreSQL und XBPBrowse

Beitragvon psp » Mo, 14. Nov 2016 12:19

Werner_Bayern hat geschrieben:
Code: Alles auswählen
set deleted off

Siehe meine ganzen PDRs dazu.


Ist egal, ob mit OFF oder ON. Das Ergebnis ist das selbe.

Werner_Bayern hat geschrieben:Ansonsten mache ich das so:
Code: Alles auswählen
select COUNT(*) from Tablename


Habe ich auch probiert und habe es nicht mit DacSQLStatement ausgeführt bekommen. Jedoch habe ich mit DacSQLStatement meinen Query mit WHERE-Bedingung ausgeführt bekommen, so dass das Ergebnis passte. Aber damit fallen alle DB-Funktionen flach, kein DBSetScope, kein DBSkip, kein OrdListAdd oder sonst was läuft mehr. Auch wenn ich alle anderen Tabellen über DacSQLStatement öffnen lasse bekomme ich nach kurzer Zeit Fehlermeldungen, die mehr Ärger als Lösung darstellen.

Die Marketing-Aussage, dass man mit wenigen Anpassungen SQL verwenden kann, taugt nichts. Zumal parallel DBF und PostgreSQL so nicht möglich ist.

PS: meine Version ist von Ende August 2016, seitdem ist von Continuus Updates nichts zu merken. In der Hilfe klaffen noch immer TBD-Löcher, gerade in Hinblick auf die SQL-Geschichte.
psp
Rekursionen-Architekt
Rekursionen-Architekt
 
Beiträge: 220
Registriert: Do, 22. Okt 2009 13:42

Re: PostgreSQL und XBPBrowse

Beitragvon Jan » Mo, 14. Nov 2016 12:38

psp hat geschrieben:PS: meine Version ist von Ende August 2016, seitdem ist von Continuus Updates nichts zu merken. In der Hilfe klaffen noch immer TBD-Löcher, gerade in Hinblick auf die SQL-Geschichte.

Erfahrungsgemäß sollten wir diese Woche ein Update bekommen. Weil ja in Frankfurt die Xbase++-Tracks anstehen. Da gibt das immer vorher was Neues. Die Continuous Delivery von Alaska gibt ja auch keine gleichmäßigen Updates raus. Mal kommen da zwei innerhalb weniger Tage, und dann ist da wieder ein halbes Jahr komplette Funkstille. Und auch der Umfang der jeweils gefixten Probleme ist vollkommen unabhängig von der Dauer seit dem vorigen Update.

Und Du hast Recht. Alaska ist mit der PostgreSQL-Geschichte ein gutes Stück hinter den eigenen Erwartungen geblieben. Nicht nur, daß das bislang nur mit einer vollkommen veralteten PostgreSQL-Version klappt. Das klappt noch nicht einmal vollständig oder reibungslos. Es wurde schon mehrfach ein Update angekündigt, mit dem das alles besser, korrekter, schneller funktioneiren sollte. Aber leider hat all das die versprochene vollständige Unterstützung noch nicht gebracht.

Zur Doku: Steffen hat eine extrem umfangreiche und detaillierte und sehr gut gemachte Doku zu den Teilgebiet PostgreSQL versprochen. Für Anfang diesen Jahres.

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
Jan
Foren-Administrator
Foren-Administrator
 
Beiträge: 11895
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle

Re: PostgreSQL und XBPBrowse

Beitragvon satmax » Mo, 14. Nov 2016 15:43

Wenn es Xbase++ und SQL sein muss, bleibt IMHO nur: SQLExpress for Xbase++. Diese Variante funktioniert seit Jahren einwandfrei und kann man empfehlen.

Was das "Continuous Delivery" von Alaska angeht, ist es meist nicht mal den Aufwand für die Installation wert.
Gruß
Markus
Benutzeravatar
satmax
1000 working lines a day
1000 working lines a day
 
Beiträge: 776
Registriert: Do, 02. Dez 2010 20:34
Wohnort: Biberbach in Österreich

Re: PostgreSQL und XBPBrowse

Beitragvon Werner_Bayern » Di, 15. Nov 2016 0:51

Servus psp,

zeig doch mal Deinen Code, bei dem das select COUNT(*) nicht funktioniert. Mischbetrieb funktioniert sehr wohl und zwischenzeitlich wurde gerade bei der ISAM-Emulation vieles gefixed.
es grüßt euch

Werner
Benutzeravatar
Werner_Bayern
Programmier-Gott
Programmier-Gott
 
Beiträge: 1235
Registriert: Sa, 30. Jan 2010 23:58
Wohnort: Niederbayern

Re: PostgreSQL und XBPBrowse

Beitragvon psp » Mo, 10. Apr 2017 14:20

Neues Update, neues Glück.

Wieder nur kein Fix für XBPBrowse. Dafür einer für DBSetFilter mit folgenden Ergebnis: XPPERROR mit Unzulässiger Funktion bei dbgotop()
psp
Rekursionen-Architekt
Rekursionen-Architekt
 
Beiträge: 220
Registriert: Do, 22. Okt 2009 13:42


Zurück zu SQL-Server

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast