Inoffizielles deutsches Xbase-Forum

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

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 !

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.

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

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.

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.

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?

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

Hab das Problem mit DBPosition auch beim Support angesprochen, mehrfach. Keine passende Antwort half mir bisher weiter.

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?

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.

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?

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

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

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 hat geschrieben:Was könnte ich übersehen haben?

Siehe meine ganzen PDRs dazu.

Ansonsten mache ich das so:

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

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.

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.

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