Verwendung von Aliasoperatoren bei Datenbankfeldern

[Martin Altmann]

Hallo Jimmy,

was heist "wechselseitiger Ausschluß" ?

damit ist gemeint, dass auch bei einem Zugriff in die Indexdatei bisher immer nur eine durfte und die anderen warten mussten (latürnich auch bei jedem Skip über die Datensätze) -> Exclusive!
Dies ist jetzt dann nur noch bei Schreibzugriffen auf den Index so!

Viele Grüße,
Martin

[AUGE_OHR]

moin,

Hallo Jimmy,

was heist "wechselseitiger Ausschluß" ?

damit ist gemeint, dass auch bei einem Zugriff in die Indexdatei bisher immer nur eine durfte und die anderen warten mussten (latürnich auch bei jedem Skip über die Datensätze) -> Exclusive!
Dies ist jetzt dann nur noch bei Schreibzugriffen auf den Index so!

aber wer ist einer und was sind die anderen ?

ist damit Xbase++ -> Cl*pper oder Xbase++ Thread (Workspace)
oder was gemeint ?

... das Xbase++ , im gegensatz zur Cl+pper, beim "lesen" mit Index
einen "implizites lock" auf den Index macht (deshalb die DBSkip Errors)
ist mir bekannt. Mache ich also DBFNTX per LOCKING_EXTENDED
dann Cl*pper kompatibel (und wenn wie) ?

gruss by OHR
Jimmy

[Martin Altmann]

Hallo Jimmy,
was "wer" bedeutet, ist völlig unherheblich!
Es durfe nur einen Zugriff auf die Indexdatei geben - parallele Zugriffe sind nicht zulässig gewesen.
Dies ist jetzt anders (latürnich nicht Clipper-kompatibel!!!), wenn nur lesend zugegriffen werden soll.
Ob das jetzt 97 User sind, die parallel auf die Indexdatei zugreifen, oder ein User, der einen Druckjob und eine Eingabemaske parallel laufen/offen hat, ist dabei völlig unerheblich.

Viele Grüße,
Martin

[brandelh]

Hi Jimmy,

normalerweise führt Clipper und Xbase++ bei shared geöffneten DBF mit Indexen zwar gleichzeitige Lesezugriffe auf die DBF aus, aber bei einem SEEK wird auch beim Lesen intern ein FLOCK auf die INDEX Datei durchgeführt. Das kann im Netz bei mehren Stationen und häufigen Abfragen die Performance erheblich bremsen. Bei EXTENDED... vertraut nun Xbase++ darauf, dass beim Lesen mehrere gleichzeitige Zugriffe dennoch richtige Ergebnisse bringen.

Die hier beschriebenen Fehler bei DBSKIP, CLOSE etc. treten zwar bei diesen Befehlen auf, aber nur weil nun die gepufferten Befehle wie replace etc. durchgeführt werden. Es ist also in gewisser Weise ein Cache Problem.

Bei XbpCRT Anwendungen sind 'bauartbedingt' Konkurenzsituationen im Programm (geradeauc bei der Verwendung von Publics und Privates - ich nehme die höchstens für Programmweite Konstanten !) seltener. Bei GUI weiß man als Programmierer nie was als nächstes kommt !

Wenn aber ein automatischer Thread dauernd im Hintergrund Datenbank operationen startet, eventuell auch Satzsperren nutzt und schreibt, kann man überhaupt nicht mehr wissen was wann passiert.

[Tom]

Hallo, Jimmy.

COMPONENT_DATA ... 1 warum so ein "kleiner" Wert ?

Weil ich ja ohnehin die Antwort von RLock() abwarte und entsprechend reagiere. Tabellen werden bei Schreib- und Suchvorgängen nicht implizit gelockt, im Gegensatz zu Indexen. Deshalb scheint mir der kleine Wert unerheblich, und Alaska hat auf meine Angaben auch nicht kopfschüttelnd geantwortet.

[Tom]

Zur Information:

Andreas Herdt schrieb mir gerade, daß sie intensiv auf der Suche nach der Ursache für die sich wiederholenden Betriebssystemfehler 1 (unzulässige Funktion) sind, die vermutlich im Zusammenhang mit dem LAN Manager des Betriebssystems stehen. Darüberhinaus hat er mir mitgeteilt, daß ich diese Einstellungen:

Code: Alles auswählen

  DbeInfo(COMPONENT_DATA,DBFDBE_LOCKRETRY,1)
  DbeInfo(COMPONENT_DATA,DBFDBE_LOCKDELAY,1)

entfernen soll, da sie obsolet sind und von der 1.9 ohnehin nicht mehr unterstützt werden.

Ich gebe Laut, sobald ich was Neues höre.