TClientDataSet / TDataSetProvider. Übers Netzwerk?

[Jackie1983]

Servus,

wir sind auf der suche nach einem lokalem DB System. Mir wurde gesagt ich solle mir dochmal TDataSetProvider anschauen damit könnte man übers Netzwerk eine Datenbank verbindung aufbauen. So das mein Client keine Extra Libs braucht. Dann wäre das Thema der lokalen DB gegessen, da auch dem Server eine Oracle DB läuft.

Also die Serveranwendung verwendet Oracle. Damit ich nicht auf jedem Client den Oracle Client installieren muss, kann ich TClientDataSet verwenden um eine Verbindung mit dem Provider aufzubauen :|.

Habe mal nach den dinger gegoogelt aber nicht wirklich was gefunden, weil vorstellen kann ich mir es nicht.

Habt ihr eventuell dazu noch ein paar Infos.

gruß

[Bernhard Geyer]

Für Oracle gibs die Komponenten von DevArt welche keinerlei externe Libs (hier Oracle Client) benötigen und vollständig als Pascal-Code vorliegt.

[Jackie1983]

schon mal gut zuwissen.
Dann werde ich mir diese Komps mal anschauen.
Aber mit dem Provider so wie oben beschrieben geht es also nicht, oder....

--Edit
Ok nachdem ich mir die Preise angeschaut habe, kann man das glaube ich vergessen.

[shmia]

Zitat:

Zitat von Jackie1983 (Beitrag 1145050)

Mir wurde gesagt ich solle mir dochmal TDataSetProvider anschauen damit könnte man übers Netzwerk eine Datenbank verbindung aufbauen

Das ist so nicht ganz richtig.

Mit den angesprochenen Komponenten werden keine Datenbanken übertragen oder getunnelt, sondern dein Server stellt mit Hilfe von TDataSetProvider eine Datenmenge (Dataset) bereit, die ein Client über TClientDataset empfangen kann.
Änderungen auf dem Client können wieder zurück auf den Server übertragen werden.

Du musst für jede SQL-Abfrage ungefähr mit 30 - 50% Mehraufwand rechnen (gegenüber direkten Abfragen vom Client).
Lohnt sich das?

Alternative: Terminalserver verwenden.
Man müsste genauer wissen, was die Anwendung leisten soll um beurteilen zu können welcher Weg der sinnvollste wäre.

[Furtbichler]

[QUOTE=shmia;1145120]

Zitat:

Zitat von Jackie1983 (Beitrag 1145050)

Du musst für jede SQL-Abfrage ungefähr mit 30 - 50% Mehraufwand rechnen (gegenüber direkten Abfragen vom Client). Lohnt sich das?

30-50% wovon? Programmieraufwand? Performance?

Bei einer 3-Tier Lösung wird man sicherlich mit gecachten Daten arbeiten sowie einen Großteil der Geschäftslogik im AppServer unterbringen. Auch kann er mit virtuellen Tabellen umgehen, falls das RDBMS keine updateable views unterstützt.

Man bekommt also was für seine 30-50% Performanceverlust (ich gehe davon aus, das Du das meinst).

Ich persönlich habe diese Einbußen allerdings nur bei wirklich großen Datenmengen gespürt. Und da liegt ja der Fehler im Design, denn wir wollen ja eigentlich keine 10000 Records im Client.

Absolut gesehen dauert eine Query 200ms anstatt 100ms, also doppelt so lange. Ich kann das verschmerzen.

Eine 3-Tier Lösung würde ich aber genau dann nicht einsetzen, wenn es mir darum geht, ob ich nun einen OraClient installieren muss, oder nicht. Da würde ich entweder DevArt nehmen oder eben doch den Client installieren. Was ist daran so schlimm?

[Jackie1983]

Eventuell kurz zur Anwendung.

Brauchen das für einen logger. Bis jetzt wurde die log in einer Textdatei geschrieben. Das ging auch sehr schnell. Nur das suchen muste man per "Hand" in der Textdatei (200MB und mehr).

Also wollen wir die Daten in einer Db speichern. Hatte schonmal ein Thema gestartet für einen nativen DB Typ.

In der Anwendung die übers Netzwerk auf den Dienst zugreift soll die log ausgelesen werden und nach inhalt gefiltert werden.

[jobo]

Also ich finde die Anforderung ja etwas eigenartig. Clientdataset scheint mir der falsche Ansatz.
Was ist der Grund für "keine Libs"? Falls es nur um administrative, organisatorische, usw. Fragen geht:
Der Oracle Instant Client ist je nach Version sehr klein (ca 20 MB) (zumindest im Verhältnis zum "Full" Client)und lässt sich scriptgesteuert installieren.
Anhand Deiner Beschreibung gehe ich nicht von einer Mehrschichtarchitektur aus.
Bei Verzicht auf DB Client könnte man log Dateien (oder Zeilen) als CSV an eine DB Server Filefreigabe schicken und der verarbeitet die per Loader. Der ist sicher schnell genug dafür.
Dadurch könnte vermutlich der Logvorgang im Client fast unberührt bleiben. Man muss aber darauf achten, dass man den Server sauber füttert, also die Logfiles akkurat verwaltet und darf die Sicherheit der Filesystemfreigabe nicht außer Acht lassen. Das ohne Hilfsanwendung zu regeln, ist wahrscheinlich nicht ganz simpel.

[shmia]

Zitat:

Zitat von Jackie1983 (Beitrag 1145206)

Brauchen das für einen logger. Bis jetzt wurde die log in einer Textdatei geschrieben.

Sowas musst du vorher sagen.
Beim Loggen im Netzwerk braucht man das Rad nicht neu erfinden.
Du könntest z.B. auf einem Server einen Syslog-Server betreiben und alle Clients schicken ihre Logmeldungen direkt an den Server.

Hier ein Beispiel für einen SysLog-Server:
http://www.heise.de/software/downloa...personal/53630
Man kann die Logmeldungen filtern, suchen, löschen, exportieren...

PS: man kann sich sogar gezielt bestimmte Logmeldungen per EMail zusenden lassen.
Sehr nettes Feature :-)