Exklusiver DB-Zugriff bei gleichzeitig DB-Komponenten

[Der schöne Günther]

Datenbanken unter Delphi sind für mich immer noch Neuland. Die "Data Aware Components" sind ein Riesenspaß. Ohne großen Aufwand kann man den Benutzer gleich toll Daten anzeigen und eventuell sogar direkt bearbeiten lassen.

Ich möchte allerdings auch ein paar Dinge mit der Datenbank anstellen, die exklusiven Zugriff brauchen: Zu dieser Zeit darf keiner lesen oder schreiben. Klassisches Beispiel: Backup machen oder wiederherstellen.


Mein Problem: Wie kann ich herausfinden, wer eigentlich gerade alles auf mein TDataSet zugreift? Ein TDBGrid hängt an einem TDataSource welches irgendein TDataSet belauscht. Die sind mir im Weg, die muss ich vorübergehend abklemmen für meinen exklusiven Zugriff. Nur wie?

[Bernhard Geyer]

Zitat von Der schöne Günther:

Zu dieser Zeit darf keiner lesen oder schreiben. Klassisches Beispiel: Backup machen oder wiederherstellen.

Schlechtes Beispiel. Alle DBMS-Systeme können Backups erstellen ohne das exklusiver Zugriff besteht. Wenn Sie das nicht können sind sie kein DBMS.

Zitat von Der schöne Günther:

Mein Problem: Wie kann ich herausfinden, wer eigentlich gerade alles auf mein TDataSet zugreift? Ein TDBGrid hängt an einem TDataSource welches irgendein TDataSet belauscht. Die sind mir im Weg, die muss ich vorübergehend abklemmen für meinen exklusiven Zugriff. Nur wie?

Gar nicht. Das können die DB-Zugriffskomponenten von Delphi (und auch von anderen Frameworks) nicht. Dieser exklusiver Zugriff würde auch den eigentlichen Prinzipien von DBMS widersprechen. Was du machen kannst ist eine sogenannte Transaktion starten. Damit kannst du erreichen das mehrerer Aktion die zusammengehören entweder vollständig erfolgreich sind oder vollständig wieder zurück genommen werden.

Was willst du eigentlich genau machen?

[Der schöne Günther]

Ich habe ein lokales Datengrab. Bei laufendem und ordnungsgemäß arbeitendem Programm werden immer mehr Daten (Messungen, Logs, ...) "hinten" angehangen. *
Ich verwende die Sybase Advantage Local DB direkt mit ihren funky Delphi-Komponenten.

Ich möchte beispielsweise verhindern, dass die lokale DB über eine bestimmte Größe wächst und die "ältesten" Datensätze löschen. Für diesen "Pack"-Vorgang brauche ich exklusiven Zugriff. Genauso wenn ich den Datenbank-Inhalt gegen einen anderen austauschen will. Kein alltäglicher Betrieb, nur für "Wartungsarbeiten". Geht nunmal nicht anders.

Es funktioniert auch alles bestens. Wenn nun irgendein blöder TDBGrid die ganze Zeit auf meine DB starrt kriege ich die ja allerdings nie kurz exklusiv geöffnet. Nun

1. Mache ich die ganzen Wartungsarbeiten (die exklusiven Zugriff benötigen) nur zu Programmstart und -ende.
2. Merke ich mir alle DB-"Observer" um sie nach Belieben aus- und danach wieder einklinken zu können
3. Es gibt noch etwas besseres

* Es ist eine Sybase Advantage Local DB. Neue Datensätze werden immer hinten angehangen, Datensätze nur zum Löschen markiert und erst beim "Packen" entfernt. Meine fünfseitige Selbstfindung zu dieser DB findet sich auch hier.


PS: Stimmt, Backup geht auch ohne Gefummel. Wiederherstellen aber sicher nicht :-p

[Uwe Raabe]

Ich kann jetzt nicht direkt zu dem Advantage-Server etwas sagen, aber in den meisten Fällen gibt es eine zentrale Stelle, bei der die aktiven DataSets gesammelt werden. Bei der BDE ist es die TDatabase-Instanz, bei DbExpress die TSQLConnection-Instanz und bei FireDac die TADConnection-Instanz - jeweils mit den Properties DataSetCount und DataSets.

Wenn man diese DataSet-Liste temporär kopiert, deaktiviert und nachher wieder aktiviert, müsste man sowas eigentlich implementieren können. Vorausgesetzt, alles läuft im HauptThread ab.

[jobo]

Ist das eine Multiuserumgebung? Eher nicht..?
Wenn es alles lokal ist und Du selbst (der Anwender) ein Restore veranlasst, ist es nicht total ok, wenn man die DBGrids (deren Connection) ausknipst?
Was würdest Du als Anwender erwarten? Das man ein Restore aufruft und das DBgrid kurz unscharf wird und dann zur Darstellung der aktuellen Daten morphed?

Ein anderes Problem wäre, ein Restore zu fahren und dabei weiterhin (wenigstens) Daten zu sammeln.

Kein RDBMS ist im "Moment" des Restore verfügbar! Das ist auch etwas, was man idR nie haben will. Das Restore betrifft die gesamte DB. Die will ich nur aus einem Backup wiederherstellen, wenn sie sich oder jemand anders sie zerstört, korrumpiert, was weiß ich, hat.

Es gibt eine Technik, die man Partitionierung nennt. Damit werden Daten z.B. nach Timestamp (Jahre, Monate, Geschäftsjahr, Typisierung ..) geclustert, physikalisch separiet / indiziert, .. mglw in Deinem Fall nützlich und verfügbar.

Ansonsten wäre es eine Überlegung wert, dass Du per Datenmodell verschiedene "Töpfe" von Anfang an vorsiehst. Sprich separate Tabellen, für "alles was grad reinkommt", "für Export", "Backup inside", "eingehende Daten für Versuchsaufbau bei Vollmond".
Format immer identisch, vielleicht nicht mal als verschiedene Tabellen, sondern als Spalte/Klasse/Kennung einer einzigen Tabelle (siehe Partitionierung)

Das Verschieben, Export, Restore von Topf zu Topf ist dann einerseits Update auf die Kennungsspalte und im Fall import/export ein insert/delete.

[Der schöne Günther]

Richtig, lokale Datenbank, nur mein Prozess greift drauf zu.

Gute Idee mit der Unterteilung
Auf lange Sicht werde ich das vielleicht auch machen.

Und natürlich, das Wiederherstellen eines Backups ist natürlich ein absoluter Sonderfall. Und wenn ich dabei nicht gleichzeitig noch die Daten sehe ist das auch absolut selbstverständlich. Mein "Problem" ist ein anderes: Ich wollte weiterhin unkompliziert Oberflächen zusammenklicken und eventuell neue Connection, Table und Query-Objekte verwenden. In meinem Anwendungscode für Backup/Restore möchte ich die aber nicht wieder haarklein zusammensuchen müssen um sie einmal abzuschalten damit ich in Ruhe an der Datenbank schrauben kann.

Dass es in der BDE und dbExpress eine "zentrale Sammelstelle" gibt macht weiterhin Hoffnung. Ich schaue mir die anderen ADS-Delphikomponenten mal an, vielleicht ist es ja ganz offensichtlich...

[sx2008]

Zitat von Der schöne Günther:

In meinem Anwendungscode für Backup/Restore möchte ich die aber nicht wieder haarklein zusammensuchen müssen um sie einmal abzuschalten damit ich in Ruhe an der Datenbank schrauben kann

Ich würde das Problem im Sourcecode der Hauptanwendung komplett ignorieren.
Stattdessen gibt es ein Wartungstool, dass die Datenbank exklusiv öffnet und die Datenbank packt.

[jobo]

Ich verstehe das Problem mit den Komponenten nicht richtig.
Wenn Du eine Single User Anwendung mit lokaler DB hast, ist doch alles sehr übersichtlich.
Du hast in einer "normalen" Anwendung idR ein Connection Object. Da hängen alle DB Komponenten dran. Wenn die Connection getrennt wird, sind alle DB Kompos "abgeschnitten".
Am einfachsten wäre nun m.E. aus der gleichen Anwendung das Backup aufzurufen, weil gerade hier die Kontrolle über das Disconnect der DB Kompos am größten ist.
Sprich die Anwendung läuft in 2 Modi: Wartung und Betrieb. Der User wählt das über entsprechende Menupunkt und Du bist nahezu 100 Pro sicher, was geht.
Ich weiß nicht, ob Deine DB per SQL gesichert und restored werden kann, das wäre ggF. noch einfacher als externe Befehle aufzurufen. Ansonsten müsstest Du in Deinem Programm vielleicht noch sicherstellen, dass es nur einmal gestartet werden kann (per Mutex oder mittlerweile irgendwie auch anders). So oder so sollte man per Abfrage von Systemviews sehen können, ob/wieviele Connections geöffnet sind oder sogar noch Datensatz/Objektsperren vorliegen.
Das würde ein ordentliches Backup (nicht Filecopy) natürlich sowieso tun und Probleme zurückmelden.

[Bernhard Geyer]

Zitat von Der schöne Günther:

Richtig, lokale Datenbank, nur mein Prozess greift drauf zu.

Auch wenn oben Lokal steht ist das nicht klar. Dann kann man es sich (wie schon jobo angemerkt hat) einfacher machen.

[hstreicher]

nur zur Erinnerung , es geht hier um die Fortsetzung von

http://www.delphipraxis.net/176409-l...auche-ich.html

Er verwendet den DB Server im Uralt DBase Modus