Command Handler...jemand Erfahrung?

[ronbrand]

habe mal mit den Command Handlern(oder heist es "Händlern" *g*) der IDTCP Kompos von Indy experimentiert. Die scheinen DAS zu sein nach was ich gesucht hab. Hat jemand praktische Erfahrung gesammelt? Eine Kleinigkeit ist mir noch nicht klar. Wie organisiere ich den eigentlichen Daten-Strom in Verbindung mit dem Command-Handle? als Parameter oder wie(Stream?!)?

Schreibe zur Zeit an einem Server-client Projekt, wo der Server als "Agent" fungieren soll, und auch mit einer Datenbank verbunden ist. Hat jemand sowas schon mal gemacht, dass der Client eine Anforderung an den Server schickt und DER dann den Aufruf und die Kommunikation mit einer Datenbank macht. (Es wäre doch viel einfacher, mit dem Client direkt auf die Datenbank zuzugreifen, aber es geht mir darum den "Agent" als "Kommandozentrale" zu haben z.B. wenn die Datenbank gewartet wird, [Hoffentlich nicht-]ausgefallen ist, etc.)

Danke für Eure Ideen
Gruss Ron

[sakura]

Hi,

was genau willst Du mit den Command-Handlern denn erreichen Wie sollen die letztendlich funktionieren?

......

[ronbrand]

Beispiel: ein client meldet sich am Server an, was mir als Administrator gemeldet wird. einen sehr gut funktionierenden Algorithmus habe ich schon. aber was, wenn ich grössere Datenmengen vom Server anfordere, sagen wir als Beispiel 20 Datensätze aus einer Datenbank, wie gehe ich vor.(wie ich die Datensätze aus der Datenbank kriege ist mir natürlich klar)
Gruss Ron

[ronbrand]

Nachtrag:
eine etwas harte Nuss wird auch das Benutzer-System was ich auch miterstellen muss, mySQL hat zum Beispiel eine hervorragende Benutzer-Rechte Verwaltung. Die könnte ich mir doch zunutze machen, da ich ohnehin mit DB-Anbindung hantieren werde. nur wüsste ich im Moment noch nicht wie. Ich könnte zwar eine dummySQL-Anweisung an die Datenbank schicken um zu sehen ob dieser Benutzer die Rechte x-y-oder Z an der Datenbank hat, aber das gelbe scheint mir so ein Vorgehen nicht zu sein.
Eleganter wäre es sicher, wenn der Benutzer von vornherein auf seinem Bildschirm nur Elemente vorfindet die seinen Zugriffs-Rechten entspricht, nicht wahr?
Gruss Ron

[sakura]

Das, was Du machen willst, sollte sich recht gut mit dem TClientDataSet machen lassen. Das übernimmt die komplette Abwicklung der Client-Server-Beziehung. Beispiele findest Du in den Delphi\Demos\Midas, Delphi\Demos\SQLClientDataset und Delphi\Demos\Corba\Idl2Pas Verzeichnissen.

Damit musst Du Dich nicht um Protokolle, Rechte, etc. sorgen, da das alles durch die CORBA-Schnittstellen erledigt wird. Die Corba-Lizenz unter Delphi 7 (anders als bei den Vorgängerversionen von Delphi) ist royalty-free

......

[ronbrand]

hi Sakura, danke für den Tip...muss ich mir nochmal genauer ansehen(gerade getan). Ich hatte diese Möglichkeit schon vor Wochen verworfen, obwohl das auf den ersten Blick super gewesen wäre, der Grund: Ich konstruiere
1.)einen Server - "Agent"
2.)einen -relativ einfachen- Client
3.)einen -schon-etwas-anspruchsvollerern-Client und
4.)muss das Ganze mit dem dahinter stehenden Datenbank - Server kommunizieren.

Jetzt kommt MIDAS DCOM&Co daher und braucht zusätzlich die üblichen Extrawürste in Form von dies.dll und das.dll und trallala.dll plus Registrierung auf jedem Client-Rechner
im Klartext, bevor ich überhaupt daran denken kann, "meine" Application anzuwerfen muss ich die obigen Extrawürste bedienen. nein danke.
Ziel wird es für mich sein, einen Client zu bauen, der irgendwo im Netzwerk liegt, ich darauf einen Shorcut auf dem Desktop erzeuge und fertig.

Erschwerend für den Angeklagten kommt hinzu dass das Teil warscheinlich einen Traffic produziert dass mir schwarz wird.

Es verursacht bei mir bereits jetzt extreme Bauchschmerzen, wenn ich daran denke wie ich bei einem etwas unbedarfterem Kunden(wo ich NICHT nebendranstehe) eine funktionierende(stabile) Datenbankanbindung hinbekomme.

Der bisherige Client (siehe 2.) verrichtet mit Hilfe von Indy seine Arbeit ganz hervorragend. Es kommt selten vor dass ich 100% zufrieden bin, aber DER machts.
Programm starten und DAS WARS. Minimalste Spielereien sorgen dafür dass das Ding auch dann noch stabil läuft wenn's gegen die Wand gefahren wird.
Einziges Problem was noch bleibt ist der VerwaltungsClient. Hier darf es ja gern etwas komplexer werden, und Dein Vorschlag hätte 'fast' gepasst, wenn ich mir nicht folgendes Scenario ausgedacht hätte.
***KatastrophenModus ON***
Verwaltungs Client-Rechner fällt aus.....
5 Meter weitergehen auf "gewöhnlichem" Client das VerwaltungsProgramm starten ...
nach dem Start und Login die vorher gewaltsam verlassene Situation vorfinden....
ohne Stress weiterarbeiten.
***KatastrophenModus OFF***(bzw. findet erst gar nicht statt)
Solange sich externe DLL - Installationen auf den Server beschränken könnt ich damit leben.
Gruss Ron

[sakura]

Zitat von ronbrand:

Jetzt kommt MIDAS DCOM&Co daher und braucht zusätzlich die üblichen Extrawürste in Form von dies.dll und das.dll und trallala.dll plus Registrierung auf jedem Client-Rechner

Wenn die drei DLLs im gleichen Verzeichnis wie die EXE der Client-App liegen, dann sollte keine weitere Installation von Nöten sein. Einen Versuch ist es wert, oder

deploy.rtf

dsnap70.bpl (ClientDataSet Redistributable)
dsnapcon70.bpl (ClientDataSet Redistributable)
dsnapent70.bpl (ClientDataSet Redistributable)

Zitat von ronbrand:

Erschwerend für den Angeklagten kommt hinzu dass das Teil warscheinlich einen Traffic produziert dass mir schwarz wird.

Der Traffic liegt wahrscheinlich niedriger als bei Deiner (sorry!) "handgestrickten" Lösung, da die Daten für den Traffic imho komprimiert werden (können).

Zitat von ronbrand:

Der bisherige Client (siehe 2.) verrichtet mit Hilfe von Indy seine Arbeit ganz hervorragend. Es kommt selten vor dass ich 100% zufrieden bin, aber DER machts.

Gut, das würde Umstellungen (wahrscheinlich viele ) bedeuten und ob die es wert sind, das kann ich nicht sagen.

Zitat von ronbrand:

***KatastrophenModus ON***
Verwaltungs Client-Rechner fällt aus.....
5 Meter weitergehen auf "gewöhnlichem" Client das VerwaltungsProgramm starten ...
nach dem Start und Login die vorher gewaltsam verlassene Situation vorfinden....
ohne Stress weiterarbeiten.
***KatastrophenModus OFF***

Öhm, der Client wird sich garantiert bis zum letzten gesicherten Datensatz durchfriemeln müssen

......

[ronbrand]

hmm...Respekt !! sakura. Du lässt ja nicht locker und ehrlich gesagt, bin ich immer noch hin und her gerissen, so ganz glücklich bin ich eigentlich mit beiden Standpunkten nicht.

Allerdings, noch mal zurück zu den Midas Demos, ja es stimmt, die laufen richtig gut(habe pflichtgemäss Hausaufgaben gemacht und alle ausprobiert), macht schon Laune. aber aufm anderen Rechner im Netzwerk krieg ich halt dumme Antworten "Klasse nicht registriert" etc...

der Vorschlag von Dir ist IN DER TAT einen Versuch wert und ich setz mich da jetzt doch mal dran(gott bin ich aufgeregt )
Melde mich mit Ergebnissen.

Gruss Ron

[ronbrand]

Fehlerantwort gibt es jetzt auf dem Client-Rechner keine mehr. Dafür schweigt sich der Client nach Kräften aus und startet vorsichsthalber erst mal überhaupt nicht. Keine Fehlerantwort, nix...lediglich in der Ereignisanzeige(winXP prof) mit Quelle Dr.Watson heisst es lapidar:

"Die Anwendung \\XXXXX.exe hat einen Programmfehler verusacht. Datum und Zeit.. ... ...Ausnahme c00000fd an Adresse 77E5A2F9 (Kernel 32! getTickcount)"

wie immer sind solche Fehler-Meldungen von M$ sehr informativ.

Ich weiss doch, warum ich die Finger davon liess.

Ron

[sakura]

So, gut. Dann fragen wir jetzt noch mal kurz (von mir aus auch Copy&Paste von oben) was genau Du jetzt mit den Command Handlern machen willst

......