Schreibzugriff auf pgdbe-Datenbank für Programme, die nicht in Xbase++ geschrieben sind (z.B. in C#)

Hier dreht es sich um den PostGre Server

Moderator: Moderatoren

Benutzeravatar
dtmackenzie
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 265
Registriert: Do, 22. Nov 2007 9:02
Wohnort: Leipzig
Hat sich bedankt: 66 Mal
Danksagung erhalten: 22 Mal
Kontaktdaten:

Re: Schreibzugriff auf pgdbe-Datenbank für Programme, die nicht in Xbase++ geschrieben sind (z.B. in C#)

Beitrag von dtmackenzie »

Tom,

bei "einem gesonderten Thread" fällt mir ein, sowohl hier als in meiner Antwort zum Beitrag von Steffen Pirsig - ich habe bisher wirklich nur an einem Thread in der Anwendung gedacht, den haben wir schon. Aber wenn alle Clients dies machen, dann könnten dies vielleicht zu einer Überlastung des Servers führen, also vermutlich müsste stattdessen doch ein separates, zentral läufendes Synchronisationsprogramm dafür her.

Das aber nur nebenbei - ich habe weiter über Deinen Vorschlag nachgedacht, vielleicht braucht man doch nur eine einzige Synchronisationstabelle so ähnlich wie folgt:

Code: Alles auswählen

CREATE TABLE Sync (
id bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
angelegt timestamp NOT NULL DEFAULT current_timestamp,
uebernommen timestamp DEFAULT NULL,
fehlermeldung text DEFAULT NULL,
tabellenname text NOT NULL,
tabellenrecord integer NOT NULL,
rowversion integer NOT NULL,
feldnamen text[] NOT NULL,
feldwerte text[] NOT NULL,
CONSTRAINT arraysok CHECK (array_length(feldnamen, 1) = array_length(feldwerte, 1))
)
Dies könnte vom Synchronisationsprogramm vielleicht sekundlich oder gar in einer Dauerschleife abgearbeitet werden.
Wenn ein Konflikt trotzdem vorkommnt, kann sie zumindest durch einen Vergleich zwischen rowversion und __rowversion erkannt werden und in fehlermeldung zurückgemeldet. Weißt aber jemand eigentlich was __keyversion bedeutet?
So wie ich mir das vorstelle, wird tabellenrecord als 0 gelassen wenn ein Append gemacht werden soll, dann vom Synchronisationsprogramm mit RECNO() gefüllt.
Das Synchronisationsprogramm muss die Feldwerte von String in den jeweiligen Typ (entsprechend Feldname) konvertieren.
Ich glaube, der Rest sollte selbsterklärend sein.
Viele Grüße,
David
Benutzeravatar
dtmackenzie
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 265
Registriert: Do, 22. Nov 2007 9:02
Wohnort: Leipzig
Hat sich bedankt: 66 Mal
Danksagung erhalten: 22 Mal
Kontaktdaten:

Re: Schreibzugriff auf pgdbe-Datenbank für Programme, die nicht in Xbase++ geschrieben sind (z.B. in C#)

Beitrag von dtmackenzie »

Hallo Frank,

fair ist es vielleicht nicht, war aber nötig darüber zu reden um die Grenzen des deterministich Möglichen zu klären...

Fazit: Felder, die in einem ISAM-Index vorkommen, können nie sicher extern geupdatet werden wenn irgendwo die Tabelle in einem Workarea geöffnet ist.

So sollte die ursprüngliche Aussage von Steffen Pirsig präzisiert werden.

"60 Sekunden out-of-sync" hat nichts zu tun mit dem eigentlichen Problem hier: Es geht darum, dass jederzeit wenn der Index korrupt ist, die Xbase++ Anwendung ohne Eigenschuld den falschen Datensatz modifizieren könnte, schlimmstenfalls selbst beim Öffnen/Ändern/Schließen wenn es zum ungünstigsten Zeitpunkt passiert.

Wie Du bestimmt nun von meinem Beiträgen gesehen hast, rechne ich nicht damit, dass sowas (z.B. durch eine triggerbasierte Lösung) in Zukunft erlaubt wird. Wäre schön gewesen, kann ich aber gut verstehen.

Meine Meinung bzgl. Microservices habe ich zum größten Teil ausgedruckt in einem früheren Beitrag. Sie sind offensichtlich strategisch einen excellenten Ansatz, insbesondere wenn Schnittstellen zu firmenexternen Systemen vorgesehen sind. Andererseits kann man kaum prototypisch vorgehen, da fehlen feste Anhaltspunkte, und dazu muss man sich mit Web-Technologie befassen. Vielleicht ist das in unserem Fall gar nicht nötig. Eine initiale Vorgehensweise so wie ich gerade mit Tom auskaspere hat eine gewisse Charme (einschließlich inherente Dokumentation von allen externen Änderungen)... Das könnte vielleicht auch ausgebohrt werden, von einer rein Feldbasierten Schnittstelle zu etwas REST-ähnliches ohne HTTP (vielleicht mit einem JSON Feld anstatt einigen der letzten Feldern)... Aber das sind noch unreife Gedanken.
Viele Grüße,
David
Benutzeravatar
dtmackenzie
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 265
Registriert: Do, 22. Nov 2007 9:02
Wohnort: Leipzig
Hat sich bedankt: 66 Mal
Danksagung erhalten: 22 Mal
Kontaktdaten:

Re: Schreibzugriff auf pgdbe-Datenbank für Programme, die nicht in Xbase++ geschrieben sind (z.B. in C#)

Beitrag von dtmackenzie »

Das bleibende Ergebnis dieses Threads (kurz: Mache es nie während eine Xbase++ Anwendung läuft) habe ich auf Englisch zusammengefasst in ILX.
Viele Grüße,
David
Benutzeravatar
Manfred
Foren-Administrator
Foren-Administrator
Beiträge: 21165
Registriert: Di, 29. Nov 2005 16:58
Wohnort: Kreis Wesel
Hat sich bedankt: 206 Mal
Danksagung erhalten: 67 Mal

Re: Schreibzugriff auf pgdbe-Datenbank für Programme, die nicht in Xbase++ geschrieben sind (z.B. in C#)

Beitrag von Manfred »

supergeil, ich komme wieder nicht rein.
Gruß Manfred
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
großer Fan des Xbaseentwicklerwiki https://wiki.xbaseentwickler.de/index.p ... Hauptseite
Doof kann man sein, man muß sich nur zu helfen wissen!!
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

Re: Schreibzugriff auf pgdbe-Datenbank für Programme, die nicht in Xbase++ geschrieben sind (z.B. in C#)

Beitrag von Jan »

Manfred,

kein Problem bei mir.

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
Frank Grossheinrich
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 142
Registriert: Fr, 31. Mär 2017 15:06
Wohnort: Eschborn
Hat sich bedankt: 5 Mal
Danksagung erhalten: 81 Mal
Kontaktdaten:

Re: Schreibzugriff auf pgdbe-Datenbank für Programme, die nicht in Xbase++ geschrieben sind (z.B. in C#)

Beitrag von Frank Grossheinrich »

Manfred hat geschrieben: Mi, 15. Mär 2023 18:16 supergeil, ich komme wieder nicht rein.
Was tust du denn und was passiert?
Denn wir machen nix.

Lass hören
Frank
We love Xbase++, and you?
Benutzeravatar
Manfred
Foren-Administrator
Foren-Administrator
Beiträge: 21165
Registriert: Di, 29. Nov 2005 16:58
Wohnort: Kreis Wesel
Hat sich bedankt: 206 Mal
Danksagung erhalten: 67 Mal

Re: Schreibzugriff auf pgdbe-Datenbank für Programme, die nicht in Xbase++ geschrieben sind (z.B. in C#)

Beitrag von Manfred »

The requested user 'XXXXXXX' could not be found.
Gruß Manfred
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
großer Fan des Xbaseentwicklerwiki https://wiki.xbaseentwickler.de/index.p ... Hauptseite
Doof kann man sein, man muß sich nur zu helfen wissen!!
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9345
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 100 Mal
Danksagung erhalten: 359 Mal
Kontaktdaten:

Re: Schreibzugriff auf pgdbe-Datenbank für Programme, die nicht in Xbase++ geschrieben sind (z.B. in C#)

Beitrag von Tom »

Das ist nicht der gleiche Benutzername wie bei der Anmeldung auf der Alaska-Site, Manfred.
Herzlich,
Tom
Benutzeravatar
Manfred
Foren-Administrator
Foren-Administrator
Beiträge: 21165
Registriert: Di, 29. Nov 2005 16:58
Wohnort: Kreis Wesel
Hat sich bedankt: 206 Mal
Danksagung erhalten: 67 Mal

Re: Schreibzugriff auf pgdbe-Datenbank für Programme, die nicht in Xbase++ geschrieben sind (z.B. in C#)

Beitrag von Manfred »

hm,
ich war ja schon mal drin und meine Auswahl zeigt nur eine Kennung.....
Gruß Manfred
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
großer Fan des Xbaseentwicklerwiki https://wiki.xbaseentwickler.de/index.p ... Hauptseite
Doof kann man sein, man muß sich nur zu helfen wissen!!
Benutzeravatar
Frank Grossheinrich
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 142
Registriert: Fr, 31. Mär 2017 15:06
Wohnort: Eschborn
Hat sich bedankt: 5 Mal
Danksagung erhalten: 81 Mal
Kontaktdaten:

Re: Schreibzugriff auf pgdbe-Datenbank für Programme, die nicht in Xbase++ geschrieben sind (z.B. in C#)

Beitrag von Frank Grossheinrich »

Benutze bitte deine Emailadresse. Nicht die Kundennummer!
We love Xbase++, and you?
Benutzeravatar
Frank Grossheinrich
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 142
Registriert: Fr, 31. Mär 2017 15:06
Wohnort: Eschborn
Hat sich bedankt: 5 Mal
Danksagung erhalten: 81 Mal
Kontaktdaten:

Re: Schreibzugriff auf pgdbe-Datenbank für Programme, die nicht in Xbase++ geschrieben sind (z.B. in C#)

Beitrag von Frank Grossheinrich »

dtmackenzie hat geschrieben: Mi, 15. Mär 2023 18:00 Das bleibende Ergebnis dieses Threads (kurz: Mache es nie während eine Xbase++ Anwendung läuft) habe ich auf Englisch zusammengefasst in ILX.
:(

Uiii, es wird immer verworrener.
Und dein fett geschriebener Satz ist schlicht FALSCH!
Der gilt nur bei Mutwilligkeit, wenn ich unbedingt Daten per SQL in PGDBE ISAM verwaltete Tabellen schreiben möchte und dann auch noch eine Null-Latenz erwarte. Ja, dann bitte nicht.

Es wurden nun aber ausreichend Lösungswege beschrieben, wie man das Problem lösen kann: MicroServices, REST, ... such dir was aus.

Und zu deiner Nachfrage (RLock): ... du denkst weiterhin ISAM ... wenn die fremde Applikation die Mutation in einer Transaction absichert (und das sollte sie tun, denn sonst kommt es zu beliebigen Problemen, nicht nur Xbase++), dann ist das auch für die Xbase++ Applikation kein Problem. Wen oder was interessiert dann ein RLock?

Ich gebe ein wenig auf.
Gruß
Frank
We love Xbase++, and you?
Benutzeravatar
Manfred
Foren-Administrator
Foren-Administrator
Beiträge: 21165
Registriert: Di, 29. Nov 2005 16:58
Wohnort: Kreis Wesel
Hat sich bedankt: 206 Mal
Danksagung erhalten: 67 Mal

Re: Schreibzugriff auf pgdbe-Datenbank für Programme, die nicht in Xbase++ geschrieben sind (z.B. in C#)

Beitrag von Manfred »

Frank Grossheinrich hat geschrieben: Do, 16. Mär 2023 14:26 Benutze bitte deine Emailadresse. Nicht die Kundennummer!
ja, wenn man das nicht speichert, dann vergisst man es wieder. So war es richtig.
Gruß Manfred
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
großer Fan des Xbaseentwicklerwiki https://wiki.xbaseentwickler.de/index.p ... Hauptseite
Doof kann man sein, man muß sich nur zu helfen wissen!!
Benutzeravatar
dtmackenzie
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 265
Registriert: Do, 22. Nov 2007 9:02
Wohnort: Leipzig
Hat sich bedankt: 66 Mal
Danksagung erhalten: 22 Mal
Kontaktdaten:

Re: Schreibzugriff auf pgdbe-Datenbank für Programme, die nicht in Xbase++ geschrieben sind (z.B. in C#)

Beitrag von dtmackenzie »

Nein Frank, da bin ich nicht ganz einverstanden, der Satz ist nicht falsch wenn bezogen auf dem Titel des ILX-Beitrags: Using SQL INSERT and UPDATE...

Dass es nicht um die Länge der Latenz geht, sondern dass es sie überhaupt gibt, scheint immernoch Dein Mißverständnis zu sein, das habe ich schon mehrmals erklärt, aber ich versuche es unten noch ein letztes Mal. Und von Mutwilligkeit darf nicht die Rede sein, schließlich ging dieser ILX-Beitrag spezifisch darum und wurde extra vom original-Beitrag getrennt. Das finde ich also keine nette Ausdrucksweise. Dass der Beitrag in diesem spezifischen Rahmen zu einem negativen Ergebnis kam, akzeptiere ich - ich habe nicht sagen wollen, dass es keine (bzw. sogar bessere) Alternativen gibt.

Fakt ist, dass Änderungen in der pgdbe-Datenbank ausschließlich über Xbase++ passieren müssen, keine andere Programme sollten Schreibzugriff auf ISAM-Tabellen haben, beides zumindest nicht während eine Xbase++ Anwendung am Laufen sein könnte.

Die Lösungswege (Alternativen) sind ausführlich diskutiert worden, vielen Dank an allen dafür, und ich bin gerade dabei eine Zusammenfassung für meinen Chef zu schreiben, wie es für die nächste Jahre weitergehen soll. Nur das direkte, externe SQL UPDATE bzw. INSERT steht nicht zur Debatte: Die Konsequenzen davon wären ein zeitweilig (selbst wenn auch nur kurz) korrupter Index, dadurch könnten an etlichen Stellen die laufende Xbase++ Anwendung auf einen falschen Datensatz stehen und ggf. diesen modifizieren, was zu eine dauerhafte Datenkorruption an der Stelle führen würde. Und es wäre leider absolut unmöglich, diese sporadische Störungen abzufangen. Das wäre ein Support-Albtraum und könnte große Schaden anrichten. Nun verständlich?

Das mit den RLOCK ist für mich nicht mehr wichtig weil es keine direkte, externe SQL UPDATE bzw. INSERT geben wird - die Zwischenschicht (z.B. Microservice) muss in Xbase++ geschrieben werden und kann das selber ordentlich handeln. Da lägen sonst potentiell doch Problemfälle drin, bin ich mir sicher, aber nun wäre es sinnlos, die zu diskutieren. Von mir aus kann der Post mit dem RLOCK gelöscht werden.
Viele Grüße,
David
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: Schreibzugriff auf pgdbe-Datenbank für Programme, die nicht in Xbase++ geschrieben sind (z.B. in C#)

Beitrag von Werner_Bayern »

Servus Frank,

Du wolltest es ja öffentlich haben, am Freitag hat euer Support nochmal Rückfragen gestellt. Mit einer 200k DS Tabelle funktioniert das autom. Aktualisieren der ISAM-Index-Felder durch die PGDBE beim nächsten dbuseArea - teilweise.

Bei unserem Kunden mit den 1.2 Mio Datensätzen mit der 1689 Runtime und vielen fehlenden ISAM-Index-Einträgen funktioniert es absolut nicht. Ich musste den Vorgang der autom. Befüllung nach dem dbuseArea() nach 60 (!) Stunden – kein Schreibfehler – abwürgen, weil der PG immer noch im Hintergrund mit 25% Auslastung rödelte und die Xbase++ - Applikation nicht reagierte.

Meinen 2. Hinweis auf einen inzwischen sehr alten Fehler hast vermutlich falsch verstanden: Schreibt man per ISAM-SQL in ein Feld, das den kontrollierenden Index darstellt in Verbindung mit einem Browse, stimmt danach der Satzzeiger nicht mehr. Teilweise würde er da die Änderungen sogar in einen falschen Satz schreiben, was dann Dank "falschem" Rlock() ins Errorsys geht.
Damit kann m. M. n. keine bestehende Anwendung, ohne den kompletten Code durchzugehen und teilweise zu überarbeiten, umgestellt werden.

Ich hab das 2019 schon bei meinem Vortrag in Münster gezeigt.

Mit dbPack() haben wir lediglich eine Optimierung gefunden, wenn der PG auf einem Docker läuft. Ansonsten habt ihr da schon die optimale Lösung für "normale" Datenmengen.

Bin schon gespannt, was euer Support dazu sagt. Hoffentlich gehts etwas schneller, sonst müssen wir noch mehr Code auf Pass-Through umschreiben.

Danke auch für Deine Hilfe hierfür!
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: Schreibzugriff auf pgdbe-Datenbank für Programme, die nicht in Xbase++ geschrieben sind (z.B. in C#)

Beitrag von ramses »

Werner_Bayern hat geschrieben: Di, 28. Mär 2023 2:06 ..... sonst müssen wir noch mehr Code auf Pass-Through umschreiben.
Das hat uns die GL nach den ersten Gehversuchen vorgeschrieben. Im gleichen Zug haben wir dann auch alles auf Web-App umgestellt und mit Blick auf eine mögliche spätere Umstellung auf ein anderes System auch gleich native Postgres (DLL-Aufrufe) verwendet. Der ganze Aufwand war einiges grösser als geplant aber die Performance auch mit mehreren sehr grossen Tabellen (Mio.+) Datensätze ist umwerfend.

Auf die Datenbanken greifen mehrere unterschiedliche Softwarepakte unterschiedlicher Herkunft zu. Um gegenseitige Störungen zu verhindern haben wir ein Verfahren mit adv_lock von Postgres an das sich alle vor Schreibzugriffen auf die gemeinsamen Datenbanken halten müssen. Seit den Tests und dem go Live läuft es nach dem Motto: Einrichten und Vergessen!...

Ich persönlich finde das für gemeinsam genutzte Datenbanken vor irgendwelchen Mircoservices usw. der beste, problemloseste Weg. Aber auch der Aufwendigste.
Valar Morghulis

Gruss Carlo
Benutzeravatar
dtmackenzie
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 265
Registriert: Do, 22. Nov 2007 9:02
Wohnort: Leipzig
Hat sich bedankt: 66 Mal
Danksagung erhalten: 22 Mal
Kontaktdaten:

Re: Schreibzugriff auf pgdbe-Datenbank für Programme, die nicht in Xbase++ geschrieben sind (z.B. in C#)

Beitrag von dtmackenzie »

Erstmal vielen Dank an allen für das Mitdenken und die Anregungen!

Nach einer Präsentation an meinen Chef wurde entschieden, diesen Weg (REST) nicht weiter zu folgen.
Stattdessen wird unsere Datenbank regelmäßig in eine rein strukturierte SQL Datenbank konvertiert, womit Nachfolgeanwendungen entwickelt werden.
Das ist als Einbahnstraße gedacht, langfristig wird Xbase++ / ISAM aus der Firma verschwinden, auch wenn dies Jahre dauern wird.
Diese Entscheidung ist sehr spezifisch zu unserer Firmensituation: Es handelt sich um unsere firmeninterne ERP-System, und es ist keine breitere Connektivität erwünscht. Sonst hätte REST vielleicht eine Chance gehabt, aber es kommt hinzu, dass ich in einem Jahr in Rente gehe und bin der einzige in der Firma mit Xbase++ (oder Vorgänger) Kenntnisse. Mein Chef wünscht sich perspektivisch Anwendungen, die auf einer gemeinsamen SQL Datenbank basiert sind, und wofür entsprechende Programmierkenntnisse vorhanden sind.

Ich erkläre dies alles weil für viele andere Firmen der Weg über REST Microservices der richtige sein wird.
Viel Erfolg dabei!
Viele Grüße,
David
Antworten