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

Neuer PDR 7564 und weitere werden folgen, bzw. haben damit zu tun.
es grüßt

Werner

<when the music is over, turn off the lights!>
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,

PGDBE_ISAM_ORD_CHECKANDFIX_KEYS funktioniert jetzt bei mir, es füllt also nachträglich die ISAM-Index-Felder mit den Daten aus den Feldern, die in Indexen enthalten sind. =D>
es grüßt

Werner

<when the music is over, turn off the lights!>
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 »

Mit der Einschränkung:

- DbeSetDefault("pgdbe") muss unmittelbar davor gesetzt sein
- keine großen Datenmengen / leere Indexfelder, weil sonst das 1. dbusearea() im ISAM-Modus zu stundenlangen Hängern führt

Bin mit dem Support weiter in Verbindung.
es grüßt

Werner

<when the music is over, turn off the lights!>
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 »

Seufz Werner,

geht das auch präziser? Lass mich an deiner Welt teilhaben.
Und ja, ich weiß, dass du bei uns im Support bist. Da kannst du mit meinen Kollegen zusammen arbeiten/erarbeiten/anfragen, was auch immer. Aber hier sind wir an einem öffentlichen Platz und da möchte ich Dinge so nicht stehen lassen.
Werner_Bayern hat geschrieben: Mo, 06. Mär 2023 23:51 Mit der Einschränkung:
Einschränkung? Das sind Features!
Werner_Bayern hat geschrieben: Mo, 06. Mär 2023 23:51 - DbeSetDefault("pgdbe") muss unmittelbar davor gesetzt sein
Was ist die Botschaft? So steht das in der Doku.
Ein dbeLoad() alleine macht die DBE noch nicht zur Default DBE.

Code: Alles auswählen

PROCEDURE Main
   ? dbeSetDefault()
   WAIT
RETURN


PROCEDURE dbeSys()
   dbeLoad( "PGDBE" )
   dbeSetDefault( "PGDBE" )
RETURN
Lass das dbeSetDefault() in der dbeSys() weg und schon funktionieren dbeInfo() Aufrufe nicht wirklich bzw. haben keine Auswirkung.
Werner_Bayern hat geschrieben: Mo, 06. Mär 2023 23:51 - keine großen Datenmengen / leere Indexfelder, weil sonst das 1. dbusearea() im ISAM-Modus zu stundenlangen Hängern führt
Bitte definiere "große Datenmengen"!
Das sind KEINE Hänger!
Ich nehme an, dass du Tausende, sogar Hunderttausende Records per SQL an eine ISAM Tabelle angefügt hast? Über welche Anzahl sprechen wir denn? Ich behaupte, dass es bei dir recht Viele sind. Die Anzahl würde mich aber dennoch interessieren.

Und stundenlange Hänger? Definiere "stundenlang".

Bitte schau mal diesen Artikel. Da geht es auch explizit um das Thema:
https://ilx.alaska-software.com/index.p ... lumns.125/

Mit dem Wissen, dass bei einem USE diese Indexfelder nachgepflegt werden, kannst du doch keine Zauberei erwarten, dass dann alles innerhalb von wenigen Sekunden "repariert" ist, was du "mutwillig" durch den nativen Eingriff per SQL kaputt gemacht hast. Je nach Anzahl Indexe, Anzahl Records, Komplexität der Index Ausdrücke, ... kann das - im Worst-Case auch Stunden - dauern. Das liegt dann aber nicht an dem USE oder an der PGDBE.

Und du siehst, dass selbst das "Reparieren" von Tausenden von Records in einer verschmerzbaren Zeit erfolgt.

Aus dem obigen Artikel:
"Zur Veranschaulichung: Eine USE dauert 13 ms, eine USE mit Out-of-Sync-Prüfung dauert 42 ms und die USE mit Prüfung und Reparatur für eine defekte Zeile dauert in meinem einfachen Beispiel 46 ms. Bei 100 fehlerhaften Zeilen, die repariert werden müssen, dauert es 99 ms. Es ist wichtig zu verstehen, dass dieser Vorgang CPU-gebunden ist, da die Reparaturmaschine im Grunde einen großen SQL-Auftrag erstellt, den sie in einer einzigen Transaktion an den Server sendet. Der kostspielige Teil ist also die Auswertung des Indexausdrucks und natürlich die Anzahl der Indizes pro Tabelle."

Grüße
Frank
We love Xbase++, and you?
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,

gerne. Meine dbesys sah bisher so aus:

Code: Alles auswählen

      if !DbeLoad("DBFDBE",.t.)
         fehler(MSG_DBE_NOT_LOADED)
      endif
      if !DbeLoad("NTXDBE",.t.)
         fehler(MSG_DBE_NOT_LOADED)
      endif
      if !DbeBuild("DBFNTX","DBFDBE","NTXDBE")
         fehler(MSG_DBE_NOT_CREATED)
      endif

      // use DBF as default
      DbeSetDefault( "DBFNTX" )

      DbeInfo(COMPONENT_ORDER, DBE_LOCKMODE, LOCKING_EXTENDED)
      DbeInfo(COMPONENT_ORDER, NTXDBE_LOCKRETRY, 500000) 
      DbeInfo(COMPONENT_ORDER, NTXDBE_LOCKDELAY, 10) 
      DbeInfo(COMPONENT_DATA, DBFDBE_LIFETIME, 0)  

      if !DbeLoad("pgdbe")
         fehler("PostgreSQL DatabaseEngine konnte beim Programmstart nicht geladen werden!")
      endif
      DbeInfo(COMPONENT_DATA, PGDBE_ISAM_RECCOUNT_CHECK_ALWAYS, .f.)
      DbeInfo(COMPONENT_DATA, PGDBE_ISAM_ORD_CHECKANDFIX_KEYS, .t.)
Und damit hatte PGDBE_ISAM_ORD_CHECKANDFIX_KEYS offensichtlich keine Auswirkung. Nach Änderung in:

Code: Alles auswählen

      .
      .
      if !DbeLoad("pgdbe")
         fehler("PostgreSQL DatabaseEngine konnte beim Programmstart nicht geladen werden!")
      endif
      DbeSetDefault( "pgdbe" )
      DbeInfo(COMPONENT_DATA, PGDBE_ISAM_RECCOUNT_CHECK_ALWAYS, .f.)
      DbeInfo(COMPONENT_DATA, PGDBE_ISAM_ORD_CHECKANDFIX_KEYS, .t.)  
      DbeSetDefault( "DBFNTX" )
scheint es nicht mehr ignoriert zu werden, jedoch führt jetzt das dbusearea() – noch vor dem Öffnen der Indexe - im ISAM-Modus zu stundenlangen Hängern (500 k Datensätze), ohne dass wirklich was passiert:
test2.png
test2.png (324.2 KiB) 3203 mal betrachtet
Offensichtlich werden hierbei jedoch die Index-Felder bei mir immer noch nicht gefüllt, weil das dbuseArea() immer solange dauert und:
test3.png
test3.png (24.12 KiB) 3203 mal betrachtet
Du siehst, dass hier 438790 DS mittels Pass-Through angefügt wurden, was < 1 Std. dauerte, per ISAM-SQL würde es länger als 6-8 Std. dauern (geschätzt, genaue Daten hab ich Eurem Support letztes Jahr mitgeteilt). Der Wert bleibt bei mir auch nach jedem dbuseArea() und ewigem Abwarten (bis der nächste Code ausgeführt wird) so.

In der Hilfe steht:
Function DbeSetDefault() is used to define the default or current DBE. The affected settings depend on the current DBE or on the file format managed by the DBE
Sorry, da hab ich nicht rausgelesen, dass mit current DBE nur die DBE gemeint ist, die mit DbeSetDefault() gesetzt ist. Denke, da würden mehrere drüber stolpern, deshalb hab ich es hier explizit erwähnt.

Hier sind es "nur" 500k DS, bei dem einen Kunden sind es 1.3 Mio. - was jetzt für einen SQL-Server keine besonderen Datenmengen sind.

Das, was Du als mutwilliges kaputt machen beschreibst, hab ich bereits ausführlich mit Eurem Support diskutiert, es gibt dazu keine andere wirtschaftliche Möglichkeit. Die Geschwindigkeit per ISAM-SQL ist inakzeptabel, per Pass-Through gehts einigermaßen. Zur Info: Es handelt sich hierbei um Datanorm-DS, also anlegen, ändern und löschen von Artikeln (und anderem Zeugs) und umfangreichen Preisänderungen und Berechnungen. Der Vorschlag vom Support war, ein CSV-Script daraus zu machen und dieses direkt am PG-Server laufen zu lassen. Das wäre aber mit der Geschäftslogik ohne gigantischen Aufwand (den uns der Kunde nicht bezahlt, schließlich sind das ja für ihn ganz normale Datenmengen und schließlich haben wir ja SQL und andere Programme können das von Haus aus...) nicht umsetzbar, da damit z. B. auch nicht geupsizte DBF-Dateien gepflegt werden.

Um nicht missverstanden zu werden: Ich finde die Pass-Through-Geschichte genial, es macht richtig Spaß und die Geschwindigkeit ist gut, wenn der PG richtig konfiguriert ist. Damit können wir ganz gut mit solchen Datenmengen umgehen, was vorher ohne ADS nicht möglich war (2 GB-Grenze etc.). Der Weg dahin war lang, steinig und von vielen PDRs gepflastert, aber inzwischen funktioniert das ganz gut.

Nur unser Schnellschuß, wg. der Datenmenge und der 2 GB-Grenze den ISAM-SQL-Weg zu wählen, war ein Fehler. Eine große Waren-Wirtschaft stellt man nicht mal eben so an einem Tag von DBFNTX auf komplettes Pass-Through um, dafür gibts ISAM-SQL. Dann gingen die Probleme aber erst richtig los, viele Mails und PDRs bezüglich Geschwindigkeit, Stabilität und Kompatibilität folgten. Das kostete uns unendlich viel Zeit.
Aber: Inzwischen habt Ihr viel getan und viel optimiert und gerade mit dem aktuellen Beispiel Eures SQL-Browses habt ihr eine Möglichkeit aufgezeigt, wie man beide Welten verbinden kann: Bequemes ISAM-SQL gepaart mit Pass-Through. Das hab ich umgesetzt und an unsere Waren-Wirtschaft angepasst, ein paar weitere PDRs folgten, einige sind bereits gefixt. Aktuell verhindern noch 2 Probleme den erfolgreichen Einsatz:

- diese beschriebene Problematik hier, für die es aber bereits eine Lösung von Euch gibt, die nur bei mir noch nicht funktioniert
- der längst gemeldete Fehler vor Jahren, dass ein Beschreiben eines Indexfeldes im ISAM-SQL-Modus zu einer Veränderung des Satzzeigers führt

Ich hoffe, das kommt bei Dir nicht wieder als Rumgemeckere an :wink:
es grüßt

Werner

<when the music is over, turn off the lights!>
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 »

:? Werner,

du denkst (noch) zu sehr ISAM.

1) 500K Datensätze oder sogar Millionen Datensätze zu schreiben ist auch für eine SQL Datenbank nicht Nichts. Egal mit welchem Werkzeug.
2) die Indexschlüssel sind ja das Problem, oder? Die müssen alle über die Xbase++ Runtime geschleust werden, da du ja dort Funktionen aufrufen könntest (also die Indexausdrücke), die ein SQL Server ja nicht kennt.

Du gehst nicht an dein Problem, sondern erwartest, dass es wie früher funktioniert. Tut es, dauert aber.

Denke um.

Zum Beispiel (ich kenne dein Szenario nicht wirklich) sagst du doch, dass die Aufbereitung der Daten "nur" 1 Stunde dauert. Dann mache diese Aufbereitung doch in eine separate Tabelle. Ohne Indexe oder max mit einem einzigen Index. Und markiere in deiner Working/Produktiv Tabelle jeden Record, den du in dieser separaten Tabelle hast anfassen müssen. Wenn du nun einen Produktiv-Record lesen musst, dann schaue nach dem "Bin-ich-markiert" Flag und übertrage dann (natürlich per ISAM, damit die Indices mitgepflegt werden) den Inhalt in die Produktiv-Umgebung/Tabelle und setze das Flag zurück. Damit verlagerst du das Update. Bzw. wenn der Record produktiv noch nicht da ist, dann lege ihn neu an.

Oder der Ansatz mit der CSV. Generiere dir eine CSV, übertrage diese auf den SQL Server und lese sie dann lokal auf dem SQL Server ein. Das fluppt. Schneller geht nicht. Gepaart mit meinem vorherigen Ansatz eventuell noch schneller.

Was weiß ich.
Du wirst aber Code anfassen müssen. Du kannst nicht Alles auf Alaska verlagern. Ineffizienter Code wird ineffizienter Code bleiben!
Das wäre aber mit der Geschäftslogik ohne gigantischen Aufwand (den uns der Kunde nicht bezahlt, schließlich sind das ja für ihn ganz normale Datenmengen
Wie kommst du darauf? Das will ich mal sehen? Ganz normale Datenmengen? Die auf Schnipp importiert sind und dann noch eine Geschäftslogik läuft, die Dinge neu berechnet? Aha!

Und wenn deine Arbeit Keiner bezahlt, dann - und das ist nicht böse gemeint - verkaufst du das schlecht. Denn ich bin mir sicher, dass deine Geschäftslogik einzigartig ist und dem Kunden so sehr hilft. Das soll er mal woanders suchen und finden. Du hälst deren Geschäft ja auch am Leben mit deiner Arbeit. Dafür muss man auch mal Geld verlangen (können).

Ich kann dir nicht viel mehr sagen.
Du bist dran. Ich meine nicht hier, aber eventuell musst du umdenken. Umstellen. Neu codieren. Anders codieren. Zumindest an dieser Stelle deines Bulk-Imports. Der Rest ist ja in Ordnung. So verstehe ich das zumindest.

Grüße
Frank
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 »

Jetzt antworte ich mir schon selbst ...

Zu meiner Idee mit der separaten Tabelle: wenn der Import abgeschlossen ist, dann kannst du ja - auch schon nachts - einen Thread starten, der die Daten von dieser Temp-Tabelle in die Produktiv-Tabelle überträgt und nicht wartet, bis der Record angefasst/gelesen/geändert werden soll. Dann kann man jederzeit arbeiten. Eventuell wird dann aber der SQL Server gesättigt.

Und noch filigraner: wenn du dir merkst, welche Records am oftesten abgefragt werden (kannst ja einen Zähler mitlaufen lassen) und diese als erstes in dem Nächte-Thread updaten.

Und wenn ich noch eine Weile drüber nachdenke, kommen mir bestimmt noch mehr Ideen.
Du bist der Herrscher der Daten und kannst jegliche Optimierung einbauen.

Aber es bleibt übrig: du musst deinen Code anfassen.

Grüße
Frank
We love Xbase++, and you?
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
Frank Grossheinrich hat geschrieben: Fr, 10. Mär 2023 15:50 Aber es bleibt übrig: du musst deinen Code anfassen.
Werner, Frank hat absolut recht. Es geht nicht anders......
Valar Morghulis

Gruss Carlo
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 und Ramses,

danke für Eure Ausführungen.

Den Code hab ich ja bereits angefasst und auf Pass-Through umgeschrieben. Auch versch. Suchfunktionen, die mit den SQL-Möglichkeiten einfach schneller und flexibler sind.

CSV auf den SQL-Server verlagern: Damit werden die ISAM-SQL-Felder aber auch nicht gepflegt!
500K Datensätze oder sogar Millionen Datensätze zu schreiben ist auch für eine SQL Datenbank nicht Nichts. Egal mit welchem Werkzeug.
test2.png
test2.png (324.2 KiB) 3500 mal betrachtet
Das sind keine Datenmengen für einen 64bit SQL-Server mit 64 GB RAM und genügend Cores.

Frank, Deinen Vorschlag über eine separate Tabelle kann ich nicht nachvollziehen. Wie geschrieben, es geht um Artikel. Per Datanorm werden diese gepflegt. Es kommen neue hinzu, alte werden gelöscht, extrem viele werden berichtigt - meist der Preis und der Artikel-Text. Anlage von neuen Sätzen entstehen i. d. R. nur beim 1. Lauf, wenn man einen neuen Großhändler aufnimmt, oder neue Warengruppen. Was soll da eine separate Tabelle bringen? Irgendwann müssen die Felder der artikel.dbf geupdatet werden, inkl. der Indexe. 1 - 3 Stunden für so einen Lauf sind ok, wenn danach die Indexe funktionieren.

Wir arbeiten hier mit einem Browse, der Kunden ruft den Artikelstamm auf, es wird ein Browse angezeigt, in dem er dann suchen, filtern, bearbeiten und löschen kann. Hier dann die angezeigten Daten über die separate Tabelle zu aktualisieren, wäre aufwändig. Ohne groß nachzudenken: Vermutl. wüsste ich bei einem XBPBrowse() gar nicht, welcher DS ein Update braucht? Doch, mittels des Skip-Blocks? Das würde das Browse aber vermutlich anfänglich sehr langsam machen?

Im Falle einer Artikelnr.- oder Matchcode-Änderung würde ich den Artikel übrigens gar nicht mehr finden, er steht ja so "nur" in der separaten Tabelle.

Schlecht verkaufen: Google doch mal, wieviele Waren-Wirtschafts-Systeme es gibt. Wir alle konkurrieren hier mit den großen Herstellern wie Sage, Büroware, Lexware, Vario etc. Einige gibts für lau, einige schon unter 1000,-- - ohne wirkliche Beschränkung von Datensätzen, mit einem Funktionsumfang, der einen erschlägt.
Zu meiner Idee mit der separaten Tabelle: wenn der Import abgeschlossen ist, dann kannst du ja - auch schon nachts - einen Thread starten, der die Daten von dieser Temp-Tabelle in die Produktiv-Tabelle überträgt und nicht wartet, bis der Record angefasst/gelesen/geändert werden soll. Dann kann man jederzeit arbeiten. Eventuell wird dann aber der SQL Server gesättigt.
Das dauert dann aber wieder > 8 Stunden, beim letzten ISAM-Versuch > 14 Std. Danach hat der Kunde abgebrochen.

Nochmal: Die Lösung per Pass-Through ist akzeptabel, das Problem sind lediglich die ISAM-SQL-Felder. Hab vom Support leider noch keine Antwort erhalten. Alternativ pflege ich die künftig bei jedem insert und update einfach selbst, ist ja kein Hexenwerk.

Mein DB-Profi arbeitet übrigens gerade an einer Optimierung des dbPack() - Befehls...
es grüßt

Werner

<when the music is over, turn off the lights!>
Benutzeravatar
Marcus Herz
1000 working lines a day
1000 working lines a day
Beiträge: 851
Registriert: Mo, 16. Jan 2006 8:13
Wohnort: Allgäu
Hat sich bedankt: 39 Mal
Danksagung erhalten: 192 Mal
Kontaktdaten:

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

Beitrag von Marcus Herz »

Ich hatte am Anfang meiner Tests die ISAM Felder per Trigger upgedatet. Geht aber nur, wenn keine xbase Funktionen verwendet werden die nicht durch SQL abgedeckt sind
Gruß Marcus

Erkenne, was du findest, dann weißt du, wonach du gesucht hast
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 Marcus,

das mit den Triggern überlege ich auch ernsthaft.
Das hätte den riesen Vorteil, dass die ISAM-Felder "atomisch" in der gleichen Transaktion aktualisiert werden, dadurch würden zu keinem Zeitpunkt inkonsistente Indexe existieren.
Bisher sehen alle relevante Funktionen so aus, als ob sie auch in SQL implementierbar wären - einige habe ich sogar schon mal automatisch übersetzt wegen FILTER (siehe z.B. XbaseToSQL).
Das Problem damit liegt in der Pflege - wenn die Trigger manuell angelegt werden, dann müssen sie immer angepasst werden wenn ein neuer Index dazukommt, das darf man nie vergessen, und das macht mir Sorgen.
Viele Grüße,
David
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 »

Marcus und David,

nein, das ist keine gute Idee.
Erstens wage ich ernsthaft zu bezweifeln, dass das ein Performance Problem löst! Denn auch ein Trigger braucht Zeit.
Und zweitens - viel wichtiger - gehören diese Felder/Spalten Alaska Software alleine! Es geht hier nicht um Besitzrechte, aber wir leisten keinen Support für selbst befüllte Indexspalten. Wir können keinen Support leisten. Das führt ja zu beliebigen Problemen. Und noch gewichtiger, wir machen eure Arbeit zunichte, wenn wir eine Optimierung an den Spalten vornehmen und z.B. deren Zusammensetzung ändern oder Sonstiges ändern. Dann seid ihr gekniffen.

Niemals nicht, bitte!

Mahnende Grüße
Frank
We love Xbase++, and you?
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 »

Frank,

es geht mir hier nicht um die Performance, die ist für mich ausreichend geklärt, sondern um die Datenintegrität.
Zu diesem Punkt sind wir bisher gekommen in Using SQL INSERT and UPDATE with ISAM emulating tables, in particular with indexed columns.
Ich sehe keine Alternative, die die Datenintegrität gewährleisten kann in diesem Fall.
Du hast aber absolut Recht, das Format der Index-Spalten ist von Alaska nicht garantiert gleich zu bleiben, also darf ich nicht selber die Trigger generieren bzw. aktualisieren.
Nur Alaska dürfte das.
Viele Grüße,
David
Benutzeravatar
Marcus Herz
1000 working lines a day
1000 working lines a day
Beiträge: 851
Registriert: Mo, 16. Jan 2006 8:13
Wohnort: Allgäu
Hat sich bedankt: 39 Mal
Danksagung erhalten: 192 Mal
Kontaktdaten:

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

Beitrag von Marcus Herz »

Ich geb dir Recht, Frank, Die Indexfelder sind in der Hoheit von Alaska. Aber eben wegen der Datenintegrität hab ich das mal ausprobiert, (aber dann nicht mehr benötigt).
Da der Trigger immer nach dem Update ausgeführt wird, muss er absolut das gleiche Ergebnis liefern wie eure interne Berechnung des Indexkeys.
Solltet Ihr aber mal die Definition ändern wollen, dann müssten ja ALLE bestehenden Indices neu erstellt werden, und dann ALLE Programme mit der aktuellen PGDEB laufen.
Ich kann mir kein solches Sceanrio vorstellen.
Gruß Marcus

Erkenne, was du findest, dann weißt du, wonach du gesucht hast
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 »

Marcus,

ich sehe es so, dass das Szenario nur überhaupt vorstellbar wäre, wenn Alaska uns im Voraus darüber informiert, damit wir zumindest den Zeitpunkt für die Datenkonvertierung festlegen könnten.
Trotzdem lasse ich doch die Finger von den Triggern.
Ich hoffe aber, dass Alaska dies übernimmt, oder eine andere 100% sichere Lösung finden kann.
Viele Grüße,
David
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 »

Teiletappenerfolg <puh, schwitz> ... ja, bitte nicht in die ISAM Metadaten eingreifen!!!!!

Aber auch zum Rest ... es geht immer noch um das Modifizieren von ISAM Daten aus einer anderen Nicht-Xbase++-Anwendung ... sollte man doch mal die Kirche im Dorf lassen. Wo wird denn so eine hoch-frequente Synchronisation notwenidg sein? Wenn ihr das wirklich braucht, dann macht es mit Xbase++ und NICHT mit einem Fremd-Tool! Dann Finger weg von ISAM Tabellen.

Aber man kommt ja schon sehr nahe an einen (fast-)synchronen Zustand: schreibt ein kleines Xbase++ Programm, das alle Minute (bitte macht das nicht jede Sekunde) die betroffenen Tabellen öffnet und auch gleich wieder schließt. In dem Öffnen-Zyklus werden die Indexspalten ja gepflegt. Und ist ja egal, welche Anwendung diese Tabellen öffnet. Das darf ja gerne außerhalb der eigentlichen Anwendung stattfinden.

Bange Grüße
Frank
We love Xbase++, and you?
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 »

Glaub mir Frank, überhaupt die Idee durch den Kopf gehen zu lassen, selber in die ISAM Metadaten einzugreifen, war eher eine Akt der Verzweiflung, einer der letzten zu ausschließenden Zweige im Entscheidungsbaum.
es geht immer noch um das Modifizieren von ISAM Daten aus einer anderen Nicht-Xbase++-Anwendung
Ja, das war vom Anfang an klar, und es wurde behauptet, dass dies möglich sei. Ist es auch, aber derzeit nur mit dem Risiko von sporadischen, nicht nachvollziehbaren Datenkorruptionen durch die über 30 Jahre entwickelte Xbase++ Anwendung, die zurecht erwarten darf, dass die Indexe immer korrekt sind. Das ist also noch keine Option.

Um beim Kirchenmetapher zu bleiben: Heilig sei die Datenintegrität, sie ist des Datenbankprogrammierers oberstes Gebot. Und die Kirche muss wohl im Dorf der Verantwortung bleiben.

Bei meinem Chef habe ich vom Anfang an behauptet, dass Datenmodifikationen in der ISAM Datenbank ausschließlich über Xbase++ erfolgen dürfen, da habe ich mir sogar eine allgemeine in Xbase++ geschriebene Zwischenschicht vorgestellt, siehe Writing to ISAM-Emulated databases from languages other than Xbase++.
Er hat sich aber auf Grund einiger Aussagen von Alaska die Hoffnung gemacht, dass ein direkter Schreibzugriff aus anderen Sprachen (ggf. mit Auflagen) möglich sein könnte. Habe ich auch gehofft.

Also bin ich jetzt nach der Teiletappe an einem Scheideweg. Entweder:
1. Bleibe ich bei meiner bisherigen Position,
2. Finde ich (gemeinsam mit Alaska) einen sicheren Lösungsweg, oder
3. Stürze ich gleich in den Abgrund der beliebigen Datenkorruptionen, direkt in die Programmiererhölle.

3. wäre der Fall wobei Inhalt und Metadaten nicht in der gleichen Transaktion aktualisiert werden, schließe ich natürlich aus! Selbst "Synchronisierungen" im Sekundentakt wären nicht ausreichend um sicher davor zu schützen, wie ich in Using SQL INSERT and UPDATE with ISAM emulating tables, in particular with indexed columns geschrieben habe.

2. würde voraussetzen, dass die Fremdanwendung innerhalb ihrer Transaktion veranlassen könnte, dass die Metadaten vor dem Commit aktualisiert werden. Theoretisch denkbar wäre, dass Alaska ein entsprechendes Stored Procedure zur Verfügung stellt, aber dann könnte es genausogut (oder besser) im Trigger aufgerufen werden, also habe ich bisher nur von Triggern geredet. Es ist mir klar, dass dies für Alaska nicht ganz leicht zu implementieren wäre.

1. ist leider beim jetztigen Stand das einzige, was mir übrig bleibt.
Viele Grüße,
David
Benutzeravatar
nightcrawler
1000 working lines a day
1000 working lines a day
Beiträge: 650
Registriert: Di, 24. Apr 2012 16:33
Wohnort: 72184 Weitingen
Hat sich bedankt: 3 Mal
Danksagung erhalten: 96 Mal
Kontaktdaten:

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

Beitrag von nightcrawler »

Hallo David,
genau an diesem Punkt würde ich mir Gedanken machen, die einzelnen Dienste separat per API anzubieten, so dass andere Programmiersprachen darauf zugreifen können (Stichwort Microservices). Diese schreibst Du - zumindest erst einmal - in Xbase mit der funktionierenden Zugriffsschicht. Baue Dein Programm schrittweise auch so um, die API zu verwenden. Sollte später mal ein Wechsel weg von PG notwendig sein - zB weil es der Kunde wünscht - brauchst du nur noch die Zwischenschicht anzupassen.
--
Joachim
Joachim Dürr Softwareengineering
https://www.jd-engineering.de
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 »

genau an diesem Punkt würde ich mir Gedanken machen, die einzelnen Dienste separat per API anzubieten, so dass andere Programmiersprachen darauf zugreifen können (Stichwort Microservices).
Das ist zwar ein sehr eleganter Weg und im Hinblick auf eine Trennung von Front- und Backend ohnehin, wie Du auch anmerkst, ein vernünftiger Schritt, erfordert aber zunächst einmal eine zusätzliche (Server-)Instanz - und die Bereitschaft der "Gegenseite", mit der API zu reden, statt ein paar SQL-Statements auf eine Datenbank abzusetzen. Ich würde deshalb eher (oder zusätzlich) darüber nachdenken, das über Transaktions- bzw. Synchronisationstabellen zu lösen, die von der Anwendung überwacht werden. Wenn die anderen sowieso in die Datenbank schreiben wollen, dann sollen sie das halt tun, aber nicht z.B. in der aktiven Artikelverwaltung, sondern in einer Fassung davon, die nur zum Abgleich benutzt wird.
Herzlich,
Tom
Benutzeravatar
nightcrawler
1000 working lines a day
1000 working lines a day
Beiträge: 650
Registriert: Di, 24. Apr 2012 16:33
Wohnort: 72184 Weitingen
Hat sich bedankt: 3 Mal
Danksagung erhalten: 96 Mal
Kontaktdaten:

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

Beitrag von nightcrawler »

Hallo Tom,
man muss wegkommen von der "ich will immer und überall SQL absetzen" hin zu kontrolliertem Zugriff auf einzelne Ressourcen bzw Dienste. Schließlich bist Du nachher der Schuldige, wenn der Kunde einen unkontrollierten SQL Befehl absetzt und die DB zerschießt. Es ist ja dann Dein Programm, welches nicht mehr läuft. Oft genug so erlebt früher bei Kunden: Dr ADS funktioniert nicht mehr richtig - die Daten sind korrupt - usw. Meist konnten wir nach viel Suchen nachweisen, das eben nicht der ADS sondern eine wildgewordene Anwendung oder ein Programmierfehler dafür Schuld ist - aber die unnötige Arbeit bleibt.
--
Joachim
Joachim Dürr Softwareengineering
https://www.jd-engineering.de
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 »

Hallo, Joachim.

Prinzipielle Zustimmung. Ich schrieb das ja weiter oben - für meine Datenbanken trage ich die Verantwortung, was die Integrität anbetrifft, aber auch aus der Perspektive von Datensicherheit und -schutz, und ich würde es grundsätzlich nicht zulassen oder sogar fördern, dass Fremdprogramme darin herumstochern, weil das immer auf mich zurückfallen wird. Aber hier ist die Situation ein wenig anders, weshalb die Nutzung einer Synchronisationsschicht möglicherweise ein gangbarer Weg ist. Einer von mehreren - es geht ja darum, die beste Lösung für David zu finden, und nicht allgemein best practice zu skizzieren.
Herzlich,
Tom
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 Joachim und Tom,

vielen Dank für Euren Antworten!

Microservices wären sicherlich ein guter langfristiger Ansatz, schon von Steffen Pirsig empfohlen worden:
Writing to ISAM-Emulated databases from languages other than Xbase++

Tom hat aber ziemlich gut den Punkt getroffen, was meine Situation betrifft. Dazu kommt, dass ich Angestellter bin und in knapp über einen Jahr in Rente gehe. Mein Chef will nicht gezwungen werden, für immer und ewig alles auf Xbase++ zu setzen, z.B. aus Arbeitsmarkterwägungen - Xbase++ Programmierer sind relativ rar. Faktisch ist aber so viel Geschäftslogik darin verwickelt, dass die Anwendung voraussichtlich viele Jahre noch bestehen muss.

Die Anwendung ist unsere firmeninterne ERP System (bestehend aus 2 Programmen: Materialwirtschaft und Finanzbuchhaltung), es gibt keine externe Kunden, und es ist nun extrem unwahrscheinlich, dass weg von Postgres gewechselt wird. Sie ist über mehr als 30 Jahren seit der Grundung der Firma mitgewachsen, ursprünglich in Clipper mit "nackten" DBF/CDX/FPT Dateien auf dem Fileserver (der Zustand als ich die Programmierung vor ca. 15 Jahren übernommen habe), dann mit Xbase++ und ADS (was eine erhebliche Verbesserung ausgerechnet betreffend der Korruptionen der Indexdateien brachte), und nun seit Mai 2021 mit Postgres/PGDBE.

Die Anwendung ist überhaupt nicht dienstorientiert programmiert, die Datenbankzugriffe sind sehr eng mit der komplexen (hybrid-textbasierten) Benutzeroberfläche verwoben, Richtung (inhaltliche) Microservices wäre ein langer, steiniger Weg um brauchbare Abstraktionen (APIs) herauszudestillieren. Das wird nicht während meiner verbliebenen Arbeitszeit möglich sein. Die Idee von Tom, Synchronisationstabellen zu nutzen, ist schon interessant, aber ich befurchte damit Probleme mit Konfliktresolutionen und auch mit der Benutzerakzeptanz wenn Daten nicht immer gleich sind zwischen den Anwendungen.

Derzeit optimal wäre für mich nachwievor, wenn Alaska eine triggerbasierte Lösung implementieren würde. Das wäre nicht nur für Fremdanwendungen (s. unten) ideal, sondern auch für Datenbankadministratoren, die z.B. mit pgAdmin4 Datenkorrekturen bzw. Importe vornehmen. Das kann ich aber nicht von Alaska verlangen, sondern nur höflich darum bitten, dass sie dies für ein zukünftiges Update in Betracht ziehen (als zuschaltbare Option).

Mir schwebt nun vor, erstmal einen allgemeinen REST-Dienst zu entwickeln, die eine API anbietet, die im Effekt SELECT/INSERT/UPDATE/DELETE anbietet (bezogen auf __deleted). Das wird für die Fremdanwendungen aufwändig im Vergleich zu SQL Statements, ist in dem Sinne keine schöne Lösung, und wird auch nicht wirklich brauchbar für datenadministrative Zwecke. Ich sehe aber beim jetzigen Stand keine gängige sichere Alternative.

Schließlich zum Begriff "Fremdanwendungen": Damit meine ich nur Anwendungen, die (vermutlich eher firmenintern als extern) in der Verantwortung des ERP-System-Verantwortlichen entwickelt werden. Das wird ein sehr kleiner Entwicklerkreis sein, möglicherweise nur eine Person. Die existierende Geschäftslogik in den relevanten konkreten Fällen müsste natürlich sehr sorgfältig analysiert werden, und diese vermutlich erstmal nachgeahmt. Aber genau dieser Prozess sehe ich als Anfang und Einstieg in die spätere Definition von "inhaltlichen" REST-APIs. Entwicklung bei Bedarf in überschaubaren Schritten, wie der Gärtner, der wartet bis Pfade über den Rasen getrampelt werden bevor er Steinplatten legt...
Viele Grüße,
David
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 »

Die Idee von Tom, Synchronisationstabellen zu nutzen, ist schon interessant, aber ich befurchte damit Probleme mit Konfliktresolutionen und auch mit der Benutzerakzeptanz wenn Daten nicht immer gleich sind zwischen den Anwendungen.
Nun, wenn im Hintergrund in einem gesonderten Thread oft genug geprüft wird, ob es Neues in der Synchronisationstabelle gibt (was ja über deren Metadaten leicht zu ermitteln ist), dürfte diese Latenz minimierbar sein.
Herzlich,
Tom
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 »

Nun, wenn im Hintergrund in einem gesonderten Thread oft genug geprüft wird, ob es Neues in der Synchronisationstabelle gibt (was ja über deren Metadaten leicht zu ermitteln ist), dürfte diese Latenz minimierbar sein.
Konflikte werden aber vermutlich doch entstehen, da haben wir fast eine ähnliche "nicht atomische" Problematik wie bei den Indexen, mit dem Unterschied, dass es hier zumindest theoretisch Lösungswege geben könnte (die aber auch den Benutzern nerven könnten). Schließe ich also nicht 100% aus, aber es könnten vielleicht ziemlich viele solche Tabellen nötig werden.
Viele Grüße,
David
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 »

Hallo David,
und die Anderen,

es ist schon fast unfair, dass Xbase++ alles leisten soll: ISAM .AND. Befüllung aus Fremd-Applikation und es muss alles in Sync sein und bleiben, im Millisekundentakt. Also, die Fremd-Applikation schießt irgendwelche Informationen rein und Xbase++ ISAM soll vollumfänglich und sofort damit umgehen können. Dir sind ja schon 60 Sekunden out-of-sync nicht ausreichend.

Ganz ehrlich: nein, dafür ist das Feature nicht gedacht.

Öffne bei jeder ISAM Mutation/Operation die Tabelle explizit, mache, was zu machen ist und schließe die Tabelle wieder. Dann hast du Gewähr, dass für deine Mutation/Operation die Daten in-sync sind. Also öffne die Tabellen nicht einmalig und habe sie über den ganzen Lebenszyklus der Anwendung geöffnet. Aber auch hier könnte ja direkt nach dem Öffnen, die Fremdapplikation etwas ändern und dazu führen, dass du dann einen bestimmten Record nicht findest (wenn ein Schlüsselfeld mutiert wurde). Oder ein neuer Record hinzukam, der dann auch ISAM-seitig sofort benötigt und suchbar sein soll.

Wenn du so eine Granularität benötigst, dann darf keine Fremd-Anwendung in deine ISAM Tabellen reinschreiben. No way.
Dann muss die Geschäftslogik in Xbase++ bleiben und du musst die Geschäftslogik über Microservices bereitstellen.
Oder - und das kann ich überhaupt nicht empfehlen - implementiere ein eigenes Protokoll über Semaphoren oder Sonstiges, das beide Applikationen auswerten können. Aber dann implementierst du ISAM Mechanismen für andere Entwicklungswerkzeuge. Das kann es irgendwie auch nicht sein.

Mehr fällt mir dazu nicht ein.
Aber DANKE an alle fürs Mitdenken! Macht auch Spaß.

Grüße
Frank
We love Xbase++, and you?
Antworten