Welche Datenbank ist die richtige?

[Jan]

Hallo,

aufgerüttelt durch die Diskussion vergangenen Samstag in der XUG Osnabrück und durch eine positive Bemerkung meines Chefs (endlich!!! Er spielt mit dem Gedanken, von Access auf Xbase++ umzusteigen) tun sich für mich viele, viele Fragen auf.

Ist-Situation: Netzwerk mit 2 Linux-Servern (Samba und Gateway). 20 Clients mit Win 2000 Pro bzw. XP. Nicht auf allen Clients wird ständig und erst recht nicht sehr intensiv gearbeitet, das machen nur etwa 6 oder 7 Clients gleichzeitig. Netzwerk ist 100 MBit.

Aufgebohrt wäre da noch eine Niederlassung mit 2 Clients. Tunnel ist in Arbeit. Schön wäre es, wenn Außendienstler ab und an mit ihren Notebooks oder ich von zu Hause auf die Datenbanken zugreifen könnten, mindestens lesend, besser auch schreibend.

Und die Kür wäre es, wenn registrierte Fachhandelspartner irgendwann mal ihre Bestellungen direkt in unser System hacken könnten, inkl. Statusabfrage der Aufträge.

Also viel zu tun. Nicht alles auf mal, aber schon mal einplanen.

Datenübernahme aus dem Access-System, bislang ca. 360 MB Daten mit ca. 50 MB jährlichem Wachstum, wäre sicher möglich. Und die Strukturen werden sicher angepasst werden müssen. Ich habe da schon vieles von meinen Vorgängern zusammengestrichen (warum ist der Brutto-Auftragswert 5 Mal! im gleichen Datensatz gespeichert???). Aber es ist noch einiges machbar und notwendig.

Was würdet Ihr machen? ADS? "Richtige" SQL? Webinterface? Tunnel?

Bislang habe ich ausschließlich Erfahrung mit lokalen dbf. Ich bin also Dankbar für jeden Hinweis und Tip.

Jan

[Martin Altmann]

Hallo Jan,
Glückwunsch!
Wenn ich das Anforderungsprofil so lese, dann würde ich denken, dass ein SQL-Server (z.B. MySQL) dafür am Besten geeignet wäre.
Und als Frontend für die Fachhandelspartner ein Webfrontend (wozu extra Clients für die Kunden programmieren und verteilen, wenn sie über stinknormale Webbrowser zugreifen können?)!

Viele Grüße,
Martin

[Manfred]

Hi Martin,

willst Du das dann über PHP lösen wollen?

[Martin Altmann]

Nee,
mit Xb2.NET latürnich!
Wir sind doch hier im IdXF++

Viele Grüße,
Martin

[Manfred]

Hi Martin,

stimmt, hast Recht. Ich habe falsch gedacht.

[Martin Altmann]

Manfred,
nimm's nicht so tragisch
Klar könnte man so was sicherlich auch mit php ganz gut erledigen. Aber dann bräuchte man auch einen Webserver, der natürlich auch wieder angreifbar ist.
Und bei XB2.NET ist alles aus einem Guß.

Viele Grüße,
Martin

[brandelh]

Hi,

was machen die Linux Server ?
Reine Fileserver, Dateien zur Verfügung stellen ?

Hier schreibe ich mal meine Erfahrungen so nieder.

1. Grundsätzlich kann man alles mit DBFs machen, insbesondere wenn nur wenige Mitarbeiter tatsächlich aktiv reinschreiben. Wir nutzen DBFCDX, da dieses 1. stabiler sein soll, 2. tatsächlich kleinere und bessere Indexdateien hat. Die 4 Anwendungen werden von je 10 bis 30 Anwendern mehr oder minder häufig aufgerufen, wobei die Datein auf einem Netzwerklaufwerk und die Anwendungen auf 3 Citrix-Servern laufen.
DBFs haben den Vorteil, dass man sich gut mit ihnen auskennt und Satzsperren etc. wie gewohnt verabeiten kann.
Allerdings sind die dauernd offenen Indexdateien der größte Schwachpunkt. Jede Anwendung die abschmiert kann einen Fehler in Inde x oder DBF hinterlassen ...

2. Mit SQLExpress habe ich Daten aus Access Dateien herausgeholt und für eine Migration umgewandelt. Das war wirklich einfach. Wenn also SQL, dann mit SQLExpress.

3. Der größte Nachteil der DBF / CDX Dateien sind ihre offenen Netzverbindungen ohne Recovery Mechanismen. Bei unbestimmten Suchen (ohne gute/stark einschränkende Indexbegriffe) wird es im Netzwerk langsam, auch wenn ein 100Mbit Netz mit SWITCHes nicht so empfindlich ist wie ein altes mit HUBs. Und keine Datei kann mehr als 2 GB werden, was teilweise zum Problem wird.
Ein weiterer ist der schlechte Ruf von dBase (obwohl es wirklich gut war), es gilt als total veraltet.

4. Persönlich habe ich (gute) Erfahrungen mit MySQL, wobei ich dieses bei einem WebFrontend mit PowerBasic nutze. Phil IDE berichtete aber von Problemen wenn man mehr will und schlägt statt dessen Postgres vor, zudem er auch eine eigene Zugriffsklasse ohne ODBC geschrieben hat (sollte eigenlich deutlich schneller sein). Damit habe ich aber keine Erfahrungen. MySQL ist im internen Firmennetz nicht unbedingt kostenlos, damit habe ich mich aber nicht beschäftigt. MySQL könnte auf einem Linux-Server laufen.

Auch MS SQL Server kann man gut mit SQLExpress ansprechen, weitergehende Ansprüche (stored procedures, recover etc.) habe ich aber nicht gehabt und kann dazu nichts sagen. Die Verwaltungstools bei den kostenpfichtigen Versionen sind sicher ausgereifter als bei MySQL, die aber deutlich aufgeholt haben.

5. Ein SQL Server nimmt dir im Programm viel ab, von Access wirst du sicher etwas SQL können, suchen sortieren interne Strukturen überwachen, um all das must du dich in Xbase nicht mehr kümmern.

Allerdings muss man umdenken, man hat normalerweise KEINE Satznummer, man braucht also ein Feld mit eindeutigem Schlüssel. Man kann nicht mal eben einen Satz sperren und direkt bearbeiten. Man muß SQL Statements ähnlich dem UPDATE Befehl verwenden.
Aber man hat aus diesen Gründen auch keine Probleme mit select Bereichen. Ein Zugriff geht nur über die Verwaltungsobjekte, die SQL Statements weiterliefern.

Der Außendienst könnte leicht über ein WEB-Frontend angebunden werden, solange Ihr eine vernünftige DSL-Leitung bekommt (6000/512 Mbit - hauptsächlich upload ! )
Keinesfalls darf man dabei die SQL Datenbank direkt ins Internet hängen und man braucht eine saubere Hardwarefirewall. Auf dem Server kann man dann aber auch ein eigenes Zertifikat erstellen, und bei der ersten Warnung den Zugriff erlauben - so mache ich es auf meinem Testserver.
LoadFromURL geht dann aber nicht, da er die Unterschiede erkennt und nicht toleriert. Steht die SSL Verbindung, ist diese zumindest sicher. Daten anzeigen und Ändern sind kein Problem.
Hier bevorzuge ich Apache mit reinen CGI-Xbase++EXE.
Martin macht das mit Xb2.NET und Alaska rät zum WAA.
Hat alles vor und Nachteile. Der WAA ist bei intensivem Datenverkehr (ab etwa 20 gleichzeitig angemeldeten Anwendern) schneller, da die DLL immer im RAM bleibt und nur Daten je User benötigt werden.
Xb2.NET bietet wohl die weitestgehende Integration, da es als Programm dauernd läuft.

Ich halte aber folgende Punkte für nachteilig:
1. TCPIP Stack muß selbst verwaltet werden, werden hier Fehler gemacht sind es die EIGENEN !
2. Wer kennt schon einen 100% sicheren TCPIP Code - ich nicht.
3. SSL Verschlüsselung kostet extra !
4. Die Versionen sind von der Xbase++ Version abhängig und werden nur im ersten Jahr ausgetauscht (ich meine nicht erweitert). Dies ist zwar bei SQLExpress das gleiche, aber da hat man aus meiner Sicht keine Alternative.
5. Eine Xb2.NET Anwendung blockiert den Port komplett. Entweder man weicht dann auf andere aus (nicht immer freigegeben) oder man muß in der einen EXE alle Anwendungen unterbringen.

Ich bevorzuge CGI, da
1. Der Apache (oder andere WebServer) sind Standard und hinreichend getestet. Ein Fehler in diesem wird nie dem Programmierer einer CGI Anwendung angelastet.
2. SSL inklusive (natürlich kein öffentliches Zertifikat)
3. CGI-Programme sind sehr einfach !
STDIN -> Programmlogik -> STDOUT
Nichts als Texte verschieben.
Keine TCPIP Funktionen, kein Asinet etc. nötig.
4. CGI-Programme sind nur kurz im Speicher, die EXE kann jederzeit locker ersetzt werden.
5. der Apache schützt das CGI und ruft dieses auf, ich muss als keine Angst haben, dass mein abstürzendes Programm den WEB-Server außer Funtion setzt. Wenn Apache aussteigt, geht das mich nichts an.
6. der Apache ist nicht schwer beim Aufsetzen.
7. Ein Apache kann unendlich viele (na ja die Namen müssen eindeutig sein CGI Programme gleichzeitig anbieten und bedienen.
8. Man bekommt Windows Apaches mit SSL Unterstützung auch fertig kompiliert.

> Und die Kür wäre es, wenn registrierte Fachhandelspartner irgendwann mal ihre
> Bestellungen direkt in unser System hacken könnten, inkl. Statusabfrage der Aufträge.

Das ist alles kein Problem, solange Ihr den WEB-Server selbst betreiben könnt. Denn dann kann mein einen geregelten (keinen gehackten ) Zugang schaffen auf euren Datenbankserver.
Falls Ihr eine feste IP-Adresse besorgen könnt ist sogar ein günstiges (100 Euro pro Jahr) SSL Zertifikat möglich, auch wenn einige die Verschlüsselte Datenübertragung nicht für nötig erachten

[brandelh]

willst Du das dann über PHP lösen wollen?

PHP ist die Standardprogrammiersprache fürs WEB.
Jeder gute PHP Programmierer macht die Webanbindung an einen Web-Server im Handumdrehen.

ABER:
1. PHP ist ein Interpreter, der von vielen nach Fehlern durchleuchtet wird und man findet auch immer wieder jede Menge gefährliche Löcher darin.
2. Die meisten Fehler machen dennoch immer noch die nicht ganz so guten PHP Programmierer, weil einfache aber wichtige Dinge (z.B. Parameterüberprüfung) vergessen werden.
3. Dann übergibt man noch einfach ein Suchfeld als SQL Statement an MySQL und der SQL Hack ist freigeschaltet
4. Wer ist hier heute ein richtig guter PHP Programmierer ? (Ich bin NICHT mal ein schlechter).
5. Wie lange braucht man um so gut zu werden, dass man sich traut die Daten seiner Firma hinter einem eigenen PHP Programm zu verstecken ?

Ich habe mich gegen PHP entschieden, wobei man dann auf eigene Server (hinter DSL oder beim Provider) angewiesen ist, da normalerweise kein WWW-Hoster EXE CGI Dateien erlaubt. Xb2.NET braucht sowieso eine Windowsmaschine, bei der man den eigentlichen Server abschalten kann.

Grundsätzlich muß man aber betonen, dass Xbase++ (ähnlich wie PowerBasic) zwar vom Prinzip her sicherer ist, da mit der dynamischen Speicher und Stringverwaltung das Problem der Speicherüberläufe nicht auftreten kann, aber ein Fehler in der Programmlogik und man hat ein Scheunentor für Angreifer geschaffen. Allerdings müssen die sich dann mit absolut untypischen EXEs herumschlagen.

[Martin Altmann]

Hallo Hubert,
einige (kleinere) Anmerkungen zu Deinen beiden sehr ausführlichen Postings - wenngleich sie auch allgemeinerer Natur und für Jan nicht hilfreich/nötig sind:
Bei Hosteurope kann man einen VServer auch unter Windows mieten, den IIS kann man dann entsprechend abschalten und ein MySQL-Server ist auch installiert - genauso wie ein Mailserver und Perl. Auf diesem VServer habe ich zwei XB2.NET-Anwendung am laufen, die über insgesamt vier Ports erreichbar sind. Die IP ist statisch und ein SSL-Zertifikat kann man auch bekommen.

Viele Grüße,
Martin

[brandelh]

Aber dann bräuchte man auch einen Webserver, der natürlich auch wieder angreifbar ist.
Und bei XB2.NET ist alles aus einem Guß.

Da werden Martin und ich uns wohl nie einig sein

Dies hat aber - aus meiner Sicht - gute Gründe:

1. Ich fand Xb2.Net in seinen Beispielen nicht so einfach und schon gar nicht um mal so schnell einen TCPIP/WEB-SERVER aufzubauen der auch DoS Attacken übersteht. Möglich dass Martin hier mehr Zeit investiert hat, oder sich scheute sich mal den Apache anzusehen. So schwierig ist der gar nicht.

2. Ich habe für den dienstlichen Bereich keinerlei Verwendung für WEB-Technik, das ist bei mir nur Hobby, daher ist mir Xb2.NET einfach zu teuer. Martin hat sicher seine Gründe Xb2.NET zu kaufen
Ich nutze daher auch meist PowerBasic, die EXE sind kleiner.

3. Statische Webseiten möchte ich als normale HTML mit CSS auf dem Server - auch verschlüsselt mit Zertifikat - ablegen, um diese schnell per Texteditor ohne compilieren zu müssen abzuändern. Vielleicht kann man ja auch mal was verkaufen

4. Nur was wirklich dynamisch ist erledige ich mit CGI-EXE Dateien, für jedes Programm eine EXE, da ist der Quellcode noch einigermaßen übersichtlich. Alle EXE liegen im CGI Verzeichnis, dem Apache ist es egal wieviele CGI-Programme er gleichzeitig bedient. Ein Xb2.NET Programm braucht einen PORT (meist 80) und somit blockiert ein Programm den Standard-Port. Für Martin ist das offensichtlich keine Problem, für mich schon

5. In meinen CGI Programmen bin ich für Programmfehler verantwortlich, aber nicht für die des Apache. Nach meinen Erfahrungen übertreibt Boris mit der Aussage was alles bei einem Apache schief gehen kann.

6. CGI Programme werden über STDIN mit Daten versorgt, können auf einer Maschine überall zugreifen (es sei den der Admin hat es verboten) und manipulieren Strings und Daten. Als Ergebnis geben sie eine HTML Seite oder Datei an STDOUT weiter. Um SSL muß man sich nicht kümmern, das macht der Apache !
DAS ist einfache Programmierung !!!

7. Jeder ist anders, programmiert anders und hat andere Probleme.

Daher kann ich nur empfehlen schaut euch Xb2.NET an, wenn ihr denkt es könnte euch bei einem Problem nützlich sein kauft es und Martin kann und wird sicherlich Hilfestellung liefern.

Wenn ihr es lieber mit CGI probieren wollt fragt und euch wird geholfen werden Wenn gar nicht weiter geht, meldet euch per PN.

Meine Erfahrungen

Ich habe seit etwa 2 Jahren auf einem Celeron 1300 mit Win2000 neben Videorecorder und Fileserver (standard) auch einen Apache, MySQL und meine CGI Programme laufen. Mit DSL 6000/512 habe ich Test (PC -> WEB -> Server -> CGI -> WEB -> PC) gefahren. Mit PowerBasic konnten je Sekunde 5 gleichzeitige CGI Programme gestartet werden, die die Daten von MySQL abriefen und zurücklieferten. Dann war der Prozessor aber auch schon recht beansprucht. Mit meiner neuen DSL 16000/1024 ist die Reaktonszeit deutlich schneller geworden (doppelter upload für Antwort).
Xbase++ Programme brauchen zwar mehr Speicher (4MB inkl. DLL) aber die Daten aus den DBF waren schneller als der Weg über ODBC zu MySQL. Die Antwortzeiten (WEB Anfrage absetzen -> Ergebnisse anzeigen) liegen meist zwischen 0,3 bis 0,5 Sekunden.
Somit sollten 300 Aufträge pro Minute kein Problem darstellen.
Das wären immerhin 18000 in jeder Stunde ...

Mit aktueller dedizierter Hardware (Athlon 64 3000+ ff, keine Virtual Server) und DSL 16000/1024 sollten locker die doppelten Werte möglich sein.

[brandelh]

- wenngleich sie auch allgemeinerer Natur und für Jan nicht hilfreich/nötig sind:

meinst du damit meine ausführlichen Postings, oder deine Anmerkungen (war nur ein Scherz, aber ich konnte nicht wiederstehen )

Hosteurope und 1und1 (wobei du mit dem Service nicht zufrieden warst) bieten schöne Server an, aber ich würde meine Daten nicht auf einen öffentliche Server legen und womöglich noch über SQL-TCPIP auf den freigegebenen SQL-Server zugreifen. Außerdem trenne ich strickt die internen von den WEB Programmen.

Nichts geht über eine gespiegelte Festplatte, bei der man mal eben schnell selbst die defekte erneuert und alle sparen am Personal auch die Provider.
Die VServer sind natürlich auch nur dann eine Alternative, wenn die Daten und Zugriffe nicht gerade üppig sind. Schließlich teilt man sich die Maschine.

[Martin Altmann]

Hallo Hubert,
geh' mal langsam in das Bett - Du mußt morgen in Berlin frisch sein!

Da werden Martin und ich uns wohl nie einig sein

Ist doch auch gut so - wäre doch sonst auch ziemlich langweilig hier im Forum wenn alle einer Meinung wären bzw. alle alles auf die gleiche Art und Weise erledigen würden, oder

1. Ich fand Xb2.Net in seinen Beispielen nicht so einfach und schon gar nicht um mal so schnell einen TCPIP/WEB-SERVER aufzubauen der auch DoS Attacken übersteht. Möglich dass Martin hier mehr Zeit investiert hat, oder sich scheute sich mal den Apache anzusehen. So schwierig ist der gar nicht.

So viel Zeit brauchte ich gar nicht investieren - zum Glück!
Und vor Xb2.NET habe ich den WAA in Verbindung mit dem Apache genutzt. Letzteren habe ich (und tue es immer noch) immer dem IIS vorgezogen - aus Sicherheitsgründen.
Aber noch sicherer ist halt ein eigener (in XB2.NET) gestrickter Webserver, da so gut wie alle Hacks ins Leere laufen (bei mir ist zumindest noch keiner erfolgreich gewesen und es wird des öfteren versucht!)

2. Ich habe für den dienstlichen Bereich keinerlei Verwendung für WEB-Technik, das ist bei mir nur Hobby, daher ist mir Xb2.NET einfach zu teuer. Martin hat sicher seine Gründe Xb2.NET zu kaufen

Ich habe im dienstlichen Bereich generell überhaupt keine Verwendung für Xbase++ (leider ) und betreibe das ganze (im Prinzip) auch nur als Hobby.

Alle EXE liegen im CGI Verzeichnis, dem Apache ist es egal wieviele CGI-Programme er gleichzeitig bedient. Ein Xb2.NET Programm braucht einen PORT (meist 80) und somit blockiert ein Programm den Standard-Port. Für Martin ist das offensichtlich keine Problem, für mich schon

Das geht auch mit XB2.NET ohne Probleme! Du hast einen Server, der über Port 80 erreichbar ist. Dieser Server servt 10 verschiedene "Programme", die über ihre einzelnen Adressen aufgerufen werden:

Code: Alles auswählen

http://www.meinserver.de/programm1
http://www.meinserver.de/programm2
...
http://www.meinserver.de/programm10

Nun sieht das vielleicht nicht unbedingt schön aus und wen das stört, der kann sich entsprechende forwarder (Stichwort NAT) einrichten.

Daher kann ich nur empfehlen schaut euch Xb2.NET an, wenn ihr denkt es könnte euch bei einem Problem nützlich sein kauft es und Martin kann und wird sicherlich Hilfestellung liefern.

Wenn ihr es lieber mit CGI probieren wollt fragt und euch wird geholfen werden

Dem habe ich nichts hinzuzufügen

Viele Grüße,
Martin

[Martin Altmann]

Hallo Hubert,

- wenngleich sie auch allgemeinerer Natur und für Jan nicht hilfreich/nötig sind:

meinst du damit meine ausführlichen Postings, oder deine Anmerkungen (war nur ein Scherz, aber ich konnte nicht wiederstehen )

Ich meinte natürlich meine Anmerkungen.
Was das Teilen anbelangt: ich hatte in den letzten 40 Stunden 3.381 Zugriffe auf meinen VServer.
Ich teile mir die Maschine zwar mit 13 anderen (habe die kleinst-mögliche Konfiguration genommen - bei größeren sind es entsprechend weniger auf einem Hardwarenode). Die Maschine hängt mit 100 MBit im Internet - teile das durch 14 und Du weißt, was ich habe. Und zwar in beide Richtungen, also auch Uploadrate!
Und das macht sich wirklich bemerkbar, da kam mein DSL zu Hause nicht hinterher...

Viele Grüße,
Martin

[brandelh]

Die Maschine hängt mit 100 MBit im Internet

du meinst wirklich, dass die eine 100 MBit Anbindung pro Rechner haben ?
Ich denke eher an 100MBit Standard Ethernetanschluß an den Switch, der seinerseits alle Server mit xxxMbit in den Backbone jagt.

Aber auf jeden Fall kann hier eine DSL Leitung nicht mithalten.
Nur braucht man im Normalfall solche Leitungen wenn man WEB-Seiten mit Infos über Kunden etc. anzeigt ?

Jetzt muß ich aber wirklich ins Bett, sonst wird es morgen wirklich hart.

[Jan]

Moin Martin und Hubert,

erstmal Danke für die ausführliche Diskussion. Das hilft schon mal ein gutes Stück weiter.

Da ich im Gegensatz zu Euch beiden versucht habe, für heute Nachmittag ausgeruht zu sein (ich kann schließlich nicht auf der Fahrt nach Berlin schlafen wie Hubert ) klinke ich mich erst jetzt ein.

Aber um eines richtig zu stellen, und um eine der ersten Fragen von Hubert zu beantworten: Wir haben 2 Linux-Server: Das Gateway mit Firewall für externen Verkehr (DSL), und einen Samba-Server für Datenhaltung. Auf den Dingern laufen 2 Virenscanner (1 für externen Verkehr, 1 für internen, auf den Clients laufen keine Scanner) sowie ein Spamfilter.

Früher liefen KHK und unser Access-Programm auf einem 3. Server mit Windows. Nachdem aber KHK auch eine Peer-to-Peer-Verbindung bei bis zu 3 Usern (Chef und Buchhalterin sind die einzigen, die das nutzen) zulässt und wir von Access 97 auf XP umgestiegen sind, haben wir auch diese beiden Daten auf dem Linuxserver, der Windows-Server ist rausgeflogen. Mein Chef möchte da nichts dran ändern! Ich bin also darauf angewiesen, die Datenbanken auf dem Linux-Server abzulegen.

Außerdem ist mein Chef sicher nicht gewillt, tausende von € für eine teure SQL auszugeben, inkl. der dazu notwendigen Schulungen. Ich arbeite zwar gerade nicht unwesentlich für eine von Larry Ellisons Privatbehausungen, aber er wird mir deswegen trotzdem keine Datenank umsonst geben Von daher wären also z. B. dbf oder MySQL sicher gut, ADS könnte ich mir vielleicht noch vorstellen, wenn ich die Vorteile meinem Chef gut verkaufen kann. Allerdings hat keiner von Euch die vorgeschlagen. Warum eigentlich nicht?

Jan

[Martin Altmann]

Hubert,
hatte ich vorhin noch vergessen, darum nur der Vollständigkeit halber: Wenn man XB2.NET kauft (und das gilt - glaube ich - auch für SQLExpress), erhält man ein Jahr Support dazu. Dieser umfasst auch kostenfreie Updates.
Sobald ein Jahr um ist, kann man immer um ein weiteres Jahr verlängern - also ein Subskriptionsmodell analog zu Alaska.
Dies würde ich jedem raten - nicht nur, um Boris zu unterstützen, sondern auch, um halt immer die neuen Versionen zu bekommen.
Ich denke mal, Steffen (schubi) hier im Forum würde das selbe sagen, wenn es um SQLExpress ginge.

Viele Grüße,
Martin

[brandelh]

Dies würde ich jedem raten - nicht nur, um Boris zu unterstützen, sondern auch, um halt immer die neuen Versionen zu bekommen.

Wir haben eine(n) SQLExpress Supportvertrag auf dieser Basis und wenn wir Xb2.NET brauchen würden, hätten wir auch einen solchen.

[brandelh]

ADS könnte ich mir vielleicht noch vorstellen, wenn ich die Vorteile meinem Chef gut verkaufen kann.
Allerdings hat keiner von Euch die vorgeschlagen. Warum eigentlich nicht?

Ich hatte bisher noch nie Probleme mit DBF bei uns und seit wir Citrix-Server haben ist die Performance unabhängig von der Leitung der Außenstelle gut. Je Programm haben wir wahrscheinlich aber weniger als 15 Anwender gleichzeitig. Weiterhin habe ich damals (als wir nur ISDN Leitungen für die Außenstelle hatten) die neuen GUI-Programme so ausgelegt, dass beim Laden alle Daten eines Falles in Variablen gelesen, dann bearbeitet und später geschrieben werden. Das Bearbeiten dauert sicher zwischen 5 und 10 Minuten pro Fall. Nach dem Lesen schließe ich alle Dateien und öffne sie später wieder zum Schreiben. Dieses Verhalten minimiert die Gefahren enorm. Diese Trennung würde übrigens einen Wechsel zu SQL zum Kinderspiel machen.

SQL oder ADS Server könnte ich bei uns politisch nicht durchsetzen.

Über die Vorteile des ADS kann dir sicher TOM etwas sagen, für uns stellte sich das Problem nie.
Die SQL Server sind aber halt auch Produkte die schon lange existieren und auch sicher noch lange existieren werden.
Solange man Standard-SQL und ODBC nutzt, ist einer auch relativ leicht gegen einen anderen auszutauschen.

Mit MySQL und MS-SQL habe ich experimentiert, da einige Dateien eines speziellen Projektes die 2. GB Grenze der DBF in etwa 1 Jahr sprengen werden. Für diesen speziellen Fall (viele Daten werden von einer Station zur Auswertung vorbereitet und danach Satzweise abgearbeitet) war MySQL durch spezielle Syntaxerweiterungen besser als MS-SQL, aber am besten ist es bei DBF zu bleiben, wenn die 2 GB Begrenzung endlich wegfällt.
Phil IDE berichtete aber von Problemen bei massivem konkurierenden Einsatz und bevorzugt PostGresSQL (er hat hierfür auch einen schnelleren Treiber der ODBC umgeht).

Solche Scenarien habe ich nie geprüft !

Mein PowerBasic CGI-Programm bedient eine MySQL DB ohne Probleme, aber die Datenmengen und Anfragen (schreiben darf sowieso nur ich) sind viel zu gering um hier Antworten zu geben. Beide sind soweit ich weiß für Linux zu haben, Postgres sogar völlig kostenlos auch im Betrieb. Bei MySQL bin ich mir nicht sicher ob es bei kommerzieller Nutzung eigener Programme im eigenen Betrieb auch kostenlos ist.
Du würdest in diesem Falle also keinen Windowsserver benötigen, solange die Anfragen an den SQL Server noch so nebenbei von den anderen erledigt werden könnten.

Vor der Umstellung würde ich an deiner Stelle aber Testversionen installieren, von MS-SQL gibt es jetzt auch eine eingeschränkte kostenlose Version. Dort Tabellen erstellen, die in etwa dein Geschäftsmodell abdecken (hautsache die Abhängigkeiten und ein bischen Füllmaterial damit es nicht zu einfach wird). Mit SQLExpress und wenn du die Prof.Sub. hast auch mit der ODBCdbe Testprogramme erstellen (eventuell auch mit Phils Treiber) und mit mehreren Threads je Rechner und mehreren Rechnern typische Abläufe automatisiert durchführen.

Hierdurch wirst du sicher erfahren welches Produkt für euch am Besten ist.

[Jan]

Hubert,

dbf wäre natürlich ein großer Vorteil für uns. Und wenn es bei Euch läuft kann es auch sooooo schlimm nicht sein. Auch bei uns sind eigentlich ständig lediglich 10-15 Clients mit den Datenbanken verbunden. Die aber nicht immer aktiv arbeiten. Wenn gerade kein Kunde da ist sind die sozusagen im Leerlauf.

Aber wie ist das mit Tunneln? Und den Index-Problemen, die auftreten (sollen)? Gibt es bestimmte Sachen, auf die ich besonders achten muß?

Im Moment ist es so, daß Auftragsdaten, die bearbeitet werden, in eine lokale dbf auf dem Client gespeichert und nur da bearbeitet werden. Auf dem Server werden die Positionsdatensätz des Auftrages sogar gelöscht wärend der Bearbeitung (das hat mein Vor-Vorgänger mal so eingebaut). Und der Kopfdatensatz wird manuell über ein logisches Feld gesperrt, so daß niemand anderes darauf zugreifen kann, nicht einmal lesend. Dazu gespeichert werfen Rechnername und User, um festzustellen wer denn da dran arbeitet.

Was ich festgestellt habe ist, daß dbf wesentlich größer sind als mdb von Access. Ich hatte mal vor einiger Zeit probehalber mit der Umstellung begonnen, dafür die 4 oder 5 wichtigsten Tabellen in dbf exportiert. Da kommt schon einiges zusammen. Nun, Platz ist genug auf dem Samba-Server. Aber es ist schon auffällig. Ich vermute mal, das in einer mdb nicht benötigte Feldlängen auch nicht "vorgehalten" werden wie in einer dbf.

Jan

[Rudolf]

Hallo Leute,
habe in den letzten Jahren einiges ausprobiert und teilweise relativ komplexe Programme damit geschrieben. Dazu gehört MS-SQL, MySQL, DBF's, eine eigene SSL Variante mit XB2Net und MS-SQL (es werden SQL-Datasets über eine sichere SSL Verbindung übertragen), XB2Net und XBase++ als CGI's. Die besten Erfahrungen habe ich mit DBF/CDX und Windows Terminal Server gemacht. Habe gerade einen Kunden umgestellt und bin begeistert. Alles läuft super schnell, die Userverwaltung ist sehr einfalch, ich habe Fernzugriff auf das ganze System und kann dem Kunden online Hilfe geben. Dazu steht ein eigener Server für den Terminalserver und ein zentraler Server beim Kunden. Läuft schneller als bei mir lokal.
SQL Programmierung kann ziemlich komplex werden, vor allem bei diversen Feinheiten wie stored procedures, constraints etc. Da kommen Fehlermeldungen vom Server die einem zur Verzweiflung bringen. Hab noch kein System gefunden, wie ich diese Fehlermeldungen dann in ein vernünftiges Recovery bringe, sind bei jedem SQL anders. Habe mein letztes SQL Projekt daher abgebrochen, da ich zusehr abhängig vom Server und vom SQL bin.
XB2Net ist genial, habe mich eine Zeit damit befasst und alle kleinen Probleme überwunden. Läuft total schnell und sicher. Vor allem wenn man das ganze mit xbscript kombiniert. Arbeite jetzt daran DynApi einzubinden und eine ander Java Library die super mit Fenstern umgehen kann. Wenn ich die Dinger eingebunden habe, denke ich habe ich die perfekte Lösung für mich für Webprogrammierung gefunden. Und der Support von Boris ist hervorragend.
Werde demnächst noch mit ADS experimentieren, ist mir lieber als SQL.
Also meine Favoriten sind für Weblösungen XB2Net und für Netzwerklösungen mit vielen Usern und Internetanbindung der Windows Terminal Server (ev. in Verbindung mit einem LINUX Server)
Wenn jemand Infos über SQL Programmierung oder XB2Net braucht, kann er mich gerne kontaktieren, habe ein paar praktische Tools dazu geschrieben die ich euch gerne zur Verfügung stelle.
Grüsse
Rudolf

[brandelh]

Hi Jan,

Aber wie ist das mit Tunneln? Und den Index-Problemen, die auftreten (sollen)? Gibt es bestimmte Sachen, auf die ich besonders achten muß?

wir haben feste Standleitungen in die Außenbezirke, also nicht über das Internet. Dennoch kommt es vor, dass z.B. ein Bagger die Leitung zerreist (2x in 15 Jahren). Bei einer getunnelten VPN über Internet Lösung weiß ich jetzt nicht wie ausfallsicher die ist, aber ich würde da eher keine DBF und Indexdatei drüber öffnen. Auch das Löschen von Daten im Server und dann lokal bearbeiten und zurückladen, erscheint mir fehlerträchtig. Hier ist es besser entweder auf die erwähnten Terminalserver zu gehen (wenige definierte Clients - eigene Rechner) wobei natürlich dafür ein richtiger Windowsserver benötigt wird, da die Workstation das Programm nicht dabei hat. Für dich als Programmierer ist der Terminalserver nahezu transparent. Wenn man allerdings auch Kunden definierten Zugriff auf die Daten geben will ist ein WEB-Frontend besser, da jeder über Internet ohne weitere Hardwarevoraussetzungen oder Einstellungen (SSL Verschlüsselung sollte auf dem Server schon sein ! ) darauf zugreifen kann. Allerdings kann ein Web-Frontend nicht so nett gemacht werden wie eine GUI Exe (Lookuptables, sofortige Feldinhaltskontrolle etc.) oder man muß mit JavaScript zaubern, was aber aus Sicherheitsgründen abgeschaltet bleiben sollte. Auch hier braucht man natürlich einen Windowsrechner, der die Xb2.NET oder CGI Programme ausführt, dies kann auch eine Workstation sein.
Bei eurer Gößenordnung sollte ein lokaler Server (Hardware eher unwichtig, 3 GHZ sind immer schnell genug, 2x400 GB Festplatten gespiegelt oder die vom Linuxserver zuordnen (da habt ihr doch gespiegelte Platten oder ??? ) beides abhandeln können.

Was die Größe der DBF betrifft, so ist es richtig, dass ein 100 Byte Datensatz immer 101 Byte (+Deleted Flag) hat, deshalb ist ja der GoTo Befehl so schnell goto(100) -> Header + 99* RecLen + 1 und ich der Rechner ist auf dem gewünschten Satz. Jeder der das anders macht muß irgendwie zwischenspeichern wo welcher Satz anfängt und wenn dann 1 Byte dazukommt ... im Übrigen sperrt DBF genau einen Satz, MDB ein 4KByte Segment ... im Netz sind DBF wesentlich schneller als gesharte MDBs, besonders wenn man der MDB noch die Indexe und das Programm einverleibt hat .

Wenn man viele leere Felder hat und einem das stört, kann man auch die nur selten benutzten Felder in eine eigene DBF auslagern und über Index verbinden.

[Gerd König]

Hallo Jan,

wir verwenden DBFNTX, haben ca. 150 Clients im Netzwerk, diese führen u.a. täglich ca. 3000 bis 6000 Materialbuchungen aus, wobei jede Buchung mindestens 2, meistens 4-6, Schreibvorgänge zur Folge hat (Update oder/und Append).

Bei der Menge der Lesevorgänge können noch 2 Nullen angehängt werden.

Als Fileserver verwenden wir MAXDATA-Server mit Hitachi-Feld, LWL zu den Hauptswitchen.

Mit dieser Konfiguration haben wir (fast) keine Geschwindigkeitsprobleme, meist werden diese durch defekte Switch- oder andere Netzwerks-Komponenten hervorgerufen.

Wir haben auch mal mit ADS Tests gefahren, aber keine nennenswerten Geschwindigkeitsänderungen feststellen können.


Viele Grüße
Gerd

[Sören]

Hallo,

ich habe ein ähnlich geartetes Problem wie Jan, daher mogel ich mich hier mal mit einer eigenen Frage rein:

Hubert schrieb:

Wir haben feste Standleitungen in die Außenbezirke, also nicht über das Internet.

Und ihr greift darüber lesend/schreibend mit einem Xbase-Programm per DBFCDX auf eure Daten zu? Und das in einer akzeptablen Geschwindigkeit?

Also im LAN sind DBF's mit Indexen nach meiner Erfahrung gar kein Problem. Aber mein Test über unser WAN mit DBFNTX hat mich schon nach wenigen Minuten das Handtuch werfen lassen. Allein das Öffnen der DB's + Indexdateien dauerte ca. 10x länger als auf dem lokalen Server.
Mit DBFCDX habe ich keine Erfahrung.

Nun zur eigentlichen Frage:

Ich habe eine Anwendung in 3 Außenstellen laufen, deren Datenbestand aufgesplittet ist. Der Datenaustausch zw. den Außenstellen läuft per Mail und Programmschnittstellen.
Natürlich wäre es sinnvoll, den Datenbestand auf einem zentralen Server vorzuhalten. Aufgrund meiner negativen Erfahrungen mit DBFNTX im WAN bin ich davon ausgegangen, dass dies nur mit SQL (ADS kommt nicht in Frage) machbar ist. Dafür müsste ich jedoch die gesamte Anwendung mehr oder weniger neu programmieren, was aus verschiedenen Gründen nicht möglich ist. Wäre die Umstellung von DBFNTX auf DBFCDX ein gangbarer Weg? Welche Erfahrungen bestehen mit DBF's auf 'entfernten' Servern?

Sören

[Tom]

Hallo, Sören.

Ich glaube kaum, daß der Wechsel von DBFNTX auf DBFCDX im WAN einen spürbaren Unterschied erzeugt. Zwar sind die Indexe bei CDX etwas kompakter, aber in beiden Fällen erfolgt sämtliche Datenbearbeitung lokal (also beim Client), so daß der Bottleneck Leitung bleibt. Es ist nicht praktikabel, auf diese Art Datenhaltung zu betreiben. Solange die Uploadgeschwindigkeiten auch bei High-Speed-DSL noch weit von denjenigen echter LANs entfernt sind, darf man auf diese Art nicht arbeiten. Da helfen nur echte SQL-Clients, Terminal Server (alle Datenbearbeitung lokal auf dem Server), selbst die ADS ist nur eingeschränkt zu empfehlen, da der Protokolloverhead sehr groß ist und zudem gelegentlich Fallbacks auf lokale Auswertungen erfolgen.

[Sören]

Hallo Tom,

was Du sagst, klingt einleuchtend, wenngleich es vage Hoffnungen zerstört .

Also bleibt, was die o.g. Anwendung betrifft, erstmal alles beim Alten.

Sören