Inoffizielles deutsches Xbase-Forum

Frank Grossheinrich hat geschrieben: ↑Do, 29. Okt 2020 16:16 Also, ein Kunde kann mit einer anderen App, die NIX von ISAM weiß und NIX mit Xbase++ zu tun hat, Datensätze einfügen und sogar bestehende Records verändern (und das sogar, wenn das betroffene Feld in einem Index verwendet wird; Worst Case). Das kriegt die PGDBE mit.

Ich schränke es ein wenig ein: das geht NICHT konkurrierend. Wenn also eine externe App Daten in die ISAM Tabellen stopft oder ändert (lesend geht jederzeit), darf/soll die Xbase++ Anwendung diese Tabellen nicht geöffnet haben. Denn beim nächsten USE fällt diese Diskrepanz auf und wird repariert. Automatisch. ... Da ist beim Erkennen einer bestimmten Situation noch ein Bug in der PGDBE, der noch gefixt werden muss. Wenn das fluppt, dann ist REINDEX "abgeschafft".

GENAU DAS haben wir gesucht und vermeintlich in der Xbase++ Version, die vor gut einem Jahr aktuell war auch gefunden. Dort wurde genau dieser Ansatz schon beworben, mir ist es prinzipiell egal, ob es mit DBReindex funktioniert oder mit USE, mit USE ist natürlich um einiges besser, weil dann nicht der Index komplett neu aufgebaut werden muss, wenn ich das jetzt richtig verstanden habe. Wir wollten genau da ansetzen und mit externen Programm Datensätze einfügen und ändern, ohne natürlich die ISAM Spalten/Tabellen anzurühren.
Umso ärgerlicher war es dann für uns, dass da dieser Bug drin war. Natürlich verstehe ich, dass nicht alles sofort und gleich gelöst werden kann, wenn jemand schreit, als Softwareentwickler ist das bei uns ja ganz genau dasselbe. Aber rein aus unserer subjektiven Sicht ist es dann richtig ärgerlich, wenn wir diese Funktionalität letztes Jahr theoretisch schon eingekauft haben und sie jetzt wieder kaufen müssen, weil unsere Subscription abgelaufen ist und eben ein Bug drin war, den wir nebenbei bemerkt auch noch selbst gefunden haben. Ich hoffe Sie können das Nachvollziehen Herr Grossheinrich, für uns sind 1000-2000 EUR (je nach Ausführugn) nicht gerade wenig Geld, vor allem dann, wenn man eigentlich der Meinung war, schon genau das gekauft zu haben, wofür man jetzt wieder Geld ausgeben soll.

Hallo Benz

GENAU DAS haben wir gesucht und vermeintlich in der Xbase++ Version

Das geht ja auch. Nur nicht so wie du es umsetzten willst.
Die ISAM DBF Emulation versucht dir auf einem PG Server die von den DBF Dateien gewohnten Funktionen zu bieten.
Wenn du Daten mit anderen APP's nutzen bezw. gleichzeitig damit arbeiten willst darfst du nicht die ISAM-Emulation verwenden sondern musst die SQL-Funktionen nutzen die dir die PGDBE auch bietet. Damit geht es dann absolut Problemlos und ohne irgeneinen Gedanken an Index usw. Nur musst du dann den Code komplett überarbeiten oder neu schreiben. So sind jedenfalls meine eigenen Erfahrungen.

Hmm. Ich glaube das kann so nicht funktionieren.

Wenn ich die ISAM benutze, dann muß ja die DBE sich um die korrekte Mitführung von Index und anderen Kleinigkeiten kümmern. Ist halt so wenn man SQL machen möchte, ohne auf Db...() Funktionen verzichten zu möchten oder zu können.

Wenn man dann von extern Daten ändert muß man zusehen, wie diese Daten dennoch konsisten bleiben. Alaska regelt das, wie Frank beschrieb, dadurch, das irgend ein Mechanismus beim Use das kontrolliert und nachführt.

Das heißt aber für mich: Wenn ich die Tabelle offen habe, und während ich die offen habe jemand per Extern die Daten ändert, dann werden Index etc. nicht nachgeführt. Weil da ja kein erneutes Use geschieht.

Für mich sieht das so aus als ob man in regelmäßigen Abständen oder zu bestimmten Funktionsaufrufen den Workaround von Frank durchführen muß. Egal ob da jetzt der Bug in der DBE ist oder nicht. Weil einfach die Situation hier nicht greift.

Oder habe ich da etwas überlesen oder mißverstanden?

Jan

Nein, Du hast nichts überlesen, denn genau das schrieb Frank: Im (unmittelbar) konkurrierenden Zugriff geht es nicht. Sonst schon. Wenn eine Anwendung die PGDBE im ISAM-Modus nutzt und jemand aktualisiert von außen außerhalb der Nutzungszeiten durch die Anwendung Tabellen, ist alles fein. Wenn es zugleich geschieht, riskiert man zumindest bis zur nächsten Tabellenöffnung via PGDBE/ISAM Datenprobleme. Leider ist es schwer für eine Nicht-PGDBE/ISAM-Anwendung, zu erkennen, ob gerade die Nutzung per PGDBE/ISAM stattfindet.

Der von Ramses (zum drölfzigsten Mal ) vorgeschlagene Weg ist natürlich der sehr viel elegantere, aber je nach Anwendung auch mit ungeheurem Zeitaufwand verbunden. Wer relativ schnell und für übliche Geschäftsanwendungen mit guter Performance auf SQL umsteigen will, ist mit der PGDBE im ISAM-Modus exzellent bedient. Ich mag das mit jedem Tag mehr.

Wenn es in diesem Szenario die Erforderlichkeit gibt, innerhalb der Datenbank mit Daten zu synchronisieren, die von außen kommen, kann man auch darüber nachdenken, Synchronisationstabellen einzuführen, die die PGDBE/ISAM-Anwendung per Watchdog überwacht.

Tom hat geschrieben: ↑Mo, 02. Nov 2020 16:19 Wer relativ schnell und für übliche Geschäftsanwendungen mit guter Performance auf SQL umsteigen will, ist mit der PGDBE im ISAM-Modus exzellent bedient. Ich mag das mit jedem Tag mehr.

Wie habt ihr das Problem des fehlenden Refresh im ISAM-Modus gelöst? Sprich:

- Tabelle öffnen
- irgendeinen Satz positionieren, Browse
- Satz wird jetzt von anderem User geändert und gespeichert
- Satz wird editiert ==> Daten sind alt!

Gleiches Szenario ohne ISAM, also dbf ==> Daten sind aktuell!

@Werner: Wir lesen die Datenquelle im Moment vor und nach jedem Edit ein, anders geht es nicht, und befriedigend ist das tatsächlich auch (noch) nicht.

Servus Tom,

ja schade eigentlich, wäre dieses Verhalten endlich gefixed, würden wir auch ernsthaft über einen Komplett-Umstieg von bestehenden Anwendungen nachdenken. So nutzen wir ausschließlich pass-through für neues und altes wird nach Bedarf umgeschrieben auf pass-through.


Zweites großes Problem besteht ja noch bei XbpBrowse mit vielen Datensätzen in der ISAM-Emu...

Hallo zusammen,

In der neuen Version vom 11.11.2020 sind einige Änderungen zu Isam.

Sind das Euere Probleme, die da behoben wurden?

Leider nein.

Sind leider nur kleinere Baustellen abgeschlossen.

Hallo Werner,

Werner_Bayern hat geschrieben: ↑Fr, 13. Nov 2020 0:14 Leider nein.

Können wir hierfür einen eigenen Thread aufmachen? Ich verstehe das Begehr noch nicht, hat aber glaube ich nix mit dem ursprünglichen Thema zu tun, oder?
Und die Dinge von Benz sollten behoben sein. So weit mein Verstädnis.

Gruß, Frank

Hi Tom,

Tom hat geschrieben: ↑Fr, 13. Nov 2020 7:30 Sind leider nur kleinere Baustellen abgeschlossen.

Das schmerzt ein wenig. Denn diese kleineren Baustellen haben uns sogar den Monats-Ende Termin verhageln lassen. Deshalb kam das Update erst jetzt. Weil wir uns die Finger wund getippt haben für die kleineren Baustellen.

Wie dem auch sei, wir sind weiter am Ball.

Grüße, Frank

Hallo, Frank.

Kleinere heißt ja nicht kleine. Aber es sind eben noch ein, zwei Großbaustellen offen - siehe Postings von mir und Werner weiter oben. Doch es wird - ich bin schon beim Testen!

Hi Tom,

Aber es sind eben noch ein, zwei Großbaustellen offen - siehe Postings von mir und Werner weiter oben.

Ich befürchte, dass immer irgndwelche Baustellen vorhanden sein werden.
Aber holt mich mal ab. Ich habe euer Begehr noch nicht verstanden!!
Könnt ihr es mal plakativer beschreiben?

Gruß, Frank

Frank Grossheinrich hat geschrieben: ↑Fr, 13. Nov 2020 11:56 Könnt ihr es mal plakativer beschreiben?

Sehr gerne: viewtopic.php?f=114&t=11814

ramses hat geschrieben: ↑Sa, 31. Okt 2020 6:37 Denkst du beim nutzen eines Mobil-Phones auch darüber nach unter welchen Personellen voraussetzungen es Hergestellt wurde?????

ich bin kein Handy Nutzer aber JA ich würde mir "nur noch" ein iPhone kaufen.

nicht wegen der Technik sondern wegen iOS 14x wo man bei "Datenzugriffen" einstellen kann welche "Werbung" man ERLAUBEN will.

AUGE_OHR hat geschrieben: ↑Do, 04. Feb 2021 4:53 nicht wegen der Technik sondern wegen iOS 14x wo man bei "Datenzugriffen" einstellen kann welche "Werbung" man ERLAUBEN will.

Ein Nokia 2720 mit PrePaid Karte reicht doch für Notfälle vollkommen.