WANTED: DB für schlechte Netzwerke

[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 von tsteinmaurer:

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 von 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?

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 von neo4a:

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 von QuickAndDirty:

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 von neo4a:

Zitat von QuickAndDirty:

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 von neo4a:

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 von neo4a:

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 von neo4a:

- 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