Hallo, Peter!
ich erhalte von unserer Organisation immer wieder Kundendaten,
die sich dann im Zuge des Kundenkontakts als
unrichtig/unvollständig etc herausstellen.
Normal…
Ich stelle mir vor:
- wenn ich einen Datensatz aufrufe, dann enthält der die
Informationen, wie sie lt. Organisation AKTUELL sind.
- wenn sich im Zuge des Kundenkontaktes Änderungen ergeben,
so gebe ich diese in meine Datenbank ein.
Hat die Organisation ebenfalls diese Datenbank? Reden wir von der gleichen Datenbank? Wie erfolgt das Verschicken bzw. der Austausch der Datensätze?
- NEU sollte sein:
Nach Verlassen des Datensatzes sollte ein Vergleich:
Feldinhalte des Datensatzes VOR und NACH Aufruf erfolgen. Nur
wenn mindestens EIN Feld verändert wurde, sollte in einer
Protokolltabelle der wesentliche Schlüssel für diese Tabelle
und nur jene FEldinhalte, die sich auch verändert haben,
protokolliert werden.
Das wäre nicht das Problem. Grundsätzlich sollte man nur wissen, ob die Daten denn wirklich identisch sind, d. h. wie die Datenbankstruktur(en) der beteiligten Datenbanken aussehen.
Grundsätzlich sollte folgendes gelten: Programm und Daten sind in Organisation und bei Dir zumindest strukturell identisch. Ohne das wird’s richtig komisch. Ich vermute aber mal, dass dem so ist.
Ich würde folgenden Ansatz versuchen, der aber abhängig von den ändernden Zugriffen (prozessbedingt) nicht unbedingt funktionieren mag. Man nehme eine zentrale Datenbank auf dem Netz, zu dem Du möglicherweise zum Datensätze abgleichen Kontakt hast, und repliziere die Datenbank zu Dir nach lokal. Bei jedem Starten wird die vorhandene Netzwerkverbindung überprüft; falls existent, werden die Daten repliziert. Dann kann man noch eine Schaltfläche fürs explizite Replizieren anbieten. Hat den Vorteil, dass Access sich um den Abgleich kümmert. Man muss selbst gar nichts machen.
Wenn das nicht geht, z. B. weil Du keinen Abgleich mit dem Netzlaufwerk durchführen kannst, muss diese „Replikation“ manuell nachprogrammiert werden, und zwar in der DB der Organisation und bei Dir. Das heißt u. U. aber auch, dass ein Konfliktmanagement eingebaut werden muss.
Zum Vergleich brauchst Du eine Tabelle zum Merken der Änderungen, die folgende Felder enthalten sollte: Tabellenname (falls mehrere Tabellen geändert werden), Schlüsselwert (zum Referenzieren des Datensatzes; ggf. sind mehrere Felder nötig, wenn Du Mehrschlüsselfelder hast), Feldname (welches Feld wurde geändert) und NeuerWert (ggf. in mehreren Typen in Feldern NeuerWertText, NeuerWertDatum, … vorsehen; der Typ kann auch als eigene Spalte mitgeliefert werden, falls nicht, muss er in der Tabellendefinition nachgeschlagen werden). Ich würde dann noch das Änderungsdatum und den Namen/Login/sonstwas desjenigen, der die Änderung durchführt, mitnehmen. Irgendwie müssen die Einträge dieser Tabelle gelöscht werden können, um die auszutauschende DB nicht immer weiter aufzublähen und die Abgleichzeiten zu verlängern. Mit diesem Ansatz kannst Du wirklich die betreffenden Felder isolieren.
Alternativ kannst Du auch nach dem Speichern und der Feststellung, dass sich Daten geändert haben, einfach einen SQL-String vom Zuschnitt „UPDATE tblKunden SET Feld1=‚neu‘, … WHERE KundeKey=4711“ in eine Tabelle hauen, ergänzt mit Datum und Name/Login wie oben. Dabei alle Feldwerte übergeben (oder ggf. auch nur die, die sich geändert haben). Hat im einfachen Fall (alle Felder) den Nachteil, dass Du nicht (einfach) auf Feldebene die Änderung siehst, wird aber möglicherweise Laufzeitvorteile haben, da nur SQL-Statements abgearbeitet werden müssen.
Ersuche um Lösungsvorschläge!
Würde, wenn’s irgend geht, die replizierte Datenbank nehmen. Denn wenn Du auch noch neue Datensätze erfassen willst (z. B. neue Dokumente/Vorgänge/sonstwas zu den Geschäftspartnern) wird’s mit der Wahl geeigneter IDs und dem Abgleichen schwierig. Und warum das Rad zwei Mal erfinden?
Gruß, Manfred
