Paradox ohne BDE

[hoika]

Hallo,

Zitat:

Wenn man lokal auf dem RDP-/Citrix-Server mit den Datenbankdateien arbeitet, hat man damit aber ja ohnehin kein Problem.

Naja, wie man es nimmt.
Es arbeiten dann mehrere Nutzer an einer Datei.
Die jeweiligen Sperren erfolgen durch das Dateisystem.
Es gibt bei NTFS die sogenannten oplocks (oppertunistic locks),
Das war damals unser Problem bei der Umstellung von Novell (3.11 jaja ) auf Windows NT.
Erst das Abschalten brachte ein kurze Verbesserung, aber auch extreme Performance-Einbussen.

[jaenicke]

Zitat von hoika:

Es gibt bei NTFS die sogenannten oplocks (oppertunistic locks),
Das war damals unser Problem bei der Umstellung von Novell (3.11 jaja ) auf Windows NT.
Erst das Abschalten brachte ein kurze Verbesserung, aber auch extreme Performance-Einbussen.

Die OpLocks sind Teil von SMB, nicht von NTFS. Von daher hat man damit lokal nichts zu tun, wenn man kein Netzlaufwerk benutzt.
Es ist richtig, dass es ohne langsamer ist, aber nicht langsamer als früher, denn vorher gab es ein solches Caching schlicht nicht.

Jedenfalls ist genau dafür die Konfiguration LeasingMode = None gedacht, die diese problematischen Teile von SMB 2 und 3 deaktiviert, so dass lokale Datenbankdateien wie eben DBase oder Paradox wieder damit funktionieren.

[Codehunter]

Ich hab jetzt nicht den ganzen Thread gelesen, möchte nur meine Erfahrung dazu geben.

Ich würde zweigleisig fahren. Die bestehenden Programme evaluieren und mit dem geringst möglichen Aufwand am Leben erhalten. Wenn Citrix da jetzt ein Problem darstellt, dann sollte man das evtl. noch etwas schieben.

Parallel die Altprogramme neu aufsetzen als moderne C/S-Konstruktion. Wenn man nämlich genau hinschaut, braucht man oftmals nicht mal mehr die Hälfte der Funktionen, die alte Programme hatten.

In Ergebnis kam ich in solchen Fällen fast immer zu der Erkenntnis, dass Aufwand und Nutzen für eine Neuentwicklung sprachen. Manchmal rechnet es sich erst nach Jahren, aber dann umso mehr.

In wiefern eure Geschäftsleitung nun nachhaltig denkt oder nur auf kurzfristigen Benefit scharf ist, mag ich nicht beurteilen.

[Codehunter]

Ich bin jetzt grad zufällig über etwas gestolpert, das evtl. in diesem Fall interessant sein könnte.

[jobo]

Ich glaube, das ist durchaus geläufig. Es taucht öfter mal in der DP auf.
Ich hatte es bereits in #4 erwähnt.

Allerdings würde ich es einfach eine dateibasierte Datenbank nennen und nicht BDE Replacement wie im Link.

[Redeemer]

Zitat von Codehunter:

Zitat von Jasocul:

Zitat von MaBuSE:

Ich würde Dir auch empfehlen, die Anwendung auf einen SQL-Server zu migrieren. (unabhängig vom Hersteller MS, Oracle, ...)

Zu dem Schluss bin ich inzwischen auch gekommen.

Will auch gründlich überlegt sein. Lizenzkosten einerseits, Zukunftssicherheit andererseits, Features passend zu den Anforderungen drittens.

Ich spreche mal aus Erfahrung mit MSSQL und Paradox: An der Stelle, an der die aktuellen Express-Editionen die Segel streichen, hast du durch Paradox

• täglich eine zu große Sperrdatei
• wöchentlich einen Index zerlegt
• wöchentlich verschwundene Daten, die aus dem Backup geholt werden müssen
• 50% Nutzer, die in Paradox nicht richtig suchen können, weil sie mehr als 2 GiB (modulo 4 GiB) freien Festplattenspeicher und keine gehackte idapi32.dll haben
• vermutlich mindestens einen Nutzer, der „prüfen“ wollte, ob man tatsächlich alle „passwortgeschützten“ Paradox-Dateien einfach durch Eingabe von wahlweise „cupcdvum“ oder „jIGGAe“ öffnen und bearbeiten kann

Zitat von jobo:

Allerdings würde ich es einfach eine dateibasierte Datenbank nennen und nicht BDE Replacement wie im Link.

Korrekt. Hat mit Paradox absolut gar nichts zu tun.

[jaenicke]

Zitat von Redeemer:

50% Nutzer, die in Paradox nicht richtig suchen können, weil sie mehr als 2 GiB (modulo 4 GiB) freien Festplattenspeicher und keine gehackte idapi32.dll haben

Das habe ich damals alles im Speicher des Prozesses gefixt, inklusive der Schutzverletzungen beim Beenden der Anwendung, die seit Windows 7 immer wieder mal auftraten. Glücklicherweise kam das alles erst nach den wichtigsten Deinitialisierungen der BDE, so dass ich eine Stelle gefunden habe, an der ich gefahrlos die weitere Deinitialisierung der idapi32.dll abbrechen konnte.