wie abfragen dass Daten in einer DBF geändert wurden?

[RolandG]

Hallo

Wie oder woran kann ich "zeitnah" erkennen dass Daten in einer DBF (im Netzwerk) von irgend einer Stelle geändert wurden?
Der Umfang der Änderung kann minimal sein, z.B. nur ein Buchsstabe in einem Feld.
Im Augenblick muss ich mich mit dem Datum und der Zeit des letzten Schreibvorgangs auf Dateiebene begnügen.
Also Abfrage mit Directory().
Trotz DbCommit() werden die Datei-Infos scheinbar nicht all zu schnell geschrieben, das kann Minuten dauern.

Ich verwende ADS, vielleicht wird damit DbCommit() nur im ADS-Buffer verarbeitet aber noch nicht auf die HDD geschrieben.

Ich brauche die Daten/DBF geändert Info um einen Refresh-Vorgang durchzuführen bzw. dafür das Flag zu setzen.
Habe in der Doku nichts gefunden.
Vielleicht hat von Euch auch schon jemand sowas benötigt und kann mir weiterhelfen...

Gruß
Roland

[brandelh]

Seit den "Optimierungen" von Windows 7 kann man sich auf die Metadaten nicht mehr verlassen.

Wenn es nur wenige Anwender sind, könnte man eine Datei schreiben, die wie ein Flag wirkt, aber bei mehreren ist das sehr unübersichtlich.
Du könntest eine DBF als Protokoll führen die bei jedem Speichern automatisch einen neuen Datensatz mit Uhrzeit und Zeit anlegt.
In allen Clients müsstest du regelmäßig nachsehen ob dort eine Änderung erfolgt ist, aber ob das zeitlich reicht ?

[georg]

Hallo, Roland -


eigentlich im Header der Datei, d.h. mit fOpen() öffnen und auslesen:

https://www.dbase.com/Knowledgebase/INT ... le_fmt.htm

[Manfred]

wenn es machbar ist, ein Zusatzfeld in die Tabelle einfügen in das dann Datum und Uhrzeit geschrieben wird bei jedem Update.

[RolandG]

@Hubert
so eine gemeinsame Protokoll-/Status-DB wäre für die Zukunft vermutlich hilfreich.
Ev. komme ich da auch nicht herum so etwas einzuplanen.

@Georg
In der Beschreibung des Headers lese ich nur was von Datum des letzten Updates?

Unterm Strich wäre so etwas wie eine Art Transaktions-Nr. die permanent hochzählt interessant.
Das System (Xbase++) könnte das machen wenn ein geänderter(?) Buffer rausgeschrieben wird.

[RolandG]

@Manfred

Die Anwendung ist seit langer Zeit gewachsen.
Wo überall Änderungen an Feldern der Workarea stattfinden wird nicht mehr oder nur mit viel Aufwand 100%if erfassbar bzw. umprogrammierbar sein.

[georg]

Hallo, Roland -


Deine Frage lautet doch, wie oder woran Du erkennen kannst, dass Daten in einer DBF verändert wurden. Eine Veränderung der Daten ist ein Update, und der Header dokumentiert, wann das zum letzten Mal passiert ist.

Oder suchst Du nach etwas anderem?

[RolandG]

Hallo Georg,

habe das zu ungenau beschrieben.
Ich meinte mit zeitnah max. 1 Minute - oder je schneller desto besser.
Ohne das von vorne herein genau zu einzubauen wie z.B. Herbert beschreibt wird eine schnelle/schnellere Erkennung vermutlich ein Wunsch bleiben.

Selbst in der eigenen laufenden EXE ist eine Wert-Änderung in einer Workarea nicht pauschal erkennbar - oder?
Wenn ich ein Feld ändere und DbCommit() verwende wird scheinbar die DBF im Netz erst beim Schließen der Workarea oder beenden der EXE das Datum und die Zeit geändert, sonst dauert das.

Ich muss das mal ohne den ADS testen wie es sich dann verhält.

[brandelh]

zum Einlesen von Änderungen, kann SKIP(0) helfen.

[RolandG]

Die Erkennung von "vermeintlichen" Datenänderungen in einer DBF über die Betriebssystem-Abfrage des letzten Schreibvorgangs Datum + Zeit ist für meine Zwecke doch unbrauchbar. Das musste ich inzwischen leider feststellen.
Es werden scheinbar auch Schreibvorgänge auf die DBF ausgelöst obwohl sich keine Daten geändert haben. Ohne ADS passiert das noch häufiger.
An dieser Datum- + Zeit-Angabe ist also nur erkennbar, dass die DBF verwendet wurde, aber nicht ob sich Daten geändert haben.

(Man könnte daraus folgern, dass mit DbCommit(), DbGoTo(0), DbCloseArea() usw. auch unnötige Schreibvorgänge ausgelöst werden. Wäre ja auch verständlich...)

Also doch den Aufwand betreiben ein Änderungs-Flag in Form einer Art lfd. Transaktions-Nr. einbauen. Je DBF. Uff...

[brandelh]

eine DBF ist ja kein Datenbank System sondern eine Flat File, was genau das Feld in der alten Definition bedeuten sollte und was Clipper / Xbase++ draus macht, ohne debugger im Treibercode kaum zu beantworten.
Keinesfalls ist da ein Trigger der bei jeder Änderung was da rein schreibt, ich meine es wäre auch noch ein Jahr 2000 Problem bei genau diesem Eintrag, aber das ist lange her.

Unter docs.fileformat.com steht zum Datumsfeld:

Byte (start mit 0)

1–3 3 Bytes Datum der letzten Aktualisierung; formatiert als JJMMTT

Was ist schon eine Aktualisierung ?

Das Schreiben des gleichen Inhalts in ein Feld, sicher ja - sollte also passen zu deinem Zweck, aber ob es sicher ist ?

[Tom]

Jeder Datensatz in jeder wirklich wichtigen Tabelle hat bei uns zusätzlich eine ID (UID), und jedes Unlock auf einem Datensatz, der dieses ID-Feld besitzt, führt automatisch dazu, dass in einer Transaktionstabelle protokolliert wird, von welcher Tabelle (DbInfo()) welcher Datensatz um welche Uhrzeit von wem geändert worden ist. Bei einigen Tabellen gibt es zusätzlich noch ein Feld, das einen Hashwert über alle Feldinhalte außer der UID und dem Hashwert selbst (Var2Char) enthält, und nur wenn sich der geändert hat, geht was in die Transaktionstabelle. Auf die der Index so gestaltet ist, dass die letzte Info zu jeder Tabelle schnell gefunden werden kann. Das ist insgesamt sehr wenig Code; UNLOCK ist per PP abgefangen, und da es nach jeder Neuerfassung oder Aktualisierung erfolgen muss, ist der Prozess dadurch sicher. Das UID-Feld wird befüllt, wenn es zu diesem Zeitpunkt noch leer ist.
Alle anderen Mechanismen taugen nichts. Erst mit einem SQL-Server lässt sich das richtig überwachen.

[RolandG]

Das mit dem angepassten DbRUnlock() habe ich heute auch bei der betreffenden DBF gemacht.
Da werden jetzt zusätzliche Daten geschrieben.
Bei den Tests scheint es bisher auf jeden Fall gut zu funktionieren.
Eine Kontrollfunktion wird mir im Laufe der Zeit zeigen ob ich unlocks übersehen habe.

Andere funktionierende Möglichkeiten scheint es wirklich nicht zu geben.

[nightcrawler]

Da der ADS im Einsatz ist: umstellen auf Data Dictionaries, auf alle Tabellen Trigger drauf und darin eine Notification versenden (bzw wie von Tom vorgeschlagen, Änderungen in eine Tabelle zusammenfassen - über Trigger - und auf dieser Tabelle eine Notification einrichten).
Im Programm musst Du nur eine zusätzliche Verbindung aufmachen und auf die Benachrichtigung warten (Multi-Threading!).

[Tom]

Eine Kontrollfunktion wird mir im Laufe der Zeit zeigen ob ich unlocks übersehen habe.

Da ist der Präprozessor Dein Freund.

[RolandG]

@Joachim

Dass der ADS in dieser Richtung Zusatzmöglichkeiten bietet habe ich mir schon gedacht. Aber dann bin ich nicht mehr unabhängig vom ADS.
Wenn der noch normal weiterentwickelt und gepflegt würde wäre diese Richtung überlegenswert.
In letzter Zeit muss ich mich sowieso mehr dran gewöhnen, manch meiner Funktionen mit und ohne ADS zu testen.

Gruß
Roland

[Werner_Bayern]

Servus,

da LUpdate() nur ein Datum zurückgibt, ist es hierfür nicht geeignet. Unter PostgreSQL geht das so: https://www.xbaseforum.de/viewtopic.php ... 54#p133654

Da wird es beim ADS ähnliches geben?

[Manfred]

Da der ADS im Einsatz ist: umstellen auf Data Dictionaries, auf alle Tabellen Trigger drauf und darin eine Notification versenden (bzw wie von Tom vorgeschlagen, Änderungen in eine Tabelle zusammenfassen - über Trigger - und auf dieser Tabelle eine Notification einrichten).
Im Programm musst Du nur eine zusätzliche Verbindung aufmachen und auf die Benachrichtigung warten (Multi-Threading!).

Hi Joachim,
könntest Du an anderer Stelle hier im Forum dazu nochmal etwas genaueres sagen, wie man sowas machen könnte/müßte?

[nightcrawler]

In der Datenbank, zB auf die Tabelle 'kunden'. Statt TrigRowID kann auch eine eigene ID verwendet werden.

Code: Alles auswählen

create trigger trig_ins on kunden after insert
begin
  execute procedure sp_SignalEvent( 'kunden', true, 0, 'INSERT '+::stmt.TrigRowID);
end;

create trigger trig_upd on kunden after update
begin
  execute procedure sp_SignalEvent( 'kunden', true, 0, 'UPDATE '+::stmt.TrigRowID);
end;

create trigger trig_del on kunden BEFORE delete
begin
  execute procedure sp_SignalEvent( 'kunden', true, 0, 'DELETE '+::stmt.TrigRowID);
end;

Dann in der Anwendung einen zusätzlichen Thread mit einer eigenen Connection aufmachen und folgendes Statement ausführen.

Code: Alles auswählen

execute procedure sp_CreateEvent( 'kunden', 2);

Auf das Event wartet man dann mit

Code: Alles auswählen

execute procedure sp_WaitForEvent( 'kunden', 10000, 0, 0); //10 Sekunden Timeout, evtl auf 1000, also 1 sek kürzen!

Achtung....bei Timeout und nach Eintreffen das Statement einfach wieder erneut ausführen.

[Marcus Herz]

@Manfred: Notification ist in AdsClass++ enthalten: AdsListening()