AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Programmieren allgemein Delphi Servergeänderte Datensätze

Servergeänderte Datensätze

Ein Thema von Sugar · begonnen am 3. Nov 2015 · letzter Beitrag vom 5. Nov 2015
Antwort Antwort
Seite 2 von 2     12
Benutzerbild von Sir Rufo
Sir Rufo

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

AW: Servergeänderte Datensätze

  Alt 4. Nov 2015, 17: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
640 Beiträge
 
Delphi 10.1 Berlin Professional
 
#12

AW: Servergeänderte Datensätze

  Alt 4. Nov 2015, 19: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
Wenn du mit Gott reden willst, dann bete.
Wenn du ihn treffen willst, schreib bei Tempo 220 eine SMS
  Mit Zitat antworten Zitat
Perlsau
(Gast)

n/a Beiträge
 
#13

AW: Servergeänderte Datensätze

  Alt 4. Nov 2015, 21:12
Wieso ist der Vorschlag, die entsprechende – kostenlose – Event-Komponente von Zeos zu verwenden, inakzeptabel oder nicht diskussionswürdig?
  Mit Zitat antworten Zitat
Dejan Vu
(Gast)

n/a Beiträge
 
#14

AW: Servergeänderte Datensätze

  Alt 5. Nov 2015, 08:14
Der MS-SQL-Server kennt den Feldtyp RowVersion von daher braucht man sich dort nicht mit einem Timestamp herumärgern.
Ich dachte auch immer, das der T-SQL Datentyp 'TimeStamp' irgendwas mit der Zeit zu tun hat. Aber in Wirklichkeit ist 'TimeStamp' nur die veraltete Version der RowVersion.

@Perlsau: Vermutlich, weil es nichts zu diskutieren gibt. Funzt. Fertig. Noch Fragen?
  Mit Zitat antworten Zitat
Hansa

Registriert seit: 9. Jun 2002
Ort: Saarland
7.554 Beiträge
 
Delphi 8 Professional
 
#15

AW: Servergeänderte Datensätze

  Alt 5. Nov 2015, 11:12
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.
Uff, das kennt hier noch jemand ? Ja, die Basis war die Btree-Isam vom Dipl.-Mathematiker Ralph Nagel. Die angesprochene Zwischenschicht war dann die Btree-Shell. Die kam aber erst dank OOP. War schon cool. Leider ging die Fa. Enz wegen Delphi 1 pleite. Warum ? Wohl weil ein Haupt-Umsatzträger Object Professional (TurboPower) war. Da gab es z.B. brauchbare Editfelder usw. So etwas war dann aber bei Delphi dann auch von Anfang an dabei. Ich kenne Enz und Nagel. Die gingen beide zu KHK (heute Sage). Es gab ja auch deutsche (gedruckte) Handbücher. Übersetzung, Drucken usw. das war wohl auch letztenendes zu teuer. Schade.

Aber zum Thema : Grundlage waren prinzipiell 3 Datensatzversionen. Genannt Savebuffer, Workbuffer und Tempbuffer. Beim Lesen eines Datensatzes werden Savebuffer und Workbuffer mit dem gelesenen Datensatz gefüllt. Savebuffer dient dabei zum späteren Vergleich auf zwischenzeitlich von anderem User durchgeführte Änderungen. Workbuffer ist das, was gerade z.B. editiert wird.

Beim Abspeichern (wäre dann das im Workbuffer) hat die Btree-Shell automatisch den momentanen Datensatz-Inhalt auf der Festplatte in den Tempbuffer eingelesen. Wenn nun Savebuffer (also quasi alter Zustand) und Tempbuffer (Zustand beim Abspeichern, also später) Differenzen aufwiesen, z.B. weil anderer User schneller war, dann wurde die Variable IGAlreadyChanged auf true gesetzt und man konnte reagieren.

Das hiesse dann, man überschreibt die von anderen gemachten Änderungen, oder speichert nicht oder es werden nur einzelne Felder geändert und dann wird gespeichert. Für letzteres u.ä. gab es viele Funktionen. Tja, finde das Prinzip immer noch wasserdicht.
Gruß
Hansa
  Mit Zitat antworten Zitat
mkinzler
(Moderator)

Registriert seit: 9. Dez 2005
Ort: Heilbronn
39.804 Beiträge
 
Delphi 10.4 Sydney
 
#16

AW: Servergeänderte Datensätze

  Alt 5. Nov 2015, 12:52
So funktioniert es grundsätzlich heute auch noch in auf Versionierung basierenden Transaktionssteuerungen.
Markus Kinzler
  Mit Zitat antworten Zitat
Hansa

Registriert seit: 9. Jun 2002
Ort: Saarland
7.554 Beiträge
 
Delphi 8 Professional
 
#17

AW: Servergeänderte Datensätze

  Alt 5. Nov 2015, 13:01
Ja, im Prinzip. Aber erkläre das doch mal, wie man die Transaktionen einstellen muss und was sonst noch zu beachten ist. Die Aussage "funktioniert heute noch so", die nützt dem Fragesteller nämlich nichts.
Gruß
Hansa
  Mit Zitat antworten Zitat
mkinzler
(Moderator)

Registriert seit: 9. Dez 2005
Ort: Heilbronn
39.804 Beiträge
 
Delphi 10.4 Sydney
 
#18

AW: Servergeänderte Datensätze

  Alt 5. Nov 2015, 13:08
Wie es bei dem Produkt vor 30 Jahren war, noch weniger.
Markus Kinzler
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

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:48 Uhr.
Powered by vBulletin® Copyright ©2000 - 2022, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2021 by Daniel R. Wolf