Paradox ohne BDE

[Jasocul]

Hier kommt das Grauen:
Bei uns gibt es ein paar sehr alte Programme, an die sich eigentlich niemand ran traut. Die Überschrift deutet wohl schon an, warum. Es sind Programme, die die BDE nutzen.
Jetzt kommt aber die Leitung auf die glorreiche Idee, dass wir demnächst auf Citrix-Lösungen umstellen.
Ein kurzes Googeln hat ergeben, dass das mit der BDE nicht wirklich optimal sein wird, wenn es denn überhaupt funktioniert. Da dachte ich mir, nimm doch mal ADO und versuche es über einen passenden ConnectionString ... Hurra, hat funktioniert.
Also einen Test auf einer anderen Maschine gemacht und ... "Die Datei hat nicht das passende Format", oder so ähnlich. Also doch kein Hurra.

Problem/Frage:
Wie kann man diese Anwendungen ohne großen Aufwand umstellen?
Wir haben im Moment nicht die Möglichkeit, große Umstellungen zu machen. Deswegen muss der Aufwand möglichst gering sein. Ideal wäre, die Paradox-Tabellen können weiter genutzt werden und die Programme benötigen nur ein paar kleine Umstellungen.

Hat jemand brauchbare Vorschläge oder Erfahrungen? Falls ja, immer her damit.

[Delphi.Narium]

Eventuell mit dem paradox dbase viewer 2.2.0 als CSV exportieren und die CSV dann in eine Datenbank eigener Wahl (was immer bei euch sonst so im Einsatz sein sollte) importieren und dann über ADO darauf zugreifen?

Alternativ:

Unter der BDE gab's auch mal die Komponente TBatchMove.

Der kann man zwei BDE-Alias angeben. Wenn man da als Quelle 'ne Paradox-Tabelle angibt und als Ziel z. B. 'nen Alias auf 'ne ACCESS-Datenbank (oder auf was man sonst so Zugriff hat), kann man recht schnell die Tabellen kopieren.

Auf die Zieldatenbank kann man dann später ohne BDE per ADO (oder auch mit jeder anderen, passenden Datenbankschnittstelle) zugreifen.

Sollte mit wenig Aufwand in 'nem halben Tag zu realisieren sein.

[franktron]

Ich habe mal alte BDE Programme auf https://sourceforge.net/projects/tpflashfiler/ migriert das klappte ohne grosse Umstellung

[jobo]

Die Frage ist ja wohl, was die Programme von der BDE nutzen.
Ich kann mich dunkel erinnern, dass ich mal in allen Formularen auf Textmodus umgestellt hab und dann TTable mit TADOQuery ersetzt habe. Dazu eine Ado Connections und das meiste lief. (Vielleicht sind das romantisch verklärte Erinnerungen, aber so ganz falsch sind sie nicht)
Ja, und es gab viel Mecker von der IDEE, nicht verfügbare Eigenschaften usw. alles gelöscht, wurde eh nicht gebraucht.

Wenn aber nun bspw. local SQL im Spiel ist oder heterogene Abfragen oder dynamisches Einbinden von ODBC Datenquellen, ja, .. kann anstrengend werden.

Beim Stichwort "minimalem Aufwand" würde ich mal auf doof nach dBase schauen, das scheint immer noch von irgendwem aufgefrischt und angeboten zu werden.

Viele schwärmen ja unter den Aspekten von Absolute DB

[mkinzler]

Lieber gliech richtig machen.

[p80286]

Die Erfahrungen von Jobo kann ich nur unterstützen, mit der Einschränkung, daß die BDE-Entwicklung noch nicht weit vortgeschritten war. (das war ein solcher Krampf)
Falls möglich, lass die Finger von der DBase/Paradox/Access-Familie wenn man einmal ein richtiges DBMS am Laufen hat, dann läuft und läuft und...... im Gegensatz zu den oben genannten, die immer nur Ärger machen, weil immer wieder irgendwelche Inkompatibilitäten auftauchen.

Gruß
K-H

[MichaelT]

Willkommen im Grauen.

Die DBASE Leute nehmen noch immer BDE.

a) Wahre Elend
Verteilten Über- und Unterbautern zu Clipper usw... In der Tradition war mal Alaska XBase zu sehen und ich denke Hersteller von Advatage DB hatten solche 'Libraries und Runtimes' auch noch im Programm.

Der nächste Schritt war.

b) Überschaubares Elend
C/S fähig machen via Datenbank, ehem. Vista DB Server und heute blieb noch die Apollo DB Engine (Hyper-Six) oder Advantage Database. Bei den XBASE Derivaten und damit verbunden den 'Servern' geht es immer um die performant(er)en Indizes und deren Verwaltung.

(* Das automatisierte Verwalten von Indizes kam erst nach oder mit DBASE IV *). Klarerweise hat hernach jeder Hersteller seine eigene Variation gepfrimmelt.

Der Advantage Database Server konnte so ich mich recht erinnere mit den Dateien umgehen, war aber eher einer Mischung SQL Datenbank und Nexus DB (ohne Transports sondern mit Client Library) ähnlich.

Den Weg haben viele beschritten oder die Anwendungen so gelassen wie sie sind.

c) UniDAC hat zumindest einen Support für FOXPro Files und DBF Files.

Der Vollständigkeit halber. Die FireDAC Connectoren (dieses Zusatzpack zu Delphi) haben auch eine XBASE Implementierung (nicht FireDAC über ODBC oder so). FireDAC kann noch auf Advantage DB.

Aber wie weit sich die mit Paradox Tabellen decken kann ich nicht ganz genau sagen und was zur Umsetzung des definierten XBASE Standard noch hinzukam. Mit Unicode usw... ist nicht viel, so ich mich recht erinnere.

Die MS kaufte Foxbase (FoxPro) und deswegen sind die Treiber noch immer da.

Das Elend geht ja weiter. Historisch haben solche Anwendungen unter DBASE resp. Clipper usw... oft transponierte Tabellen - d.h. mit ';' (an sich eine halbverwahrtakelte Verletzung der 1. NF) Werte aus einer Nachschlagetabelle (heißt in SAP R/3 Cluster und im Hintergrund (4GL) wird für jeden Wert eigene SQL Query erzeugt usw ... Damit man zu DBASE Zeiten nicht die Tabellen n-mal hat bei dem Datensatz Zugriff lesen müssen wurden sie 'kommasepariert' gespeichert und zumeist kryptisch mit 2 bis 3 Buchstaben verschlüsselt).

Das war jetzt umfassendere Variante Stand vor ca. 14 Jahren. Es vielen alle viele Alternativen weg und DBASE kam zurück. Migration einer DBASE Anwendung, dass die Variante DB-DOS (Shell in der DBASE DOS Anwendung laufen und auch Drucken können) keine schlechte Idee ist resp. ich im Moment eher DBASE direkt nehme. Aber nur für den lokalen Fall. Die DBASE Leute gehen heute gegen relationale DBs über ADO, was ganz gut zur so 4GL Sprache passt, aber ... naja. Es gibt Dinge die muss man mögen.

Delphi Komponenten wie TDBF usw... muss man sich konkret anschauen.

Michl

Zitat von Jasocul:

Hier kommt das Grauen:

Hat jemand brauchbare Vorschläge oder Erfahrungen? Falls ja, immer her damit.

[jaenicke]

Die BDE funktioniert mit einem aktuellen Server 2016 oder Server 2019 gut auch mit SMB 3 mit DBase oder Paradox, wenn man in der SMB Konfiguration den neu für diesen Zweck eingeführten LeasingMode auf None setzt, das gilt auch für Citrix.
Wenn man lokal auf dem RDP-/Citrix-Server mit den Datenbankdateien arbeitet, hat man damit aber ja ohnehin kein Problem.

Nichtsdestotrotz macht es schon Sinn auf ein aktuelleres Datenbanksystem umzustellen. Bei richtiger Konfiguration sind die Probleme mit der BDE zwar selten, aber wenn sie auftreten eben auch ggf. nicht nachhaltig lösbar.

[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.