WANTED: DB für schlechte Netzwerke

[QuickAndDirty]

Welche Datenbank muss ich nehmen um FatClients in einem NICHT Administrierten Netzwerk zu betreiben...
(Der Netzwerk Admin ist verwand mit dem Besitzer und unfehlbar...)

Gehen wir einfach davon aus das vorliegende Netzwerk ist lahm. Und der Flaschenhals nicht direkt auffindbar Virenscanner, Firewalls, Switche, Netzwerkkarten....

Wenige große Datenpackete sind schnell übertragen aber viele kleine Datenpakete dauern....

das Programm setzte ausschließlich "Select, insert , update, delete" statements ab. In der Regel Prepared und Parametrisiert.


Ich habe schon festgestellt das MSSQL unter genannten bedingungen um längen besser funzt als Firebird

Wer hat solche Erfahrungswerte für andere Paarungen beizusteuern?

[jobo]

Sorry, das klingt etwas drollig. Ich würde versuchen, das Netz rund zu bekommen, aber Du musst ja mit den Gegenenheiten "arbeiten".

Ich kann eigentlich keine spezifischen Rankings liefern, nur ein paar allgemeine Gedanken. Fat Clients sind ja offenbar sehr geschwätzig (verglichen mit WEB basierten Systemen).
In Deinem Problembereich (Symptome) sehe ich die Netzwerkschwächen dann offenbar im Bereich Routing, Adressierung, Namensauflösung, nicht in der Bandbreite. Sprich, der DB Client ist vorwiegend damit beschäftigt, auf Antworten von DNS und Co zu warten. Große Pakete gibt es glaub ich weniger in dem Bereich.
Bei MS (in einem MS Netzwerk) gibt es ja gefühlt 50 weitere Protokolle neben DNS und DHCP), dass MS Produkte da verhältnismäßig gut mit klarkommen, ist nicht verwunderlich.
Meine Strategie wäre:
Das eigentliche Netzwerkproblem rausfinden (schlechter DNS, lokale DNS Einstellungen nach außen und vlt sogar falsche DNS Angaben, alte Protokolle, z.B. NetBUI oder wie das hies, usw.) Dann ein entsprechendes Arangement bilden.
GGf. Namensauflösung vermeiden (also Clientconfig IP basiert) oder sogar Fat Client "vermeiden". Ich weiß janicht, wie frei Du ansonsten in der "Wahl der Waffen" bist, aber mit dem Fat Client etwas näher an eine Webarchitektur zu rücken, wäre vielleicht einen Test wert. Dabei denke ich an sowas wie mORMot. Hab's noch nicht genutzt, aber wird hier gelegentlich genannt.

[QuickAndDirty]

Zitat:

Zitat von jobo (Beitrag 1157315)

Sorry, das klingt etwas drollig. Ich würde versuchen, das Netz rund zu bekommen,

Ich auch...aber ich bin kein Admin...und so forensische Analysen was Netzwerke betrifft sind sehr sehr aufwendig...und man muss ne Menge Ahnung haben. Wir haben hier wirklich nur Entwickler und Verkäufer in der Firma.

Zitat:

Zitat von jobo (Beitrag 1157315)

aber Du musst ja mit den Gegenenheiten "arbeiten".

Das kommt daher da ja alle anderen Sachen schnell durchs Netzwerk gehen...z.B. Große Archive, CAD Dateien, Worddokumente...
Nur unsere Anwendung ist langsam...also ist das aus Adminsicht ganz klar unser Problem, auch wenn wir wissen das es etliche Firmen gibt bei denen es gefühlt 15 mal schneller ist.

Zitat:

Zitat von jobo (Beitrag 1157315)

Ich kann eigentlich keine spezifischen Rankings liefern, nur ein paar allgemeine Gedanken. Fat Clients sind ja offenbar sehr geschwätzig (verglichen mit WEB basierten Systemen).

Ja, insbesondere mit FB als Basis.

Zitat:

Zitat von jobo (Beitrag 1157315)

In Deinem Problembereich (Symptome) sehe ich die Netzwerkschwächen dann offenbar im Bereich Routing, Adressierung, Namensauflösung, nicht in der Bandbreite. Sprich, der DB Client ist vorwiegend damit beschäftigt, auf Antworten von DNS und Co zu warten. Große Pakete gibt es glaub ich weniger in dem Bereich.

Der Admin will sich in dieser Richtung nicht bewegen. Auf keinen Fall kann an dingen geschraucbt werden die in seinem Verantwortungsbereich liegen, schließlich ist er eine Koryphäe der netzwerktechnik.

Zitat:

Zitat von jobo (Beitrag 1157315)

Bei MS (in einem MS Netzwerk) gibt es ja gefühlt 50 weitere Protokolle neben DNS und DHCP), dass MS Produkte da verhältnismäßig gut mit klarkommen, ist nicht verwunderlich.

Also ich war sehr überrascht das MSSQL wirklich um einiges schneller ist als FB...

Zitat:

Zitat von jobo (Beitrag 1157315)

Meine Strategie wäre:
Das eigentliche Netzwerkproblem rausfinden (schlechter DNS, lokale DNS Einstellungen nach außen und vlt sogar falsche DNS Angaben, alte Protokolle, z.B. NetBUI oder wie das hies, usw.) Dann ein entsprechendes Arangement bilden.

Ok, der teil der Strategie, ist nicht möglich (wegen Reibung mit dem Admin). (Für den ist ja auch total normal das von 4 pings 3 verloren gehen....)

Zitat:

Zitat von jobo (Beitrag 1157315)

GGf. Namensauflösung vermeiden (also Clientconfig IP basiert)

Hey das ist gut. Da habe ich noch garnicht drann gedacht! Derzeit ist FB über den Computername konfiguriert. Aber merkt sich so ein PC nicht die Auflösung eines Computernamens im Lokalen Netz?

Zitat:

Zitat von jobo (Beitrag 1157315)

oder sogar Fat Client "vermeiden".

Es handelt sich um einen 1,8 Millionen Code Zeilen FatClient... das ist so in 25 jahren Programmentwicklung aufgelaufen. Wir haben auch ein Webprodukt das wirklich gut skaliert, aber hier ist leider der FatClient gefragt.

Zitat:

Zitat von jobo (Beitrag 1157315)

Ich weiß janicht, wie frei Du ansonsten in der "Wahl der Waffen" bist, aber mit dem Fat Client etwas näher an eine Webarchitektur zu rücken, wäre vielleicht einen Test wert. Dabei denke ich an sowas wie mORMot. Hab's noch nicht genutzt, aber wird hier gelegentlich genannt.

Das intelligenteste wäre für besagtes Netzwerk über Terminalserver zu arbeiten oder das Netzwerk flott zu machen....aber intelligenz ist nunmal hier nicht angebracht, deswegen ich suche eine DB die auch mit HiPingBastard Netzwerken klar kommt.
Irgendwo muss es doch Rankings zu Geschwätzigkeit von geben.

[mkinzler]

Man könnte den Verkehr bündeln/komprimieren

http://www.winton.org.uk/zebedee/ oder http://www.stunnel.org/

Damit bekommet man sogar (FireBird-)Verkehr über das Internet gehandelt.

http://firebird.sourceforge.net/down...ebedee_eng.pdf

[tsteinmaurer]

Das Firebird-Remote-Protokoll ist bekannt "geschwätzig". Siehe auch den Lesestoff hier:

http://dyemanov.blogspot.com/2012/01...t-network.html
http://dyemanov.blogspot.com/2012/03...d-buffers.html
http://dyemanov.blogspot.com/2012/03...-batching.html

Wenn man sich aber in einem LAN befindet, dann sollte das nicht so viel ausmachen. Vorausgesetzt natürlich, dass netzwerktechnisch sowohl hardware-, als auch softwareseitig (DNS-Auflösung etc.) die Sache einigermaßen im grünen Bereich ist.

Interessant ist auch, was denn der Fat-Client so treibt. Ich hab client-seitig im Umfeld von Firebird schon viel gesehen und performancetechnisch wundert mich da manchmal gar nichts mehr. :-D Ev. liegt ja Optimierungspotential im Fat-Client und der zugrundeliegenden Firebird Datenbank (Konfiguration, Indexes etc.)

[jobo]

Zitat:

Zitat von QuickAndDirty (Beitrag 1157906)

Zitat:

Zitat von jobo (Beitrag 1157315)

In Deinem Problembereich (Symptome) sehe ich die Netzwerkschwächen dann offenbar im Bereich Routing, Adressierung, Namensauflösung, nicht in der Bandbreite. Sprich, der DB Client ist vorwiegend damit beschäftigt, auf Antworten von DNS und Co zu warten. Große Pakete gibt es glaub ich weniger in dem Bereich.

Der Admin will sich in dieser Richtung nicht bewegen. Auf keinen Fall kann an dingen geschraucbt werden die in seinem Verantwortungsbereich liegen, schließlich ist er eine Koryphäe der netzwerktechnik.

Ich meinte auch, dass Du Dich bewegen musst. Du kannst selbst ohne Netzwerkkenntnisse mit ein paar einfachen Tests das Problem eingrenzen.
Z.B. einen Client Zugriff auf Basis der IP adresse statt DNS Name aufsetzen und Performance Tests machen.
Außerdem kann man einfach mittels Taskmanager / Netzwerktraffic sehen(!), was die Anwendung selbst für Last produziert bzw. welche Grundlast ohne Eure Anwendung da ist.

Jenach Technology oder verwendeten Kompos (alà "ultimativeTreeviewKomponente", die die halbe DB in den Tree saugt) hat man schnell mal eine riesige Tabelle im Hintergrund geöffnet und erst später den gewollten Filter appliziert. (Frage von Event Reihenfolge, usw.) Soetwas fällt häufig nicht im Entwicklersystem auf, da dort die echten Datenmengen fehlen. Also vor Ort testen und Netzwerkmoni beobachten.

Zitat:

Zitat von QuickAndDirty (Beitrag 1157906)

Zitat:

Zitat von jobo (Beitrag 1157315)

Meine Strategie wäre:
Das eigentliche Netzwerkproblem rausfinden (schlechter DNS, lokale DNS Einstellungen nach außen und vlt sogar falsche DNS Angaben, alte Protokolle, z.B. NetBUI oder wie das hies, usw.) Dann ein entsprechendes Arangement bilden.

Ok, der teil der Strategie, ist nicht möglich (wegen Reibung mit dem Admin). (Für den ist ja auch total normal das von 4 pings 3 verloren gehen....)

S.o. unabhängig vom Admin kannst Du sicher selbst ein paar Sachen abchecken.

Zitat:

Zitat von QuickAndDirty (Beitrag 1157906)

Zitat:

Zitat von jobo (Beitrag 1157315)

oder sogar Fat Client "vermeiden".

Es handelt sich um einen 1,8 Millionen Code Zeilen FatClient... das ist so in 25 jahren Programmentwicklung aufgelaufen. Wir haben auch ein Webprodukt das wirklich gut skaliert, aber hier ist leider der FatClient gefragt.

ok, wieviel Clients sind da in Betrieb.
>Ein< geschwätziger Fat Client plus ein paar Missgriffe in der anwendung selbst sind ja nicht schlimm, aber 100, .. ?

[QuickAndDirty]

Zitat:

Zitat von jobo (Beitrag 1157929)

Zitat:

Zitat von QuickAndDirty (Beitrag 1157906)

Zitat:

Zitat von jobo (Beitrag 1157315)

In Deinem Problembereich (Symptome) sehe ich die Netzwerkschwächen dann offenbar im Bereich Routing, Adressierung, Namensauflösung, nicht in der Bandbreite. Sprich, der DB Client ist vorwiegend damit beschäftigt, auf Antworten von DNS und Co zu warten. Große Pakete gibt es glaub ich weniger in dem Bereich.

Der Admin will sich in dieser Richtung nicht bewegen. Auf keinen Fall kann an dingen geschraucbt werden die in seinem Verantwortungsbereich liegen, schließlich ist er eine Koryphäe der netzwerktechnik.

Ich meinte auch, dass Du Dich bewegen musst. Du kannst selbst ohne Netzwerkkenntnisse mit ein paar einfachen Tests das Problem eingrenzen.
Z.B. einen Client Zugriff auf Basis der IP adresse statt DNS Name aufsetzen und Performance Tests machen.
Außerdem kann man einfach mittels Taskmanager / Netzwerktraffic sehen(!), was die Anwendung selbst für Last produziert bzw. welche Grundlast ohne Eure Anwendung da ist.

Das mit dem umgehen des DNS ist eine idee die ich ganz vergessen hatte das kann man versuchen.
Traffic und prozessorlast habe ich gemessen. Prozessorlast immer unter 2% und traffic wenige KB/s Bandbreite in den spitzen. Ich wünschte ja es wäre mehr! Er soll sich die Bandbreite und Rechenzeit nehmen...er tut es nur nicht. Habe die Ursache schon soweit eruiert das die Latenz das Problem ist. Leider ist FB auch besonders anfällig für schlechte Latenz weil viel über ping pongs läuft.

Zitat:

Zitat von jobo (Beitrag 1157929)

Jenach Technology oder verwendeten Kompos (alà "ultimativeTreeviewKomponente", die die halbe DB in den Tree saugt) hat man schnell mal eine riesige Tabelle im Hintergrund geöffnet und erst später den gewollten Filter appliziert. (Frage von Event Reihenfolge, usw.) Soetwas fällt häufig nicht im Entwicklersystem auf, da dort die echten Datenmengen fehlen. Also vor Ort testen und Netzwerkmoni beobachten.

Ja ich kenne das Dilema. Hatte ich auch mal bei einem Piloten. Hier handelt es sich allerdings um eine Software die auf vielen tausend Kunden Netzwerken absolut flüssig läuft.

Zitat:

Zitat von jobo (Beitrag 1157929)

Zitat:

Zitat von QuickAndDirty (Beitrag 1157906)

Zitat:

Zitat von jobo (Beitrag 1157315)

oder sogar Fat Client "vermeiden".

Es handelt sich um einen 1,8 Millionen Code Zeilen FatClient... das ist so in 25 jahren Programmentwicklung aufgelaufen. Wir haben auch ein Webprodukt das wirklich gut skaliert, aber hier ist leider der FatClient gefragt.

ok, wieviel Clients sind da in Betrieb.
>Ein< geschwätziger Fat Client plus ein paar Missgriffe in der anwendung selbst sind ja nicht schlimm, aber 100, .. ?

Ein Server und 2 Fatclients der Rest wird über das Web abgewickelt. Wobei der Webserver im prinzip auch als MegaFatClient zählt.

[tsteinmaurer]

Sofern die existierende Lösung auf Firebird und im speziellen auf 2.5 basiert, dann wirf mal die Trace API an, um ein Gefühl dafür zu bekommen, was client-seitig so abgesetzt wird.

[QuickAndDirty]

Zitat:

Zitat von mkinzler (Beitrag 1157909)

Man könnte den Verkehr bündeln/komprimieren

http://www.winton.org.uk/zebedee/ oder http://www.stunnel.org/

Damit bekommet man sogar (FireBird-)Verkehr über das Internet gehandelt.

http://firebird.sourceforge.net/down...ebedee_eng.pdf

Ja darauf bin ich auch schon gestoßen. Aber ich bin bereit zu wechseln...Anydac unterstützt ja eine breite auswahl an DBs .
Gibts Datenbanken die von natur aus weniger geschwätzig sind?

[QuickAndDirty]

Zitat:

Zitat von tsteinmaurer (Beitrag 1157936)

Sofern die existierende Lösung auf Firebird und im speziellen auf 2.5 basiert, dann wirf mal die Trace API an, um ein Gefühl dafür zu bekommen, was client-seitig so abgesetzt wird.

Dem ist so :)
Ist die 64Bit Variante (ja die soll ja auch noch langsamer sein....als die 32Bit Version)

Ich weiß das FB geschwätzig ist...
Wonach soll ich in dem Trace suchen?

Wir kennen in etwa die Probleme mit dem Protokoll...(warum z.B. ein Prepare echt viel Zeit kosten kann.....&c.)

Aber so eine DB die ein bisschen besonders wenig anfällig für latenz ist (wenige ping pongs) kennst du nicht?

[tsteinmaurer]

Also, die 2(!) Fat-Clients und der Webserver greifen im LAN (mit geringer Latenz) auf die Datenbank zu? Wenn ja, auf die Gefahr hin, dass ich mich wiederhole, aber da liegt mit ziemlicher Sicherheit die Spaßbremse in der Client-Anwendung und nicht im Remote-Protokoll. Was war nochmal dein ursprüngliches Problem? Einfach nur schlechte Performanz?

[tsteinmaurer]

Zitat:

Wonach soll ich in dem Trace suchen?

Naja, die üblichen Kennzahlen, die etwas mit Performanz tun haben. Also z.B. die Ausführungsplan, Ausführungszeit, I/O-Statistiken, Indexed vs. Non-Indexed Reads, abseits vom Trace Output in Hinblick auf die Selektivität der Indizes in deiner Datenbank etc.

[neo4a]

Zitat:

Zitat von tsteinmaurer (Beitrag 1157941)

Was war nochmal dein ursprüngliches Problem? Einfach nur schlechte Performanz?

Ich denke, es ist ein schlecht konfiguriertes Kundennetzwerk. Möglicherweise gibt es da aktive Komponenten, die Traffic-Priorisierung o.ä. vornehmen. Schlecht, wenn man einen Admin hat, der nicht helfen will. Gut, wenn man eine solch simple App hat, mit der man mal eben schnell die DB wechseln kann.

Da FB unterschiedliche Ports unterstützt, würde ich es einmal mit einem versuchen, der normalerweise von einem SQL-Server benutzt wird. Vielleicht kann man Problem und Admin damit umgehen.

[QuickAndDirty]

Zitat:

Zitat von tsteinmaurer (Beitrag 1157941)

Also, die 2(!) Fat-Clients und der Webserver greifen im LAN (mit geringer Latenz) auf die Datenbank zu? Wenn ja, auf die Gefahr hin, dass ich mich wiederhole, aber da liegt mit ziemlicher Sicherheit die Spaßbremse in der Client-Anwendung und nicht im Remote-Protokoll. Was war nochmal dein ursprüngliches Problem? Einfach nur schlechte Performanz?

Es sollen mal 2 Fatclients sein...
Ich teste es aber direct auf dem Server mit einem Fatclient...die sind nicht an während ich teste...

Die Fatclients laufen absolut flüssig...überall...bei vielen Kunden...nur bei einem nicht.

Bei besagtem Kunden gehen 3 von 4 pings verloren!!!! Deine Folgerung daraus :"An dem Netzwerk liegt es nicht sondern am Fatclient" ....

OK ^^

[QuickAndDirty]

Zitat:

Zitat von neo4a (Beitrag 1157956)

Da FB unterschiedliche Ports unterstützt, würde ich es einmal mit einem versuchen, der normalerweise
von einem SQL-Server benutzt wird. Vielleicht kann man Problem und Admin damit umgehen.

Ok das wäre einen versuch wert! Vielleicht geht 1435 schneller.

[jobo]

Wenn Du dabei bist, kannst du ja auch mal named pipe connect versuchen (zumindest falls das angesagt ist unter fb)

[neo4a]

Zitat:

Zitat von QuickAndDirty (Beitrag 1157971)

OK ^^

Bei Deiner konfusen Problem-Erörterung und scheibchenweisen Info-Bereitstellung kann man leicht den Überblick verlieren. Und das im kommerziellen Umfeld?!

Aber da Du ja ohnehin mal eben das DB-System wechseln kannst, macht es auch nichts, wenn Du einem ausgewiesenen FB-Experten wie Thomas symbolisch an's Bein pinkelst. - Nun, vielleicht kommt bei Dir mit den Jahren zur Erfahrung auch noch besseres Benehmen hinzu, vielleicht.

[QuickAndDirty]

Zitat:

Zitat von neo4a (Beitrag 1157979)

Zitat:

Zitat von QuickAndDirty (Beitrag 1157971)

OK ^^

Bei Deiner konfusen Problem-Erörterung und scheibchenweisen Info-Bereitstellung kann man leicht den Überblick verlieren. Und das im kommerziellen Umfeld?!

Die Frage war gibt es eine Datenbank die mit schlechten Netzwerken besser klar kommt. Das ist das Thema des Threads. Ich habe ausgeführt was ich unter schlechten netzwerken verstehe.
Kennst du eine DB die damit zumindest besser als FB klar kommt? Wenn ja dann habe ich das in deinem Beiträgen überlösen.
Ja das im kommerziellen Bereich. Delphi wäre als Hobby doch recht Teuer.

Zitat:

Zitat von neo4a (Beitrag 1157979)

Aber da Du ja ohnehin mal eben das DB-System wechseln kannst,

Im Rahmen des ablösens der BDE haben wir dafür gesorgt das Datenbank-Hersteller austauschbar sind...es muss nur eine SQL 2003 Datenbank sein. Wir haben eine zentrale Datenzugriffsschicht.
Wir liefern aber nur in FB/Interbase/MSSQL/Oracle aus. (kaum einer braucht Oracle.....)

Zitat:

Zitat von neo4a (Beitrag 1157979)

macht es auch nichts, wenn Du einem ausgewiesenen FB-Experten wie Thomas symbolisch an's Bein pinkelst.

Kein bisschen, ich pflege mein geschäft real und virtuell stets auf der Toilette zu tätigen.

Zitat:

Zitat von neo4a (Beitrag 1157979)

- Nun, vielleicht kommt bei Dir mit den Jahren zur Erfahrung auch noch besseres Benehmen hinzu, vielleicht.

Der einzige der die Sachebene verlassen hat bist du. Kann das sein?

[mkinzler]

Zitat:

Im Rahmen des ablösens der BDE haben wir dafür gesorgt das Datenbank-Hersteller austauschbar sind...es muss nur eine SQL 2003 Datenbank sein.

Dann bleibt ja nur Oracle ( erfüllt zwar SQl 2003 auch nicht ganz, ist aber am Nähesten dran).

Was neo4a meint ist, dass es wenig klug wäre das DBMS zu wechseln, nur weil bei einem Kunden die zu erwartenen Mindestvoraussetzungen an ein Netzwerk nicht erfüllt sind.

Wenn das Wechseln so einfach ist, werden die verwendeten DBMS auch nicht richtig unterstützt, d.h. es ist nicht für diese optimiert. den diese unterscheiden sich im Detail doch sehr, auch wenn sie im ersten Blick den Standard unterstützen.

Ich würde an deiner Stelle vielleicht nur 2 DBMS unterstützen ( z.B. MSSQL, wenn Kunde bereit ist für das DBMS zu zahlen und FB, wenn es kostenlos sein soll), diese aber dann optimal ausnutzen.

[mschaefer]

Als Vergleich würde ich neben MSSQL mal Interbase testen, da hier wohl keine Veränderungen im Code gemacht werden müßten.
Und ich neige dazu mal einen Test mit verschiedenen Datenzugriffskomponenten zu machen.

Wenn kleine Datenpakete verlorengehen und große problemlos laufen, dann geht irgendeine Komponente im Netz zwischendurch schlafen. Entweder Ihr findet den Schuldigen durch geduldige Pingtest, oder Ihr baut schlicht eine Pingkomponente in Euer Programm ein, damit der Schlaf keine Chance hat.

Und bei der kommerziellen Variante sehe ich das wie Markus.

Grüße // Martin

[neo4a]

Zitat:

Zitat von QuickAndDirty (Beitrag 1157985)

Die Frage war gibt es eine Datenbank die mit schlechten Netzwerken besser klar kommt.

Allein durch diese Fragestellung hätte ich Dich eher im Hobby-Umfeld vermutet. IMO hat sich eine DB in erster Linie um die Daten zu kümmern. Es kann nicht die Aufgabe eines DB-Systems sein, Konfigurationsfehler in einem Netzwerk zu handeln (BTW, was kennzeichnet eigentlich ein schlechtes, und ab wann spricht man von einem guten und wann haben wir das "Optimalst-Bestmögliche" Netzwerk?).

Deine restlichen Einlassungen lasse ich unkommentiert.

@mkinzler: War meine Meinung wirklich so offensichtlich ;) Und wo doch MS-SQL in diesem Netzwerk rennt und sogar noch von der fraglichen FAT-APP supportet wird: Warum dann noch FB? Aber ich will mal nicht zu laut denken, sonst gibt's wieder Noten vom TE - und wer will das schon?!

[Bernhard Geyer]

Zitat:

Zitat von mkinzler (Beitrag 1157989)

Wenn das Wechseln so einfach ist, werden die verwendeten DBMS auch nicht richtig unterstützt, d.h. es ist nicht für diese optimiert. den diese unterscheiden sich im Detail doch sehr, auch wenn sie im ersten Blick den Standard unterstützen.

Ich würde an deiner Stelle vielleicht nur 2 DBMS unterstützen ( z.B. MSSQL, wenn Kunde bereit ist für das DBMS zu zahlen und FB, wenn es kostenlos sein soll), diese aber dann optimal ausnutzen.

Blos nicht nur 2. Wenn der Frager schon die gebräuchlichsten DBs (MS SQL, Oracle, MySQL, ...) unterstützt hat man nämlich ein wichtigen Punkt weg - Dem Kunden vorzuschreiben welches DBMS er einsetzen muss. Den sobald man das macht wird der Kunde oft genug versuchen diverse Aufgaben auf einem abzuwälzen (Backup einrichten, Sicherheitseinstellung, Tuning, ...) bzw. für Probleme in ganz anderm Umfeld verantwortlich zu machen "Sie haben doch hier eine DB eingrichtet. Seitdem gibts Probleme mit ...." (auch wenn diese zu 99,99% nichts mit dem DBMS zu tun haben). Eine kommerzielle und eine kostenlose DB ist zu wenig! Es müssen die gebräuchlichsten sein (siehe oben).

[mkinzler]

Nachtreten bringt auch nichts!

Bitte fangt hier keinen Schlagabtausch auf persönlicher Ebene an.

[mkinzler]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1157996)

Zitat:

Zitat von mkinzler (Beitrag 1157989)

Wenn das Wechseln so einfach ist, werden die verwendeten DBMS auch nicht richtig unterstützt, d.h. es ist nicht für diese optimiert. den diese unterscheiden sich im Detail doch sehr, auch wenn sie im ersten Blick den Standard unterstützen.

Ich würde an deiner Stelle vielleicht nur 2 DBMS unterstützen ( z.B. MSSQL, wenn Kunde bereit ist für das DBMS zu zahlen und FB, wenn es kostenlos sein soll), diese aber dann optimal ausnutzen.

Blos nicht nur 2. Wenn der Frager schon die gebräuchlichsten DBs (MS SQL, Oracle, MySQL, ...) unterstützt hat man nämlich ein wichtigen Punkt weg - Dem Kunden vorzuschreiben welches DBMS er einsetzen muss. Den sobald man das macht wird der Kunde oft genug versuchen diverse Aufgaben auf einem abzuwälzen (Backup einrichten, Sicherheitseinstellung, Tuning, ...) bzw. für Probleme in ganz anderm Umfeld verantwortlich zu machen "Sie haben doch hier eine DB eingrichtet. Seitdem gibts Probleme mit ...." (auch wenn diese zu 99,99% nichts mit dem DBMS zu tun haben). Eine kommerzielle und eine kostenlose DB ist zu wenig! Es müssen die gebräuchlichsten sein (siehe oben).

Die meisten Anbieter bieten aber gerade ein Bestimmtes an. Lieber wenige richtig, als alle "suboptimal".

[QuickAndDirty]

Zitat:

Zitat von mkinzler (Beitrag 1157989)

Zitat:

Im Rahmen des ablösens der BDE haben wir dafür gesorgt das Datenbank-Hersteller austauschbar sind...es muss nur eine SQL 2003 Datenbank sein.

Dann bleibt ja nur Oracle ( erfüllt zwar SQl 2003 auch nicht ganz, ist aber am Nähesten dran).

Was neo4a meint ist, dass es wenig klug wäre das DBMS zu wechseln, nur weil bei einem Kunden die zu erwartenen Mindestvoraussetzungen an ein Netzwerk nicht erfüllt sind.

Wenn das Wechseln so einfach ist, werden die verwendeten DBMS auch nicht richtig unterstützt, d.h. es ist nicht für diese optimiert. den diese unterscheiden sich im Detail doch sehr, auch wenn sie im ersten Blick den Standard unterstützen.

Ich würde an deiner Stelle vielleicht nur 2 DBMS unterstützen ( z.B. MSSQL, wenn Kunde bereit ist für das DBMS zu zahlen und FB, wenn es kostenlos sein soll), diese aber dann optimal ausnutzen.

Es ist so das wir tatsächlich deswegen auf Skripte und stored Procedures usw. verzichten...
In sofern hast du recht, das wir das Problem lösen könnten in dem wir die Logik weitestgehend in stored procedures legen würden.

[QuickAndDirty]

Zitat:

Zitat von neo4a (Beitrag 1157995)

Allein durch diese Fragestellung hätte ich Dich eher im Hobby-Umfeld vermutet.

Na ja, also Delphi als Hobby ist mir zu teuer...mein Hobby ist C#

Zitat:

Zitat von neo4a (Beitrag 1157995)

IMO hat sich eine DB in erster Linie um die Daten zu kümmern. Es kann nicht die Aufgabe eines DB-Systems sein, Konfigurationsfehler in einem Netzwerk zu handeln

Ds hast du völlig recht. Der Fall der mich die Frage hat aufwerfen lassen ist tatsächlich eher etwas was man irgendwo auf Kindergartenniveau verorten würde. Da ich aber am liebsten konflikten aus dem Weg gehe...versuche ich eben irgendeine Lösung zeitnah zu liefern die funktioniert ohne das ich mich mit dem Admin des Kunden anlegen muss....

Zitat:

Zitat von neo4a (Beitrag 1157995)

Deine restlichen Einlassungen lasse ich unkommentiert.

Kein problem. Ich bin eben der Böse.

Zitat:

Zitat von neo4a (Beitrag 1157995)

@mkinzler: War meine Meinung wirklich so offensichtlich ;) Und wo doch MS-SQL in diesem Netzwerk rennt und sogar noch von der fraglichen FAT-APP supportet wird: Warum dann noch FB?

Weil wir für Konnektivität nach MSSQL und ORACLE Aufpreis verlangen :-)

[QuickAndDirty]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1157996)

Blos nicht nur 2. Wenn der Frager schon die gebräuchlichsten DBs (MS SQL, Oracle, MySQL, ...) unterstützt hat man nämlich ein wichtigen Punkt weg - Dem Kunden vorzuschreiben welches DBMS er einsetzen muss. Den sobald man das macht wird der Kunde oft genug versuchen diverse Aufgaben auf einem abzuwälzen (Backup einrichten, Sicherheitseinstellung, Tuning, ...) bzw. für Probleme in ganz anderm Umfeld verantwortlich zu machen "Sie haben doch hier eine DB eingrichtet. Seitdem gibts Probleme mit ...." (auch wenn diese zu 99,99% nichts mit dem DBMS zu tun haben). Eine kommerzielle und eine kostenlose DB ist zu wenig! Es müssen die gebräuchlichsten sein (siehe oben).

Nun MySQL ist noch nicht dabei...wäre aber recht schnell machbar...nur im setup wäre arbeit nötig um es komfortabel zu machen....uns ärgert hier die komische lizenz...

Genau das passiert auch so...sogar unsere Händler sind der meinung das wir selbst für Backup,Sicherheit, &c. zuständig sind...nun...Backup während des Betriebs ist tatsächlich jetzt für alle plattformen möglich....man kann es sogar auf einer anderen Plattform und an einem Anderen Server wieder herstellen....so funktioniert es auch als Umzugskarton.....


Hast du Erfahrungen was schlechte Netzwerke und verschiedene DBs angeht?

[neo4a]

Zitat:

Zitat von mkinzler (Beitrag 1157997)

Bitte fangt hier keinen Schlagabtausch auf persönlicher Ebene an.

Einen Schlagabtausch auf unpersönlicher Ebene ist mir persönlich auch nicht so das richtige Niveau, weil man dann ja niemand mehr persönlich trifft und sich auch niemand richtig getroffen fühlt.

[Valle]

Zitat:

Zitat von neo4a (Beitrag 1157985)

(BTW, was kennzeichnet eigentlich ein schlechtes, und ab wann spricht man von einem guten und wann haben wir das "Optimalst-Bestmögliche" Netzwerk?)

Äußerliche Eigenschaften eines guten Netzwerks:

• geringe Latenz
• geringe Übertragungsfehlerrate (hier hängt's!)
• hoher Datendurchsatz
• hohe Ausfallsicherheit (und/oder hier)

Innere Eigenschaften wie optimales Routing (kleinster Preis vs. kürzester Weg) oder tatsächliche Kosten fehlen absichtlich.

Mein Beileid zum Admin des Kunden. Eine Ping Fehlerrate von 75% als normal zu bezeichnen disqualifiziert ihn eigentlich vom Begriff des Administrators.

Liebe Grüße,
Valentin

[tsteinmaurer]

Puh, da ist was los. Ist man mal ein paar Stunden weg ...

@QuickAndDirty: Auf deine mehrfach gestellte Frage:

Zitat:

Hast du Erfahrungen was schlechte Netzwerke und verschiedene DBs angeht?

Nein. Ich verdiene auch nichts dabei Firebird zu verteidigen, außer wenn du bei mir kommerzielle Unterstützung zur zielorientierten Problemlösung (die in einem öffentlichen Forum manchmal schwer ist) suchst. 8-)

Darum wünsch ich dir Alles Gute bei der Problem- und Lösungsfindung, die für dich und deine(n) Kunde(n) letztendlich zufriedenstellend ist. Und das meine ich nicht ironisch! :thumb:

[mkinzler]

Zitat:

Darum wünsch ich dir Alles Gute bei der Problemfindung

. Und natürlich auch der Lösung

[neo4a]

Zitat:

Zitat von Valle (Beitrag 1158023)

Zitat:

Zitat von neo4a (Beitrag 1157985)

(BTW, was kennzeichnet eigentlich ein schlechtes, und ab wann spricht man von einem guten und wann haben wir das "Optimalst-Bestmögliche" Netzwerk?)

Äußerliche Eigenschaften eines guten Netzwerks:
[LIST][*]geringe Latenz

Oha, ich verstehe. ;)

Dann ist dann eine sehr geringe Latenz ja ein Merkmal für ein sehr gutes, und gar keine Latenz bringt mir mein brutalst-mö...

SCNR.

[QuickAndDirty]

Zitat:

Zitat von tsteinmaurer (Beitrag 1158034)

Puh, da ist was los. Ist man mal ein paar Stunden weg ...

@QuickAndDirty: Auf deine mehrfach gestellte Frage:

Zitat:

Hast du Erfahrungen was schlechte Netzwerke und verschiedene DBs angeht?

Nein. Ich verdiene auch nichts dabei Firebird zu verteidigen, außer wenn du bei mir kommerzielle Unterstützung zur zielorientierten Problemlösung (die in einem öffentlichen Forum manchmal schwer ist) suchst. 8-)

Darum wünsch ich dir Alles Gute bei der Problem- und Lösungsfindung, die für dich und deine(n) Kunde(n) letztendlich zufriedenstellend ist. Und das meine ich nicht ironisch! :thumb:

Danke!, vermutlich werden wir uns da selbst rein knien müssen und dem Admin sein Netzwerk konfigurieren/reparieren....am Ende können wir dann unseren Techniker vermutlich nichtmal in Rechnung stellen....

Es wäre so schön wenn sich Leistungserschleichungen dieser Art umgehen lassen würden....

[BUG]

Zitat:

Zitat von QuickAndDirty (Beitrag 1158103)

Es wäre so schön wenn sich Leistungserschleichungen dieser Art umgehen lassen würden....

Theoretisch könnte man Leistungsanforderungen an das Netz mit in die Mindestanforderungen schreiben und zum Vertragsbestandteil machen.

[shmia]

Zitat:

Zitat von QuickAndDirty (Beitrag 1157971)

Bei besagtem Kunden gehen 3 von 4 pings verloren!!!!

So einen Kunden hatte ich auch mal.
Probleme ohne Ende mit der Verbindung zum MS SQL Server.
Ursache war:
der "schlaue" Admin hat in den Server 2 Netzwerkkarten eingebaut.
Die IP-Adressen waren im gleichen Segment.
Dann hat er beide Netzwerkkarten mit dem gleichen Switch verbunden
in der irrigen Annahme seine Netzwerkanbindung wäre jetzt 200MBit statt nur 100MBit. :wall:

[mkinzler]

Und dazu noch ein dummer Switch, der die Loop nicht bemerkt

[IBExpert]

Moin,

hier noch mal einen kleinen Denkanstoß zum eigentlichen Thema.

Wir hatten vor einiger Zeit mal ähnliche Konstellation und haben dann einfach auf
Firbeird basierend einen minimale API realisiert, die nicht anderes ist als eine
Stored procedure, der man den auszuführenden Befehl als Blob übergibt und die dann
ggf sich daraus ergebende Resultsets in einem Blob zurückgibt.

Hier der Quellcode der SP

Code:

create or alter procedure BRPAPI (
    CMD blob sub_type 1 segment size 80)
returns (
    RES blob sub_type 1 segment size 80)
as
declare variable RESLINE blob sub_type 1 segment size 80;
begin
  if (cmd starting with 'SELECT') then
  begin
  res='';
  for execute statement :cmd into :resline
  do res=res||'
'||resline;
  end
  else
  begin
    execute statement :cmd;
    res='EXECUTED';
  end
  suspend;

end

Wie benutzt man die dann? Auch recht simpel, z.B.

Code:

select res from brpapi('SELECT ID||'';''||TXT FROM KUNDE')

Die Antwortmenge wird durch das SQL einfach schon mal als CSV Format vorgegeben, damit müsste dann ggf der Client klar kommen.

Hier für Interessierte ein Protokoll aus dem TCPIPExpert Tool mit dem gesamten TCP/IP Traffic zu einer SQL Abfrage mit Übergabe
der Ergebnismenge (Ausführung war hier mit isql.exe)

Code:

## 18:59:59:136 Channel 1; DATA (Client -> Server): Length= 8
00 00 00 5B 00 00 00 02                             [            

## 18:59:59:435 Channel 1; DATA (Client -> Server): Length= 124
00 00 00 3E 00 00 00 00 00 00 00 44 00 00 00 02     >       D    
FF FF FF FF 00 00 00 03 00 00 00 3A 73 65 6C 65             :sele
63 74 20 72 65 73 20 66 72 6F 6D 20 62 72 70 61  ct res from brpa
70 69 28 27 53 45 4C 45 43 54 20 49 44 7C 7C 27  pi('SELECT ID||'
27 3B 27 27 7C 7C 54 58 54 20 46 52 4F 4D 20 4B  ';''||TXT FROM K
55 4E 44 45 27 29 00 00 00 00 00 19 15 04 07 09  UNDE')          
0B 0C 0D 0E 10 11 12 13 08 05 07 09 0B 0C 0D 0E                  
10 11 12 13 08 00 00 00 FF FF 80 00                              

## 18:59:59:464 Channel 1; DATA (Server -> Client): Length= 156
00 00 00 09 00 00 00 03 00 00 00 00 00 00 00 01                  
00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00                  
00 00 00 09 00 00 00 04 00 00 00 00 00 00 00 00                  
00 00 00 5A 15 04 00 01 00 00 00 04 07 04 00 01     Z            
00 00 00 09 04 00 01 00 00 00 0B 04 00 09 02 00                  
00 0C 04 00 01 00 00 00 0D 04 00 04 00 00 00 0E                  
04 00 08 00 00 00 10 03 00 52 45 53 11 06 00 42           RES   B
52 50 41 50 49 12 06 00 53 59 53 44 42 41 13 03  RPAPI   SYSDBA  
00 52 45 53 08 05 07 04 00 00 00 00 00 01 00 00   RES            
00 00 00 01 00 00 00 00 00 00 00 00                              

## 18:59:59:466 Channel 1; DATA (Client -> Server): Length= 56
00 00 00 3F 00 00 00 03 00 00 00 01 00 00 00 00     ?            
00 00 00 00 00 00 00 00 00 00 00 41 00 00 00 03             A    
00 00 00 0C 05 02 04 00 02 00 09 00 07 00 FF 4C                 L
00 00 00 00 00 00 0A A8                                          

## 18:59:59:496 Channel 1; DATA (Server -> Client): Length= 68
00 00 00 09 00 00 00 01 00 00 00 00 00 00 00 00                  
00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00                  
00 00 00 42 00 00 00 00 00 00 00 01 00 00 00 00     B            
00 00 00 33 00 00 00 00 00 00 00 42 00 00 00 64     3       B   d
00 00 00 00                                                      

## 18:59:59:503 Channel 1; DATA (Client -> Server): Length= 20
00 00 00 38 00 00 00 00 00 00 00 01 00 00 00 00     8            
00 00 00 33                                         3            

## 18:59:59:530 Channel 1; DATA (Server -> Client): Length= 32
00 00 00 09 00 00 00 04 00 00 00 00 00 00 00 01                  
00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00                  

## 18:59:59:532 Channel 1; DATA (Client -> Server): Length= 16
00 00 00 24 00 00 00 04 00 00 40 00 00 00 00 00     $      @     

## 18:59:59:562 Channel 1; DATA (Server -> Client): Length= 216
00 00 00 09 00 00 00 02 00 00 00 00 00 00 00 01                  
00 00 00 B6 A0 00 0D 0A 34 30 30 30 30 30 31 39          40000019
33 37 34 3B 42 61 72 0D 0A 34 30 30 30 30 30 31  374;Bar  4000001
39 34 30 38 3B 47 65 6D 65 69 6E 64 65 20 48 75  9408;Gemeinde Hu
64 65 0D 0A 34 30 30 30 30 30 31 39 36 32 31 3B  de  40000019621;
57 53 0D 0A 34 30 30 30 30 30 31 39 38 30 38 3B  WS  40000019808;
2D 0D 0A 34 30 30 30 30 30 32 30 36 39 33 3B 4B  -  40000020693;K
61 72 73 74 65 6E 20 44 69 65 72 73 20 47 6D 62  arsten Diers Gmb
48 0D 0A 34 30 30 30 30 30 32 33 34 30 36 3B 46  H  40000023406;F
6C 6F 72 65 73 20 41 70 6F 74 68 65 6B 65 0D 0A  lores Apotheke  
34 30 30 30 30 30 32 39 37 35 34 3B 44 52 4B 20  40000029754;DRK 
48 75 64 65 0D 0A 12 00 34 30 30 30 30 30 33 30  Hude    40000030
38 36 31 3B 5A 6F 72 62 61 73 00 00 00 00 00 01  861;Zorbas      
00 00 00 00 00 00 00 00                                          

## 18:59:59:571 Channel 1; DATA (Client -> Server): Length= 36
00 00 00 27 00 00 00 04 00 00 00 5B 00 00 00 01     '       [    
00 00 00 43 00 00 00 03 00 00 00 01 00 00 00 5B     C           [
00 00 00 01                                                      

## 18:59:59:598 Channel 1; DATA (Server -> Client): Length= 32
00 00 00 09 00 00 00 00 00 00 00 00 00 00 00 01                  
00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00

hier noch mal mit anderem SQL

Code:

## 19:00:40:601 Channel 1; DATA (Client -> Server): Length= 144
00 00 00 5B 00 00 00 02 00 00 00 44 00 00 00 02     [       D    
00 00 00 03 00 00 00 03 00 00 00 4F 73 65 6C 65             Osele
63 74 20 72 65 73 20 66 72 6F 6D 20 62 72 70 61  ct res from brpa
70 69 28 27 53 45 4C 45 43 54 20 49 44 7C 7C 27  pi('SELECT ID||'
27 3B 27 27 7C 7C 54 58 54 20 46 52 4F 4D 20 4B  ';''||TXT FROM K
55 4E 44 45 20 57 48 45 52 45 20 49 44 3D 34 30  UNDE WHERE ID=40
30 30 30 30 32 30 36 39 33 27 29 00 00 00 00 19  000020693')     
15 04 07 09 0B 0C 0D 0E 10 11 12 13 08 05 07 09                  
0B 0C 0D 0E 10 11 12 13 08 00 00 00 FF FF 80 00                  

## 19:00:40:631 Channel 1; DATA (Server -> Client): Length= 156
00 00 00 09 00 00 00 03 00 00 00 00 00 00 00 01                  
00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00                  
00 00 00 09 00 00 00 04 00 00 00 00 00 00 00 00                  
00 00 00 5A 15 04 00 01 00 00 00 04 07 04 00 01     Z            
00 00 00 09 04 00 01 00 00 00 0B 04 00 09 02 00                  
00 0C 04 00 01 00 00 00 0D 04 00 04 00 00 00 0E                  
04 00 08 00 00 00 10 03 00 52 45 53 11 06 00 42           RES   B
52 50 41 50 49 12 06 00 53 59 53 44 42 41 13 03  RPAPI   SYSDBA  
00 52 45 53 08 05 07 04 00 00 00 00 00 01 00 00   RES            
00 00 00 01 00 00 00 00 00 00 00 00                              

## 19:00:40:633 Channel 1; DATA (Client -> Server): Length= 56
00 00 00 3F 00 00 00 03 00 00 00 01 00 00 00 00     ?            
00 00 00 00 00 00 00 00 00 00 00 41 00 00 00 03             A    
00 00 00 0C 05 02 04 00 02 00 09 00 07 00 FF 4C                 L
00 00 00 00 00 00 0A A8                                          

## 19:00:40:661 Channel 1; DATA (Server -> Client): Length= 68
00 00 00 09 00 00 00 01 00 00 00 00 00 00 00 00                  
00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00                  
00 00 00 42 00 00 00 00 00 00 00 01 00 00 00 00     B            
00 00 00 3F 00 00 00 00 00 00 00 42 00 00 00 64     ?       B   d
00 00 00 00                                                      

## 19:00:40:669 Channel 1; DATA (Client -> Server): Length= 20
00 00 00 38 00 00 00 00 00 00 00 01 00 00 00 00     8            
00 00 00 3F                                         ?            

## 19:00:40:697 Channel 1; DATA (Server -> Client): Length= 32
00 00 00 09 00 00 00 04 00 00 00 00 00 00 00 01                  
00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00                  

## 19:00:40:698 Channel 1; DATA (Client -> Server): Length= 16
00 00 00 24 00 00 00 04 00 00 40 00 00 00 00 00     $      @     

## 19:00:40:727 Channel 1; DATA (Server -> Client): Length= 68
00 00 00 09 00 00 00 02 00 00 00 00 00 00 00 01                  
00 00 00 24 02 00 0D 0A 1E 00 34 30 30 30 30 30     $      400000
32 30 36 39 33 3B 4B 61 72 73 74 65 6E 20 44 69  20693;Karsten Di
65 72 73 20 47 6D 62 48 00 00 00 01 00 00 00 00  ers GmbH        
00 00 00 00                                                      

## 19:00:40:734 Channel 1; DATA (Client -> Server): Length= 16
00 00 00 27 00 00 00 04 00 00 00 5B 00 00 00 01     '       [    

## 19:00:40:735 Channel 1; DATA (Client -> Server): Length= 20
00 00 00 43 00 00 00 03 00 00 00 01 00 00 00 5B     C           [
00 00 00 01                                                      

## 19:00:40:760 Channel 1; DATA (Server -> Client): Length= 32
00 00 00 09 00 00 00 00 00 00 00 00 00 00 00 01                  
00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00

und hier mal als Update statement

Code:

## 19:01:49:811 Channel 1; DATA (Client -> Server): Length= 156
00 00 00 5B 00 00 00 02 00 00 00 44 00 00 00 02     [       D    
00 00 00 03 00 00 00 03 00 00 00 5A 73 65 6C 65             Zsele
63 74 20 72 65 73 20 66 72 6F 6D 20 62 72 70 61  ct res from brpa
70 69 28 27 55 50 44 41 54 45 20 4B 55 4E 44 45  pi('UPDATE KUNDE
20 53 45 54 20 54 58 54 3D 27 27 4B 41 52 53 54   SET TXT=''KARST
45 4E 20 44 49 45 52 53 20 47 6D 62 48 27 27 20  EN DIERS GmbH'' 
57 48 45 52 45 20 49 44 3D 34 30 30 30 30 30 32  WHERE ID=4000002
30 36 39 33 27 29 00 00 00 00 00 19 15 04 07 09  0693')          
0B 0C 0D 0E 10 11 12 13 08 05 07 09 0B 0C 0D 0E                  
10 11 12 13 08 00 00 00 FF FF 80 00                              

## 19:01:49:907 Channel 1; DATA (Server -> Client): Length= 156
00 00 00 09 00 00 00 03 00 00 00 00 00 00 00 00                  
00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00                  
00 00 00 09 00 00 00 04 00 00 00 00 00 00 00 00                  
00 00 00 5A 15 04 00 01 00 00 00 04 07 04 00 01     Z            
00 00 00 09 04 00 01 00 00 00 0B 04 00 09 02 00                  
00 0C 04 00 01 00 00 00 0D 04 00 04 00 00 00 0E                  
04 00 08 00 00 00 10 03 00 52 45 53 11 06 00 42           RES   B
52 50 41 50 49 12 06 00 53 59 53 44 42 41 13 03  RPAPI   SYSDBA  
00 52 45 53 08 05 07 04 00 00 00 00 00 01 00 00   RES            
00 00 00 01 00 00 00 00 00 00 00 00                              

## 19:01:49:908 Channel 1; DATA (Client -> Server): Length= 56
00 00 00 3F 00 00 00 03 00 00 00 01 00 00 00 00     ?            
00 00 00 00 00 00 00 00 00 00 00 41 00 00 00 03             A    
00 00 00 0C 05 02 04 00 02 00 09 00 07 00 FF 4C                 L
00 00 00 00 00 00 0A A8                                          

## 19:01:49:967 Channel 1; DATA (Server -> Client): Length= 68
00 00 00 09 00 00 00 01 00 00 00 00 00 00 00 00                  
00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00                  
00 00 00 42 00 00 00 00 00 00 00 01 00 00 00 00     B            
00 00 00 80 00 00 00 00 00 00 00 42 00 00 00 64             B   d
00 00 00 00                                                      

## 19:01:49:975 Channel 1; DATA (Client -> Server): Length= 20
00 00 00 38 00 00 00 00 00 00 00 01 00 00 00 00     8            
00 00 00 80                                                      

## 19:01:50:042 Channel 1; DATA (Server -> Client): Length= 32
00 00 00 09 00 00 00 04 00 00 00 00 00 00 00 00                  
00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00                  

## 19:01:50:044 Channel 1; DATA (Client -> Server): Length= 16
00 00 00 24 00 00 00 04 00 00 40 00 00 00 00 00     $      @     

## 19:01:50:087 Channel 1; DATA (Server -> Client): Length= 44
00 00 00 09 00 00 00 02 00 00 00 00 00 00 00 00                  
00 00 00 0A 08 00 45 58 45 43 55 54 45 44 00 00        EXECUTED  
00 00 00 01 00 00 00 00 00 00 00 00                              

## 19:01:50:092 Channel 1; DATA (Client -> Server): Length= 36
00 00 00 27 00 00 00 04 00 00 00 5B 00 00 00 01     '       [    
00 00 00 43 00 00 00 03 00 00 00 01 00 00 00 5B     C           [
00 00 00 01                                                      

## 19:01:50:177 Channel 1; DATA (Server -> Client): Length= 32
00 00 00 09 00 00 00 00 00 00 00 00 00 00 00 00                  
00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00

Du siehst das jeder Befehl ca. 10 Datenpaket generiert, 5 vom client zum Server und 5 vom Server zum Client.

Wenn du dir eine geeignete clientseitige API aufbaust, die dann eben mit der Serverapi klar kommt, dann
hast du den Vorteil, auch aus langsamen Netzen alles rausholen zu können und verzichtest trotzdem nicht
auf die ganzen Firebird Möglichkeiten.

wenn du den ganzen Dataset schnickschnack mit im Grid editieren usw. haben willst, dann ist das
ziemlich aufwändig, eine eigene Middleware auf der o.a. Technik aufzusetzen, aber das werden dir
auch andere Datenbanken kaum schneller liefern können.

Gruß

Holger