DBedit, unterschiedlichen DataSources für Lesen/Schreiben

[stolti]

Hallo,

ich bin ganz neu in diesem Forum...so neu auch wieder nicht, denn bisher habe ich
auf alle meine Delphi - Programmierfragen in diesem Forum Antworten gefunden.

Für das folgende Problem habe ich allerdings keine direkte Lösung gefunden
(Vieleicht ist dass, was ich mir vorstelle auch gar nicht machbar oder birgt zu viele Risiken)

Ich möchte ein Datenbanksystem unter MySql realisieren, dessen Daten auf 2 Servern gleichtzeitig
vorhanden sind.
- die Lesesezugriffe auf die Server sollen in dem jeweiligen lokalen Netz durchgeführt werden
um Abfragen beschleunigt durchführen zu können.
- Schreibzugriffe sollen auf nur einem Server durchgeführt werden, und dann mittels Replikation
auf den zweiten Server übermittelt werden
- pro Subnetz maximal 10 Benutzer
- für den Datenzugriff benutze ich die MySqlDac - Komponenten

Jetzt stehe ich vor der Wahl:
1. Ich benutze Standard Edit Felder /Grids etc. und manage das Lesen und Schreiben der Daten
manuell (kein Datasource, Einfügen, Löschen und Ändern mittels generierter SQL - Statements)
2. Ich benutze das Delphi Datasourcen / DbEdit - "Konzept", mit dem Nachteil (u.a.) das
Lesen und Schreiben nur auf einem einzigen Server möglich ist.
=> Bei dem Server der seine Daten aus der Replikation erhält darf nicht geschrieben
werden, der Schreibzugriff müsste also "umgeleitet" werden.

Die Frage lautet: Gibt es eine DBedit Komponente, die zwei verschiedene DataSourcen anbietet
(also ein DS zum Lesen und ein DS zum Schreiben) ?

Die jeweiligen DataSource könnte man ja mit unterschiedlichen Queries verbinden, die wiederum
mit verschiedenen Databases gekoppelt sind

Vieleicht hat jemand eine Tip, oder macht das ganze keinen Sinn ??

Danke !

[marabu]

Herzlich willkommen in der Delphi-PRAXiS, stolti.

Die datensensitiven Komponenten unterstützen nur eine DataSource, aber ist es nicht eher die Datenbankverbindung, die du im laufenden Betrieb ändern möchtest?

Freundliche Grüße

[stolti]

Hallo marabu,

auf den Wechsel der Datenbankverbindung wird es hinaus laufen...die Frage ist ob die
DbEdit´s dann noch verwendbar sind:

=> Derzeit stehe ich vor dem Problem eine größere Anwendung in Richtung Replikation erweitern zu müssen,
habe aber bisher nur DbGrids, DbEdits usw. verwendet und scheue den Aufwand alles umzustellen.
Deshalb will ich erst mal prüfen ob es noch irgendeinen anderen Weg gibt.

Ein DbEdit müsste seine Daten auf Server A Lesen und Änderungen auf den Server B
weiterreichen und bekommt dann die Änderungen mittels Replikation des Servers B auf den Server A
zurück (Deshalb die Frage nach 2 DataSourcen...)

Aas DbEdit der Anwendung, die auf dem Masterserver läuft kann ganz "normal" benutzt werden.

Mann müsste alle Post-, Insert- und Delete-Aktionen auf der Datenmenge des Servers B abfangen und
auf Server A weiterleiten (Wenn man über Datasource Verknüpfungen arbeitet, die diese Aktionen
im Hintergrund abwickeln). Dafür fehlt mir aber bisher das Wissen, so etwas zu relisieren.

"Zu Fuss" könnte ich das machen, indem ich kein DbEdit benutze, sondern nur Edits und alle
Aktionen der Benutzer mittels Buttons und EreignisRoutinen abfange. Hinzu kommt das Ersetzen von DbGrids
mit normalen Grids, die auch alle manuell aufbaut werden müssten.

Somit ist der Aufwand obiges Ziel zu relisieren viel grösser als mit einer Verknüpfung.
(Ich weiss, es ist nicht vorteilhaft datensensitive Elemente für die Arbeit mit SQL-Servern
zu verwenden, allerdings hatte ich bisher zumindest keine Zugriffs-Geschwindigkeitsprobleme)

Wie kann ich denn die Datenbankverbindung zur Laufzeit wechseln ?
Vieleicht so

Schreibzugriff:

MySqlQueryServerA.Database := Database_Server_B Und nach Abschluss des Schreibvorgangs:

MySqlQueryServerA.Database := Database_Server_A Kann man das "ungestraft" machen ?

[marabu]

Hallo stolti,

ich vermute, deine Fragen resultieren auch aus der Verwendung der MySQL Standard Edition, die ja nur die single master replication unterstützt. Die Cluster-Version hat dieses Problem laut Dokumentation nicht.

Ich habe ein solches Szenario noch nicht implementiert. Ein Leistungsmerkmal der datensensitiven Controls (DBEdit, etc.) ist ja die Unterstützung von mode-less UI - der Benutzer muss nicht erst in den Edit-Modus wechseln, um einen Datensatz zu bearbeiten. Ich würde in einer Testanwendung überprüfen, ob ein Wechsel der Verbindung im Ereignis OnStateChange() für Entwickler und Benutzer akzeptabel ist. Dabei muss natürlich eine Zustandsvariable mitgeführt werden, die ein unbeabsichtigtes Triggern der Ereignisbehandlung unterbinden hilft.

Zu deiner nachgeschobenen Frage: Der Wechsel der Verbindung ist schon etwas aufwändiger, hängt aber auch stark von dem bereits existierenden Code ab. Ich gehe von einem Bearbaitungsdialog aus, dessen DB-Controls durch eine Query unterlegt werden, die genau einen Datensatz liefert. Diese Query muss dann mit der ausgetauschten Verbindung erneut abgerufen werden und der unterbrochene Zustandswechsel muss mit der neuen Query zu Ende gebracht werden.

Freundliche Grüße

[stolti]

Hallo marabu,

Ja, es stimmt, die Frage rührt wohl von meiner MySql-Server (4.1) Version her.

Ich habe also jetzt zwei Möglichkeiten:

1. Ich entwerfe ein Testprogramm, mit dem ich das Ereignis "OnStateChange" des jeweiligen
DataSources abfange/umleite. Werde mal im Forum Suchen, ob jemand schon etwas ähnliches
gemacht hat.

2. Ich versuche die MySql Server upzudaten, so dass auch Clustering möglich ist.

Bei Möglichkeit 2 habe ich allerdings (noch) keine Informationen bzgl. des dahinter-
stehenden Konzepts...ich vermute es handelt sich um eine wechselseitige Replikation ?
Muss ich mich mal schlau machen, ob z.B auch AutoInc - Werte realisierbar sind und
ich bei meiner bisherigen Vorgehensweise bleiben kann.

Vielen Dank für Deine Infos !

Ebenfalls freundliche Grüsse.