ADS im Netzwerk - Zugriffskonflikte vermeiden

[eddy]

Hallo Leute,

nachdem ich nun meine Auftragsbearbeitung auf ADS (AdsServerTypes := [stADS_LOCAL]) umgestellt habe, kämpfe ich nun mit den Tücken im Netzwerk.

Problem 1:
Auf (ArbeitsPlatz) AP1 lege ich einen Kunden an, auf AP2 wird die Liste aber nicht automatisch aktualisiert. Ein Refresh löst das Problem zwar, aber eben nicht automatisch.

Problem 2:
Wenn ich auf einem AP einen Datensatz lösche (beispielsweise eine Adresse) und dieser war gerade auf einem anderen AP geöffnet, gibt es einen ADS-Fehler (5035).

Bevor ich nun wie zu BDE-Zeiten anfange, diese Fehler selbst programmtechnisch zu vermeiden, möchte ich klären, ob nicht ADS schon entsprechende Mechanismen enthält, diese Fehler zu vermeiden, ich diese wegen fehlendem Wissen nur noch nicht zu nutzen verstehe.

mfg
eddy

[Union]

Hallo eddy,

Problem 1:

Das hat nichts mit ADS zu tun, sondern damit, wie Delphi Datenmengen handlet. Du bist selber für einen Refresh verantwortlich. Soll das automatisch passieren, kannst Du dafür einen Thread oder einen Timer verwenden.

Problem 2:
Fehler 5035 heisst, dass der Satz nicht gesperrt werden konnte. Diese Exception wird natürlich immer geworfen, wenn zwei User denselben Satz bearbeiten wollen. Du solltest diese auch IMMER abfangen.

Delphi-Quellcode:

try
  edit;
except
  ShowMessage('Kunde konnte nicht berbeitet werden');
end;

Wie sollte denn ein DBMS das automatisch machen ?

[mschaefer]

Also ich kenne mich mit ADS nicht aus,
aber es wäre sicherlich hilfreich eine Liste abfragen zu können, die alle akutell gesperrten Sätze einer Tabelle hat.

Grüße // Martin

[Union]

Diese Funktion gibt es: TAdsTable.GetAllLocks

[eddy]

Hallo Leute,

zum Refresh:
So etwas hatte ich bereits zu BDE-Zeiten realisiert, eine Tabelle, in der stand: AP Nr, Datenbank-Name und Record-ID. Bevor ein Zugriff erfolgte, wurde dann die jeweilige Datenbank aktuallisiert. Ging zwar, war aber eigentlich einer der Gründe, warum ich das Datenbanksystem gewechselt habe. Solche Dinge stellen sich aber für gewöhnlich immer erst konkret heraus, wenn man mit einem System arbeitet.

zum Sperren von Sätzen:
Dem Hinweis von Union folgend bin ich auf:

 AdsTable.AdsGetAllLocks(LockArray); gestoßen, aber da erhalte ich nur die Informationen über die Sätze, die ich auf dem aktuellen AP mit AdsTable.AdsLockRecord(AdsTable.RecNo); gesperrt habe.

Sinnvoll wäre doch hier eine vom Datenbanksystem komplett verwaltete Tabelle, die Auskunft darüber gibt, welcher Satz von welchem Arbeitsplatz gesperrt wurde.

Nebeneffekt von AdsLockRecord: ich kann zwar immer noch von einem anderen AP aus den Datensatz löschen, aber nicht mehr vom eigenen.

Vielen Dank für die bisherige Unterstützung.
Sollte sich eine effiziente Lösung finden, hinterlege ich diese hier im Forum.

mfg
eddy

[joachimd]

Zitat von eddy:

zum Refresh:
So etwas hatte ich bereits zu BDE-Zeiten realisiert, eine Tabelle, in der stand: AP Nr, Datenbank-Name und Record-ID. Bevor ein Zugriff erfolgte, wurde dann die jeweilige Datenbank aktuallisiert. Ging zwar, war aber eigentlich einer der Gründe, warum ich das Datenbanksystem gewechselt habe. Solche Dinge stellen sich aber für gewöhnlich immer erst konkret heraus, wenn man mit einem System arbeitet.

Checke mal Notification beim ADS

Zitat:

zum Sperren von Sätzen:
Dem Hinweis von Union folgend bin ich auf:

 AdsTable.AdsGetAllLocks(LockArray); gestoßen, aber da erhalte ich nur die Informationen über die Sätze, die ich auf dem aktuellen AP mit AdsTable.AdsLockRecord(AdsTable.RecNo); gesperrt habe.

Du bekommst darüber nur Deine eigenen Sperren.

Zitat:

Sinnvoll wäre doch hier eine vom Datenbanksystem komplett verwaltete Tabelle, die Auskunft darüber gibt, welcher Satz von welchem Arbeitsplatz gesperrt wurde.

und das gibt es auch, wenn eine zentrale Kontrollinstanz vorhanden ist. AdsMgGetLocks funktioniert aber nur bei Client/Server, nicht dem Local Server.