AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Programmieren allgemein Delphi Servergeänderte Datensätze
Thema durchsuchen
Ansicht
Themen-Optionen

Servergeänderte Datensätze

Ein Thema von Sugar · begonnen am 3. Nov 2015 · letzter Beitrag vom 5. Nov 2015
Antwort Antwort
Benutzerbild von p80286
p80286

Registriert seit: 28. Apr 2008
Ort: Stolberg (Rhl)
6.659 Beiträge
 
FreePascal / Lazarus
 
#1

AW: Servergeänderte Datensätze

  Alt 3. Nov 2015, 22:01

Ja, ich greife über ADO auf den SQL Server zu.

Zu deinen Tipps:

Ich muss leider - exakt aus Gründen der Performance - mit ein paar Tabellen arbeiten. Alle sinnvollen Daten hole ich mir natürlich mit AdoQueries. Und, man mag es veraltet halten, aber ohne datensensitive Controls stände ich jetzt vor dem gleichen Problem.
Was eine Mehrzahl von Tabellen mit Performance zu tun hat ist mir schleierhaft.

Dein Link, danke dafür, hilft mir nach erster Analyse auch nicht weiter. So wie ich es verstehe, müsste der Client nur woanders nach einer Änderung suchen. Ich "überwache" nur eine andere Tabelle.
Nein, er wird benachrichtigt!

Gruß
K-H
Programme gehorchen nicht Deinen Absichten sondern Deinen Anweisungen
R.E.D retired error detector
  Mit Zitat antworten Zitat
hoika

Registriert seit: 5. Jul 2006
Ort: Magdeburg
8.277 Beiträge
 
Delphi 10.4 Sydney
 
#2

AW: Servergeänderte Datensätze

  Alt 4. Nov 2015, 06:47
Hallo,
er benutzt TAdoTable, weil es sich so besser mit seinen datensensitiven Elementen (TDBEdit usw.) arbeiten läßt.
Kennt TAdoQuery eigentlich auch das RequestLive ?
Damit klappte war ein TQuery doch fast so gut wir ein TTable.
Hatte ich aber nie benutzt.


Heiko
Heiko
  Mit Zitat antworten Zitat
Dejan Vu
(Gast)

n/a Beiträge
 
#3

AW: Servergeänderte Datensätze

  Alt 4. Nov 2015, 07:11
Die Problematik schreit eigentlich nach einem Service (aka Mittelschicht). Zugriff auf die Daten über den Service, der dann ja alle Clients benachrichtigen kann.

ADO unterstützt keine Event notifications. Man müsste also den Provider wechseln (AnyDac) oder sich eben den Service selbst schreiben. Fragt sich, was billiger ist
  Mit Zitat antworten Zitat
Benutzerbild von FBrust
FBrust

Registriert seit: 4. Okt 2002
Ort: Saarbrücken
654 Beiträge
 
Delphi 10.4 Sydney
 
#4

AW: Servergeänderte Datensätze

  Alt 4. Nov 2015, 07:25
Hallo,

als kleinere Zwischenlösung könntest Du auch folgendes machen:

- In jeder Tabelle gibt es ein Feld mit Datum/Zeit der letzten Änderung
- Wenn ein Datensatz bearbeitet wird, wird das Feld im Client zwischengespeichert
- Bevor ein Datensatz dann gespeichert werden soll, wird das Datum der letzten Änderung nochmal
aus der Datenbank gelesen und mit dem zwischengespeicherten verglichen
- Ist das Datum unterschiedlich, wurde der Datensatz in der Zwischenzeit geändert

oder Du setzt beim "Holen" eines Datensatzes ein Feld in der Tabelle, das allen
anderen signalisiert, dass der Datensatz gesperrt ist (dann kannst Du auch hinterlegen, von wem und seit wann)

Aber ein Service ist langfristig natürlich die bessere Wahl.

Gruß
Frank
"Ich habe Dinge gesehen, die ihr Menschen niemals glauben würdet. Gigantische Schiffe, die brannten, draußen vor der Schulter des Orion" - Roy Batty
  Mit Zitat antworten Zitat
Benutzerbild von TheMiller
TheMiller

Registriert seit: 19. Mai 2003
Ort: Gründau
2.480 Beiträge
 
Delphi XE7 Architect
 
#5

AW: Servergeänderte Datensätze

  Alt 4. Nov 2015, 08:40
Du könntest auch sog. MessageQueues benutzen. Die Windows-Server haben die MS-MessageQueue mit an Board, welche man über die Serververwaltung nachinstallieren kann. Jedes Windows-OS ab 7 aufwärts (glaube ich), hat dieses Feature als Server auch integriert (bzw. ist nachinstallierbar).

Ansonsten kannst du auch RabbitMQ / ApacheMQ verwenden, wenn du eine Linux-VM erstellen kannst.

Dann kannst du bei jeder Änderung eine Nachricht an die MessageQueue schicken, welche alle aktiven Clients benachrichtigt.

Alternativ kannst du auch - wenn es nur um die Meldung geänderter Datensätze aus einem Modul geht - einen TCP-Server u Client verwenden und nach dem Ändern eines DS eine Broadcast-Message (oder alle aktiven Clients) via TCP/IP ansprechen und den String "/reload-1234" senden. Beim Empfangen wissen die TCP-Clients, dass die den DS 1234 aktualisieren müssen.
Bisheriger Nutzername "DJ-SPM"
  Mit Zitat antworten Zitat
Sugar

Registriert seit: 23. Jul 2012
83 Beiträge
 
#6

AW: Servergeänderte Datensätze

  Alt 4. Nov 2015, 08:49
Vielen Dank an alle. Also, die Anwendung ist mir für eine Investition in andere Zugriffskomponenten einfach zu minimal.

Ich würde mir aber gerne mal die Lösung mit dem Service, wenigstens in der Theorie, ansehen. Kennt einer hilfreiche Links oder andere Quellen (democode) dazu?
  Mit Zitat antworten Zitat
Benutzerbild von Sir Rufo
Sir Rufo

Registriert seit: 5. Jan 2005
Ort: Stadthagen
9.454 Beiträge
 
Delphi 10 Seattle Enterprise
 
#7

AW: Servergeänderte Datensätze

  Alt 4. Nov 2015, 16:22
Der MS-SQL-Server kennt den Feldtyp RowVersion von daher braucht man sich dort nicht mit einem Timestamp herumärgern.
Kaum macht man's richtig - schon funktioniert's
Zertifikat: Sir Rufo (Fingerprint: ‎ea 0a 4c 14 0d b6 3a a4 c1 c5 b9 dc 90 9d f0 e9 de 13 da 60)
  Mit Zitat antworten Zitat
mm1256

Registriert seit: 10. Feb 2014
Ort: Wackersdorf, Bayern
642 Beiträge
 
Delphi 10.1 Berlin Professional
 
#8

AW: Servergeänderte Datensätze

  Alt 4. Nov 2015, 18:06
Vielen Dank an alle. Also, die Anwendung ist mir für eine Investition in andere Zugriffskomponenten einfach zu minimal.

Ich würde mir aber gerne mal die Lösung mit dem Service, wenigstens in der Theorie, ansehen. Kennt einer hilfreiche Links oder andere Quellen (democode) dazu?
Den Service selber zu programmieren würde ich nicht machen. Der Aufwand ist viel zu hoch. Folglich müsstest du hier auch wieder auf Komponenten von Drittanbietern zurückgreifen, z.B. das Trio Aurelius/Sparkle/XData von TMS.

Auch wenn es aus technischer Sicht nicht vom Feinsten und State of the Art ist, würde ich in diesem speziellen Fall (soweit ich dies anhand der verfügbaren Informationen beurteilen kann) mit einer Variante der bereits vorgeschlagenen Lock-Mechanismen arbeiten. Entweder eine separate Lock-Tabelle, oder entsprechende Lock-Felder bei den Datensätzen. Das einzig knifflige Problem dabei ist, wie man mit Verbindungsabbrüchen umgeht. Ein Client lockt, und verabschiedet sich. Wer hebt den Lockmechanismus dann wieder auf? Ist also auch nicht das gelbe vom Ei.

Wie wäre es denn mit einem Mechanismus, wie ihn die uralte B-Tree-Shell von EDV-Beratung Enz schon zu DOS-Zeiten verwendet hat. Ich verwende ihn teilweise heute noch. Es ist quasi eine "lokal auf dem Client arbeitende Mittelschicht".

Es werden insgesamt 3 Datenpuffer verwendet:

- Bei Beginn des Editiervorganges wird der Inhalt des aktuellen Datensatzes in Puffer 1 gelesen
- Puffer 1 wird in Puffer 2 kopiert, das ist der Editierpuffer mit dem der User arbeitet
- Nach dem Editieren und vor dem Post wird Puffer 2 mit Puffer 1 verglichen. Besteht kein Unterschied (der User hat nichts geändert) muss in der DB nicht gepostet werden. Man spart sich also den Post. Andernfalls wird Puffer 3 vom aktuellen Datensatz aus der DB gelesen und mit Puffer 2 verglichen
- Ist der Vergleich positiv (beide Puffer sind gleich) hat womöglich ein anderer User bereits die selben Änderungen vorgenommen. Man spart sich also wieder den Post. Bei negativem Vergleich kann man dem User dann wahlweise

a) die geänderten Daten aus Puffer 3 nochmals zum Editieren anbieten
b) seine eigenen Änderungen verwerfen
c) beide Varianten anzeigen und einen Mix daraus bilden. Das muss im Einzelfall entschieden werden.

Dieses Prinzip hatte für den Arbeitgeber den Vorteil, dass sich die Mitarbeiter nie lange mit dem Editieren aufgehalten haben. Es könnte ja sein, dass ein Anderer "gewinnt". So nebenbei hat man auch ein UnDo während des Editierens.

Für die Erstellung der Puffer braucht man lediglich eine einzige Funktion, dazu dann noch die Vergleichsfunktion, was den Zeitaufwand sehr in Grenzen hält.
Gruss Otto PS: Sorry wenn ich manchmal banale Fragen stelle. Ich bin Hobby-Programmierer und nicht zu faul die SuFu zu benutzen
  Mit Zitat antworten Zitat
Antwort Antwort


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 00:30 Uhr.
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz