DB Abgleich

[Tim Henford]

Hallo,

gibt es eine einfach Lösung eine lokale MSSQL 2000 DB mit einer im Netzwerk abzugleichen und wie kann man Übeschneidungen behandeln oder muss man sich ein eigens Konzept basteln?

Danke Tim

[mkinzler]

Am Besten indem man verschiedenen Wertebereiche für die IDs und GUIDS für diese verwendet.

[Tim Henford]

Was passiert eigentlich, wenn ich gerade mehrere Datensätze schreiben bzw. posten will und das Netzwerk zusammenbricht oder ein Stromausfall kommt - ist die DB dann "zerstört"?

[mkinzler]

Nein, dank Transaktionssteuerung wird die Transaktion zurückgefahren (rollback).

[Phoenix]

Vorausgesetzt, man verwendet Transaktionen. Tut man das nicht, sind halt alle Änderungen die bis zum Verbindungsabbruch vollständig abgesetzt wurden auch wirklich in der Datenbank.

[Tim Henford]

wie läuft das mit der Transaktionssteuerung, muss man da was einstellen oder geht das automatisch?
Wie verifiziert dann die DB, ob der Eintrag nun halb oder schon komplett war?

Gilt das auch für den Fall, dass der Server abstürzt?
Kann man darüber irgendwo was lesen?

Ich lasse von meinen Programm eine Sperrliste anlegen, damit kein anderer User im gleichen Moment auf die DB zugreifen kann, kann es passieren, dass ein anderer User im gleichen Moment auch eine Sperrlist erzeugt?

[Phoenix]

Hrm? Beim SQL Server kann man Tabellen explizit sperren. Wobei es unsinnig ist, einen Table lock zu setzen wenn man nur eine Handvoll Datensätze anpacken will...

Ein Datenbankserver stürzt im übrigen nicht einfach so ab. Und für den Fall eines Stromausfalls hängt man halt eine USV dran.

Die Datenbank erkennt ein komplettes Statement in der Regel an einem abschliessenden Semikolon, und führt das Ding dann aus. Danach kommt die nächste Anforderung dran die empfangen wird. Solange ein Statement nur halb da ist wird auch nix ausgeführt.

Transaktionen:
BEGIN TRANSACTION
update, insert, delete, wasauchimmer...
... und wieviel man mag.

Wenn alles okay:
COMMIT TRANSACTION

Wenn nicht okay:
ROLLBACK TRANSACTION

Geht die Verbindung zwischendrin flöten wird automatisch ein rollback durchgeführt.

[Tim Henford]

Danke für die Hilfe.

Ja Frage ist nur, was passiert, wenn plötzlich doch irgendwas abstürzt beispielsweise auf dem Server selbst.

Wie funktioniert das mit dem Table lock? Geht das beim MSSQL2000 und den normalen Ado-Komponenten unter Delphi 7 auch bereits?

[Phoenix]

Was soll denn da Abstürzen? :gruebel:
Wenn der Server einfach mal so abkachelt, dann hat wer auch immer ein größeres Problem, als eine nicht abgeschlossene Transaktion.

Nochmal: Du kannst zwar eine Tabelle locken, aber es macht nicht viel Sinn.
Arbeitest Du mit einer Transaktion, dann werden die Daten erst nach Abschluss der Transaktion geschrieben und auch erst dann für andere User sichtbar. Ein Write-Lock wird inenrhalb der Transaktion automatisch gesetzt, das heisst solange die Transaktion läuft kann kein anderer User einen engepackten Datensatz schreibend locken.

Ein kompletter Read-Lock auf der Tabelle würde a) andere Sessions komplett blockieren und b) ist er wie gesagt unsinning wenn nur ein paar Datensätze angepackt werden.

[Tim Henford]

ok, danke dir.
Ein write Lock reicht ja schon, wenn die Sperrlistentabelle erstellt wird, nur darf der nicht gleichzeitig von 2 Usern kommen...das war mein Bedenken

[Phoenix]

Wieso überhaupt irgendwelche Sperrlisten?

Das klingt mir danach, als würdest Du eine Logik nachprogrammieren, die die Datenbanken von sich aus schon zur Verfügung stellen. Wieso willst Du das Rad neu erfinden? Zumal Dein Rad wahrscheinlich noch nichtmal rund sein wird sondern - sorry, no offense - aufgrund Deiner offensichtlichen Wissenlücken über Datenbanksysteme, mit an Sicherheit grenzender Wahrscheinlichkeit ziemlich viereckig sein dürfte.

[Tim Henford]

ja das stimmt natürlich, aber es sieht so aus, dass ich für den Fall hier mir selbst ein Synchronisationskonzept überlegen muss, denn ich weiß nicht, ob die DB entscheiden kann, welcher Messwert von welchem Platz nun der richtige ist.
Bei Überschneidungen soll der User gefragt entscheiden, welche Werte nun die besseren sind...

Über eine schnellere einfachere Lösung wäre ich auch froh

[Phoenix]

Was hat das eine (Entscheidung welche Werte) mit dem anderen (Sperren der DB) zu tun?

[Tim Henford]

Das Sperren ist Voraussetzung für die strikt sequentielle Ordnung der Updates und Änderungen.
Sonst wurschtelt ja irgendwer irgendwann mal irgendwas dazwischen, wo keiner weiß wo es herkommt...

[mkinzler]

Zudem gibt es auch fertige Replikationssysteme für verschiedene Datenbanken.

Zitat:

Sonst wurschtelt ja irgendwer irgendwann mal irgendwas dazwischen, wo keiner weiß wo es herkommt...

Du solltest dich wirklich mal mit den Grundlagen von Datenbanken einarbeiten.

[Tim Henford]

Diese Replikationssysteme fragen meines Wissens aber nicht nach, welcher Eintrag der richtige ist und somit wird das mit der automatischen Synchronisation auch nix wirklich

[Phoenix]

Zitat:

Zitat von Tim Henford

Sonst wurschtelt ja irgendwer irgendwann mal irgendwas dazwischen, wo keiner weiß wo es herkommt...

:wall:

Fall zu Deinem Konzept:
1.) User A schaut in Deine Sperrliste. Findet nix.
2.) User B schaut gleichzeitig in Deine Sperrliste. Findet auch nix.
3.) User A und B fangen gleichzeitig an, die Daten zu synchronisieren.

Und jetzt schnapp Dir ein gutes Buch über Datenbanksysteme, nimm Dir zwei, drei Wochen Zeit, und frage dich dann nochmal, ob Du ein Synchronisierungskonzept selber entwickeln willst. Ich gehe jede Wette ein, dass ein selber implementiertes System eher früher als später a) in eine Deadlock-Situation rennt oder b) trotz bestmöglicher Absicherung eine Kollision zulässt.

Oder um es ganz deutlich zu sagen: Finger weg von eigenen Sperrmechanismen, sobald Du ein System benutzt dass es zum einen schon selber kann und das zum anderen auch noch besser, als Du es jemals selber implementieren könntest.

[Phoenix]

Zitat:

Zitat von Tim Henford

Diese Replikationssysteme fragen meines Wissens aber nicht nach, welcher Eintrag der richtige ist und somit wird das mit der automatischen Synchronisation auch nix wirklich

Nochmal ganz deutlich: Eine logische Entscheidung über die Quelle eines Datensatz hat nichts, aber auch absolut gar nichts, mit der Entscheidung zu tun, welche Datensätze von welcher Session wann und wie lange und wieso und wo überhaupt gesperrt werden.

[mkinzler]

Kommt darauf an, wie deine Datenbankschema aussieht. haben die verschiedenen Bestände verschiedenen ID-Bereiche kann man schnell erkennne, welche Datensätze neu sind. Wird ein Änderungs-Timestamp geschrieben, kann man auch Änderungen an vorhandenen DS erkennen.

[Tim Henford]

Na schön, kein Grund gleich in die Luft zu gehen :firejump:
Ich bin über jede Vereinfachung dankbar, nur wie soll ich sicherstellen, dass 2 User nicht kurz hintereinander unerwünschte Einträge machen.
Wie wird das dann im Netz verteilt und wie können diesen dann noch ausgewertet werden, sodass nicht plötzlich Einträge von einem anderen User gelöscht wurden, die ich aber nur änderen wollte?

[Phoenix]

Du suchst Dir die Datensätze im voraus aus, die Du ändern musst - und bei denen Du den User um angaben bitten musst.
Auf genau diese setzt Du einen rowlock. Damit können diese Datensätze (und auch nur diese) nicht mehr geändert (oder gelöscht) werden. Und dann änderst Du die in einer Transaktion.

[Tim Henford]

Vielleicht wären noch ein paar Hinweise hilfreich, wie man mein Problem am besten löst:

Es sind im Moment 4 PCs die verschiedene Sachen messen und in unterschiedlichen Tabellen auf einer DB speichern sollen. Dabei kann es aber sein, dass diese ab und zu nicht am Netz hängen oder aus einem dummen Zufall mal abstürtzen können.
Mehr nicht, die sammeln eigentlich nur Daten.
Allerdings kommen im Laufe der Zeit immer mal andere Parameter/Spalten hinzu und evtl. wieder weg.

Dann soll es noch möglich sein, diese gesammelten Daten zu vergleichen, bearbeiten und eventuell zu löschen von 3 anderen Leuten, jeder an einem anderen PC, die aber auch nicht immer mit dem DBServer verbunden sein können und ihre Daten "offline" ändern müssen.
Wäre es da sinnvoll lokal auch einen MSSQL Server laufen zu haben?

Danke Tim

[mkinzler]

Ja ich würde überall die MSDE/SQL Express Laufen lassen, und jedem PC einen anderen ID-Bereich geben, so ist es relativ einfach die daten auf Serverseite zusammenzuführen; auch automatisch.

[Tim Henford]

Wie genau funktioniert dann das "serverseitige Zusammenzuführen"?
An dieser Stelle komm ich irgendwie nicht weiter. Ich dachte mir, dass ich mittels Programm sage, jetzt soll ein Abgleich erfolgen und wenn es nicht klappt, soll es eben nur wieder lokal gespeichert werden.

Wie merke mein Programm, ob der Eintrag schon von jemand anders verändert wurde und kann den Nutzer entscheiden lassen, ob seiner richtig ist oder der auf der ServerDB?
:gruebel:

[mkinzler]

Durch eine Replikationslösung

[Tim Henford]

ja davor saß ich ja, aber wie kommuniziert die DB dann mit meinem Programm, also sagt: den Eintrag gibt es schon oder sowas?

[mkinzler]

Nochmal zum Mitschreiben:
-Jeder Client hat einen eigene Id-Bereich, so kann jeder Eintrag dem Rechner zugeordnet werden, welcher ihn erzeugt hat. Deshalb kann es nicht passieren, daß ein Eintrag schon vorhanden ist! der Replikationsmechanismus sorgt je nach Wunsch nur eine Mischung auf dem Server oder verteilt die Änderungen/Neuerungen der Client auf die anderen Clients.

[alzaimar]

Client #1: Vergibt in seinen Tabellen nur ID's 0...10000
Client #2: Vergibt in seinen Tabellen nur ID's 10001...20000
etc.

Dann kannst Du später einfach die Daten zusammenführen (lassen). Das macht der SQL-Server automatisch, man muss ihm das nur sagen (Stichwort: Replikation). Natürlich geht das auch per Hand, indem Du einfach z.B. auf dem Ziel-Server (der im Netz) ab und an die Daten von den Clients saugst und die Client-Daten dann löschst.

Du sprichst außerdem von irgendwelchen Änderungen in der Struktur. Das ist -soweit ich weiss- nicht die Aufgabe einer Replikation, sondern vom Administrator, der dafür Sorge tragen muss, das die einzelnen DB immer die gleiche Struktur aufweisen. Ich verwende dafür ein Tool von 'Red Gate', 'SQL-Compare' heißt das Teil. Das macht genau, was ich will: Es synchronisiert die Struktur, also Tabellenaufbau, Views, Stored Procedures etc. von zwei MS-SQL Datenbanken.

Weiterhin merkt man, das Du hinsichtlich der Ausfallsicherheit etc. von Datenbanken verunsichert bist. Vermutlich hast Du vorher mit einer Desktop 'Datenbank' gearbeitet, z.B. Access, Paradox oder DBase. Da passiert sowas nämlich, das die DB zerschossen ist, wenn beim Speichern der Strom ausfällt. Gegen ein richtiges DBMS kannst Du während des speicherns treten (ok, nicht bei MySQL), da passiert *gar nichts*. So eine richtige DB sorgt auch dafür, das zwei Leute nicht gleichzeitig an Daten rumwuseln können, wenn Du ihr das sagst.

Allerdings benötigt man dafür ein wenig Grundwissen über DB-Konzepte.

[Tim Henford]

ja danke für die Tipps

was passiert denn z.Bsp, wenn 2 Leute die gleichen Werte offline ändern und dann online ihren Kram hinschicken? Kommt dann erst ein Update sobald man online ist und dann sind die eigenen Änderung überschrieben?

Ich hab das Buch vom Herrn Kosch Ado und Delphi und Datenbanken mit Delphi aber sehr weit bringen die mich dahingehend leider net.

[mkinzler]

In diesem Fall sollte man festlegen, welcher Benutzer/Client Vorrang hat.

[Tim Henford]

Also ich hab mir nun mal das SQL Server Handbuch ausgeliehen und hab mir die Geschichte mit der Merge-Replikation angeschaut, die ich auch sehr gut finden, nur 2 Sachen, die mich da stören:
- kann man irgendwie programmgesteurt (per Knopfdruck) den Replikationsvorgang auslösen
- kann man eine systemmeldung von der Datenbank bei Konflikten bekommen, um den User aktiv über sichüberschneidende Veränderungen zu informieren?
- was passiert, wenn ich merke, dass ich noch mehr/weniger Spalten brauche oder diese umbennen will, kommt die DB dann durcheinander

Ansonsten nutzt es mir ja nichts, wenn einfach Einträge nach dem Prinzip: "wer zuerst kommt, mahlt zuerst" überschrieben werden.

Danke Tim