Verbindung zu Datenbank über Netzwerk aufbauen

[Jens Hartmann]

Hallo zusammen,

ich beschäftige mich gerade das erstemal damit meine Programm Netzwerkfähig zu machen. Ich habe um dieses Zuhause testen zu können, folgenden Versuch aufgebaut. Ich habe meinen Delphi Laptop mit einem anderen Notebook vernetzt.

Das Notebook verfügt über folgende IP-Adresse, die ich auch Pingen kann: 192.168.178.21

Mein Delphi Laptop hat die IP: 192.168.178.20

Ich habe jetzt in meine TZConnection folgenden verschieden Verbindugsstrings schon ausprobiert, aber jedesmal mit der im Anhang befindlichen Fehlermeldung.

Code:

String 1: LOCALHOST:PSSecur 
String 2: 192.168.178.21:PSSecur
String 3: 192.168.178.21:C:\Dokumente und Einstellungen\All Users\Anwendungsdaten\hu\db\PSSecurdat.FDB

String 1 die LOCALHOST Verbindung funktioniert einwandfrei. Die LOCALHOST Verbindung auf dem Notebook wo die Datenbank liegt, funktioniert auch einwandfrei. Wenn ich aber über meinen anderen Laptop auf die DB zugreifen will, geht das nicht.

Hat da jemand vieleicht einen Tip für mich.

Danke schon mal

Gruß Jens

[RWarnecke]

Hallo Jens,

Der String 3 wäre ein richtiger Connectionsstring für eine Firebirdverbindung. Hast Du auf dem Rechner mit der 21 auch einen Firebird-Server laufen und den Port ander Windows-Firewall freigegeben ? Als zweites würde ich auch probieren, mit einem anderen Programm wie IBExpert auf die Datenbank zuzugreifen.

[Jens Hartmann]

Danke Rolf,

lag an meiner Firewall. Habe das ganze jetzt eigendlich schon am rennen. Allerdings, frage ich mich momentan, wie ich es am besten realisiere, die Daten auf dem Clientrechner zu aktualisieren.

Mein Programm schreibt ja Ereignisdaten einer Hardware mit. Jetzt möchte ich natürlich diese auch auf meinem Client aktuell haben. Mache ich das über einen Timer, oder ist es besser wenn ich dem User sowas wie einen "Aktualisieren Button" zur Verfügung stelle.
Oder noch anders, kann ich irgendwie abfangen, wenn in die Datenbank neue Einträge gemacht werden.

Danke nochmal

Gruß Jens

[RWarnecke]

Bitte Jens, kein Problem. Um mitzubekommen, ob gerade etwas in die Datenbank geschrieben wurde, wäre das Ereignis AfterPost vielleicht das richtige. Kommt drauf an, welche Kompos Du benutzt, kann es sein dass es auch etwas anderst heißt. Vielleicht kannst Du Dir damit ja etwas zusammen bauen.

[neo4a]

Firebird kennt Events, die z.B. in einem Trigger aufgerufen werden können. Damit bekommen alle verbundenen Clients ein Meldung, wenn sich in der DB etwas geändert hat und können dann bei Bedarf ein Refresh der Daten durchführen.

--
Andreas

[Jens Hartmann]

Hallo Rolf,

da habe ich auch schon drüber nachgedacht, allerdings habe ich entweder einen Grundlegenden Fehler in meinem Programm, oder ich sehe da so momentan noch nicht wie es gehen könnte.

Ich will kurz versuchen zu Beschreiben, wie ich das gesamte bis jetzt aufgebaut habe. Mein Programm läuft bislang als Einplatzlösung und funktioniert auch nach vielen Test und Änderungen Fehlerfrei. Jetzt habe ich eigendlich nur folgendes gemacht. Um mir eine Serverlösung zu basteln, habe ich das vorhanden Programm nur ein wenig umgebaut. Ich habe eine INI-Datei mit eingebunden, aus der ich folgende Daten beim Programmstart lese.

Code:

[ALLGEMEIN]
MASTER=1

[PSSECUR]
IP=192.168.178.22
STRING=C:\Dokumente und Einstellungen\All Users\Anwendungsdaten\hu\db\PSSecurdat.FDB

[PSUSER]
IP=192.168.178.22
STRING=C:\Dokumente und Einstellungen\All Users\Anwendungsdaten\hu\db\PSUser.FDB

[PSCONFIG]
IP=192.168.178.22
STRING=C:\Dokumente und Einstellungen\All Users\Anwendungsdaten\hu\db\PSConfig.FDB

Mit dem Eintrag Master = 1, passe ich meine Programm-Oberfläche an. Ist Master = 1, werden gewissen Programmpunkte ausgeblendet. Über die 3 Connection Strings, weiße ich der Datenbank den Standort der jeweiligen Datenbank zu. Ich habe das auf 3 Connection aufgebaut, damit der USER später mal die Möglichkeit hat, am Slave andere Rechte zu vergeben wie am Master.

Mein Problem, was ich jetzt sehe, wie bekomme ich den jetzt mit, wenn am Slave eine AfterPost durchgeführt wurde. Ich habe ja uaf diese Daten keinen Zugriff. Oder macht das Firebird irgendwie automatisch.

Mein AfterPost Ereignis befindet sich ja in der Query Kompo und an meinem Master wird dieses einfügen der Daten ja nie durchgeführt. Also müsste ich ja am Master mitbekommen, wenn der Slave eingetragen hat.

Vieleicht denke ich auch noch zu umständlich.

[EDIT]Danke Neo4a, das kann ich mir auch mal noch ansehen. Aber vielecht kann man mir ja trotzdem mal sagen, ob der obige Weg der richtige ist[EDIT]

Gruß Jens

[RWarnecke]

Hallo Jens,

Andreas hat Dir schon des Rätsels Lösung verraten. Ich hätte Dich jetzt auch auf die Events verwiesen. Du kannst über einen Trigger für die jeweilige Tabelle ein Event auslösen. So mache ich das zum Beispiel für die AutoInc-Felder in meinen Tabellen.

[neo4a]

Ohne die spezielle Anwendungslogik zu kennen, gleicht eine Ferndiagnose Hellseherei...und das ist ganz nah an Scharlatanerie.

Egal, hier meine Empfehlung: Firebird-Events erfordern eine aktive Connection zur Datenbank; Du müsstest Deine Clients ggf. gleichzeitig zu allen 3 DB's verbinden. Warum also nicht gleich alles in eine DB packen?

Dass FB seine Clients per Events "informiert", dass etwas passiert ist, gehört zu den eher coolen Features: Push-Notification hat z.B. Blackberries zu Managers Liebling gemacht. Das klassische Polling (per Timer die Clients nötigen, auf Änderungen zu checken) ist eher Bäh im C/S-Umfeld.

Aber natürlich steht es Dir frei, die Event-Notification vom DB-Server in die Clients zu verlagern: Auch dort kannst Du z.B. per UDP-Broadcasting Deinen Client in's Netz brüllen lassen und die Client-Zuhörer damit auffordern, sich auf den neuesten Stand zu bringen. Der zusätzliche Aufwand (im Vergleich zur "fertigen" FB-Lösung) belohnt Dich mit unbegrenzter Flexibilität, ist aber auch nicht ganz trivial, wenn man es das erste Mal macht. In beiden Fällen brauchst Du einen weiteren Port (3050 für FB-Datenverbindung und einen niedrig privilegierten z.B. 30000 für die Events).

Aus H. Borries "The Firebird Book" sei hier von S. 685 das Beispiel zitiert:

SQL-Code:

set term ^;
Create trigger post_new_order for table_sales
active after insert position 0
AS
Begin
  POST_EVENT 'neuer Datensatz';
end^
set term ;^

Hier definierst Du für die Tabelle "tables_sales" einen Trigger, der nach jedem Einfügen/Insert ausgeführt wird. Der feuert dann das Event mit der Bezeichnung "neuer Datensatz" ab, das Du mit einer TIBEvent-Komponente am Client auswerten kannst. Simpel und effektiv und um es mit Willy Astor zu sagen: "Probierstes, dann spürstes..."

--
Andreas

[Jens Hartmann]

Hallo Andreas,

Zitat von neo4a:

Egal, hier meine Empfehlung: Firebird-Events erfordern eine aktive Connection zur Datenbank; Du müsstest Deine Clients ggf. gleichzeitig zu allen 3 DB's verbinden. Warum also nicht gleich alles in eine DB packen?

Ich weiß nicht so richtig, ob die Logik von mir stimmt, aber ich will mal kurz den Zusammenhang beschreiben.

Ich habe ein Objekt z.B. in Berlin. In diesem Objekt werden Ereignisse einer Einbruchmeldeanlage auf einem solchen Client als Einplatzlösung gespeichert. Jetzt gibt es da z.B. ein Objekt in Köln, von dem alle Objekte Deutschland weit betreut werden.

An diesem Standort möchte ich jetzt, je nach Bedarf auf die einzelnen Objekte zugreifen. Die Standorte sind über VPN vernetzt. Soll aber bedeuten, ich will mir das Objekt auswählen und manuell eine Verbindung zum Objekt aufbauen. Aus diesem Grund die 3 Datenbanken. Ich möchte am MASTER Standort, die Möglichkeit haben, das USER Einstellungen und Oberflächengestaltung komplett selbstständig verwaltet werden zu können.
Lediglich die Ereignissdaten möchte ich mir aus der Ferne holen könne. Das ganz geht ja jetzt auch schon soweit.

Jetzt war aber mein nächster Gedanke, so eine Art LIVE-Screen zu realisieren. Ich möchte also, z.B. auf einen Button Klicken, welchen ich mit LIVE beschrifte, und ab diesem Moment wie vor ORT sein. Das heißt, wenn jetzt Ereignisse auftreten, möchte ich diese direkt sehen können. Sobald ich den Haken oder Button wieder ändern würde, wird der LIVE-Screen Modus beendent.

Zitat von neo4a:

Warum also nicht gleich alles in eine DB packen?

Die Gesamte Datenmenge wäre bei der Anzahl der Objekt viel zu Groß wenn ich diese Zentral sichern wollte. Außerdem, wäre das absolut nicht notwendig und wegen eventuell auftretenden Netzwerkfehlern zu gefährlich. Daher möchte ich einfach, das die Daten bei den Clients liegen und bei Bedarf geholt werden können.

Ich hoffe ich konnt den ablauf so mal ein bißchen beschreiben.

Gruß Jens

[neo4a]

Also 3 Datenbanken, das passt dann schon.

Je nachdem, was für einen Umfang das "Live"-Erlebnis hat, würde ich die Nachrichten per TCP/IP-Connection direkt zum verbundenen Client senden. Damit bleibt die Anwendungslogik direkt im Client und es ist auch nicht erforderlich, dass der empfangenende Client sich direkt mit der DB verbinden und die Daten per SQL-Query erst noch abholen muss (was beim FB-Event noch nötig wäre).

Du erstellst dazu am besten eine MemTable und "fütterst" diese mit den empfangenen Nachrichten - quasi als Live-Log. Das hat dann auch erst einmal nichts mit FB zu tun, da der sendende Client das direkt in seinem Post-Event ausführen kann. Ich habe da gute Ergebnisse mit den ICS-Komponenten gemacht. Auch die tschechische Synapse-Library ist gut geeignet; mit den Indy-Komponenten habe ich keine Erfahrungen, weil sie zu der Zeit, als ich sie gebraucht hätte, nicht zu gebrauchen waren. Das kann jetzt anders sein.

Edit: Links korrigiert.

--
Andreas