Welcher Datenbankserver

[Bernd Reinhardt]

Hallo
Ich habe bei Kunden teilweise Probleme mit der dbf-Datenbank.
Prinzipiell versucht ja auch Microsoft File basierte Anwendungen auszuhebeln.
(SMB bei WIN 2008 und WIN 7/8).
Deshalb die Überlegung auf einen "Server" umzustellen. In welche Richtung es bei Alaska
geht ist mir nicht klar, und bis wann da irgendwann was fertig wird ist auch nicht kalkulierbar.

Deshalb meine Frage: Was könnte ich aktuell verwenden. Muss stabil unter allen Betriebssystemen laufen
und sollte möglichst einfach umzusetzen sein. Habe bei meinen Anwendungen mehrere Datenbanken offen.
Nutze auch browse , quickbrowse usw.

Teilweise habe ich schon MS-SQL-Server im Einsatz. Wenn von Anfang an geplant geht das mit SQL.
Aber alte USE SKIP usw. in SQL umzusetzen wäre sehr aufwändig.

Ich nutze die Version 1.9 und SL1.
Aktuell nutze ich noch NTX als Indexdateien.
Bei "like" Suche mache ich das so das ich mir beim Programmstart die Datenbank lokal hole und diese Suche
dann über die lokale Datenbank mache (geht schneller). Wenn der Satz ausgewählt ist dann schalte ich auf
die Netzwerkdatei zurück.

Was würdet Ihr mir empfehlen.

Gruß
Bernd

[georg]

Hallo, Bernd -


also, ich habe unter Zuhilfenahme von Hector Peroza's MySQL-Wrapper etliche Programme auf MySQL umgestellt. Im Gegensatz zur ODBCDBE greifst Du dann direkt über die MySQL-API zu. Sauschnell, mit den ganzen Vorteilen von MySQL (bzw. einer SQL-Implementierung).

Browse geht auch, einmal mit Bordmitteln von Hector, zum anderen gibt es von mir eine Browse-Klasse, mit der man Xbase-konform auch durch "riesige" Datenbestände gehen kann.

Für mch hat sich die Umstellung gelohnt, es ist natürlich immer davon abhängig, wieviel Code und Tabellen zu bearbeiten sind. Bei einem Programm habe ich Datei für Datei durch eine SQL-Tabelle nach der anderen ersetzt. Das gibt Dir aber auch die Chance, an manchen Stellen den Code zu optimieren.

[Jan]

Das Problem mit "normalen" SQL-Servern ist ja der administrative Aufwand. Das kann oder will nicht jeder stemmen. Wenn es also nicht auf Multiuserfähigkeit ankommt, dann bietet Xbase++ 2.0 die native Unterstützung von SQLite an. Auch SQL, die fehlenden Funktionen stören im Normalfall nicht unbedingt, besteht nur aus einer einzigen Datei. Kann aber nicht wirklich konkurrierenden Zugriff. Mit Tricks schon, aber schön ist halt was anderes.

Jan

[georg]

Guten Morgen, Jan -


so vom Grundsatz her ...

Wo bisher DBF/NTX/CDX funktioniert hat, ist kein grosser Administrationsaufwand für einen SQL-Server erforderlich.

Und SQLite ist eigentlich nicht für echten Mehrbenutzerbetrieb geeignet, und mit manchen Problemen steht man dann mit dem Rücken zur Wand. Ich habe meine SQLite-Experimente abgebrochen, als ich Zugriffsfehler bekam, weil die Datei gerade gesperrt sei - was definitiv nicht der Fall war. Und Support war schwer zu bekommen, und Onkel Google fand nichts Passendes.

[Tom]

Wenn es also nicht auf Multiuserfähigkeit ankommt, dann bietet Xbase++ 2.0 die native Unterstützung von SQLite an.

Und wenn es auf die Multiuser-Fähigkeit ankommt und Xbase++ 2.0. tatsächlich mal erscheint, bietet das außerdem die direkte Migration auf PostGre an. Damit hätte man eine SQL-App mit einem relativ stabilen und performanten Datenbankserver ohne großen Migrationsaufwand. Der ist nämlich sehr hoch. Denn es ist schon ein Unterschied, ob man ein paar SQL-Statements für irgendeine Schnittstelle in seiner Applikation hat - oder tatsächlich einen Riesentrumm von der datensatzbasierten Navigation zur mengenbasierten portieren will.

Wenn es aber nur um den richtigen Windows-Server für die dateibasierte Datenbank geht - wenn irgendein aktueller MS-Server richtig konfiguriert ist (SMB2-Patch von Alaska einspielen), sollte er's tun.

[brandelh]

... wenn irgendein aktueller MS-Server richtig konfiguriert ist (SMB2-Patch von Alaska einspielen), sollte er's tun.

die 3 (magischen) Cache-Einstellungen auf Win7-Endgeräten müssen (auch) auf dem Client eingespielt werden !

[UliTs]

Also ich würde in so einem Fall auf jeden Fall den Advantage DataBase Server (ADS) einsetzen.
1) Er kann DBF/CDX und sogar noch DBF/NTX
2) Für alte Programmteile kann man die alten USE-Befehle behalten
3) Er ist sehr schnell und zuverlässig
4) Der Administrationsaufwand ist minimal

Uli

[Bernd Reinhardt]

Hallo

2.0 ist wie viele Jahre alt?? und wie viele Jahre vergehen noch bis sich hier was tut.
Hier sehe ich noch keinen Ansatzpunkt dieses in Überlegungen einzubeziehen.

Jeder, der nach einer Client/Server-Lösung für Xbase++ und darüber hinaus sucht, sollte sich den PostgreSQL-Server und dessen Leistungsmerkmale näher betrachten. Die PostgreSQL- Preview soll, so Steffen F. Pirsig, CTO bei Alaska Software, nach dem Release von Service Level #1 für Xbase++ 1.9, erhältlich sein. Statement von vor 5 Jahren. siehe Homepage Alaska

Denjenigen unter Ihnen, die immer noch hin und her überlegen ob sie sich für die Europäische Xbase++ DevCon 2007 anmelden sollen, sei an dieser Stelle nochmals nachdrücklichst gesagt, dass die Entwicklerkonferenz die beste Gelegenheit ist, sich auf alle die anstehenden Änderungen, vor allem im Kontext der Xbase++ 2.0 Technologieplattform, vorzubereiten! Vor knapp 6 Jahren. Siehe Homepage Alaska

Seit den letzten 6 Jahren (und voraussichtlich auch in den weiteren Jahren) scheint dann ADS wohl die aktuell einzige SQL-Variante zu sein?

Die Version 1.9 ist jetzt ca. 7 Jahre alt und das einzige sind ein kleiner Servicelevel und ein paar Hotfixes und sehr viel BLA BLA BLA
Es wäre mal an der Zeit eine aktuelle Version zu veröffentlichen, denn die Hotfixes soll man ja nur bei Problemen verwenden.
Werde mir die ADS mal ansehen.
Danke für die Infos.
Gruß
Bernd

[ramses]

@ Bernd

Ich kann dir nur empfehlen den ADS-Server zu nutzen und keinesfalls auf irgendetwas von Alaska zu warten .....

Meiner Meinung nach wurde Xbase selbst von Alaska abgeschrieben (RIP) wie sonst kann erklährt werden dass wie du schreibst über Jahre ausser Versprechnungen nichts weiter gekommen ist.

Cu Carlo

[brandelh]

Wenn ODBC reicht, ist SQLexpress() die erste Wahl, einfach stabil schon lange erhältlich

Die ADS hat aktuell sicherlich den geringsten Umstellungsaufwand, auch wenn ich keine praktische Erfahrung damit habe.

[AUGE_OHR]

... wenn irgendein aktueller MS-Server richtig konfiguriert ist (SMB2-Patch von Alaska einspielen), sollte er's tun.

die 3 (magischen) Cache-Einstellungen auf Win7-Endgeräten müssen (auch) auf dem Client eingespielt werden !

der Registry Eintrag lautet

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Lanmanworkstation\Parameters

und bezieht sich auf Ordner die nicht im Netzwerk freigegeben sind ( z.b. TEMP / TMP )

[brandelh]

der Registry Eintrag lautet

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Lanmanworkstation\Parameters

und bezieht sich auf Ordner die nicht im Netzwerk freigegeben sind ( z.b. TEMP / TMP )

weshalb sollten sich LANMAN Einstellungen auf LOKALE Laufwerke mit direktem exklusivem Zugriff beziehen ?
Bei denen KANN es gar kein Problem mit einem Netzwerkcache geben

[AUGE_OHR]

weshalb sollten sich LANMAN Einstellungen auf LOKALE Laufwerke mit direktem exklusivem Zugriff beziehen ?
Bei denen KANN es gar kein Problem mit einem Netzwerkcache geben

Der Server "sendet" an die Clients den "Befehl" den lokalen Client Cache zu löschen weil sich der "ist" Zustand ( Server / Cache ) im "Netzwerk" geändert hat.

wer wissen will was die 3 "magischen" Registry Einträge machen sollte ich dies ansehen.
http://technet.microsoft.com/en-us/libr ... 10%29.aspx
innerhalb des Textes gibt es den Hinweis auf "Directory Change Notifications"

Da ich nun Dateien, auch lokale, immer per UNC-Path anspreche benötige ich die Registry Setting nicht.
nun muss man aber nicht "jeden" Ordner freigeben im Netzwerk denn das OS() hat ja "gemeinsame" Ordner.
vom dem lokalen TEMP / TMP Ordnern "weiss" der Server "nichts" weil er über diese Ordner nicht "benachrichtigt" wird.

[brandelh]

von dem lokalen TEMP / TMP Ordnern "weiss" der Server "nichts" weil er über diese Ordner nicht "benachrichtigt" wird.

Der Server (ich meine jetzt nicht den Servertask der eigenen Maschiene) hat mit diesem LOKALEN Cache auch nichts zu tun, daher mein Einwand dass dieser falls überhaupt gesharte Dateien drauf sind lokal verwaltet wird.

Da ich nun Dateien, auch lokale, immer per UNC-Path anspreche benötige ich die Registry Setting nicht.

da bin ich anderer Meinung, diese Dateien gehen über die Netzwerkschnittstelle UND könnten auch von anderen PCs/Instanzen mitbenutzt werden.
Für diese gelten Netzwerkregeln und der lokale Serverdienst wird hier wohl auch die (eventuell) lokalen Clients informieren müssen.

Behaupten möchte ich es aber nicht, es ist ewig her, dass ich auf einem Netzwerklehrgang war

Den Link oben habe ich schon mal gelesen, aber dann nicht mehr gefunden, daher hier mal einige Schlagwörter und die Überschrift

SMB2 Client Redirector Caches Explained server microsoft CACHE SMB WIN7 ...

[Jan]

Ich frage mich, warum diese bescheuerte Diskussion schon wieder los geht. Tom hatte doch ganz eindeutig auf das Installationspaket von Alaska hingewiesen, das alle notwendigen Registry-Einstellungen vornimmt. Da muß niemand manuell in den Einstellungen rumfuhrwerken.

Jan

[brandelh]

Falls dich MEIN Link so genervt hat ...
Ich habe die Seite vor einiger Zeit gesucht um sie an unseren EDV Dienstleister weiterzugeben und wollte mir das Wiederfinden erleichtern.

Im Übrigen, abregen und einfach weiterblättern wenn ein Thema nicht interessiert

[Jan]

Hallo Hubert,

Du hast damit überhaupt nichts zu tun. Du hast ja diese spezielle Diskussion nicht angestoßen.

Aber wir hatten das Thema hier schon so oft, und immer wieder wird zu allen passenden und unpassenden Gelegenheiten wieder von Vorne angefangen. Obwohl die Lösung des Problems längst fest steht. Und man nicht manuell irgendwo in der Registry rumfuhrwerken muß, sondern eine fertig Lösung von Alaska anwenden kann.

Jan

[AUGE_OHR]

Und man nicht manuell irgendwo in der Registry rumfuhrwerken muß, sondern eine fertig Lösung von Alaska anwenden kann.

Die "Lösung" von Alaska enthält "im" MSI Paket genau die 3 Registry Settings satt statt Problem "innerhalb" von Xbase++ zu lösen !!!
Es ist lediglich ein "Workaround" wenn man seine Application so konstruiert hat das ein solches Problem auftauchen könnte.

[Jan]

??? Wie "bitte"? Wie kann "man" denn "eine" Applikation "schreiben" die dateibasierte " Zugriffe" macht, und "SMB2" ausschaltet? "Das" schafft ja "nicht einmal " MS mit "seinen" eigenen Officeprogrammen.

"Abgesehen" "davon": Solange "man" SMB2 "umgehen" muß, "kann" man besser "das" Alaska-Tool "benutzen" als selber "in" der Registry rumzufuhrwerken.

Jan

[brandelh]

Hallo Jimmy,

M$ selbst schreibt doch die Abschaltung der völlig idiotischen Voreinstellung vor, wenn man Dateien shared. Das gilt auch für Access Dateien !

[UliTs]

??? Wie "bitte"? Wie kann "man" denn "eine" Applikation "schreiben" ...

Coole Antwort, Jan
Aber meinen Kommentar bitte nicht zu ernst nehmen
Uli

[AUGE_OHR]

M$ selbst schreibt doch die Abschaltung der völlig idiotischen Voreinstellung vor, wenn man Dateien shared. Das gilt auch für Access Dateien !

über welche Version sprichst du ?
die SMB2 "Erweiterungen" sind ja gerade wegen Office / Exchange gemacht worden damit z.b. in Sharepoint man gemeinsam an einer Datei arbeiten kann.

"Wie" man eine Application schreibt welche "Directory Change Notifications" beherrscht wird ja im Technet Link erklärt.