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:kotz:)
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

[jobo]

Ach und nochwas:
"Die Datei hat nicht das passende Format" oder so ähnlich
Klingt nicht nach einer klassischen Delphi/ADO Fehlermeldung..

Auch ADO hat ja nun schon eine lange Geschichte. Ob und welche (genaue) Version der Komponenten nun (zufällig) auf einem Rechner installiert ist, wer weiß das schon?! Wahrscheinlich nicht mal der Admin. Teilweise war es schon im OS dabei, häufig kommt es von Office Installationen, vielleicht von SQL Client, vielleicht von expliziten Installationen..
Dann wird auch schon mal was deinstalliert..
Eine Stichprobe auf irgendwelchen (Entwicklungs-)Rechnern ist kaum zielführend, vielleicht fliegt da sogar noch die BDE rum.
Lieber ein frisches W10 aufsetzen und dann schauen, was nachinstalliert werden muss (ins Programm Setup gehört)

[Jasocul]

Eine DB-Umstellung ist aktuell eigentlich nur zweite Wahl. Es kann in einigen der Anwendungen zu Situationen kommen, in denen die richtige DB (SQL-Server) nicht verfügbar ist. Die Anwendungen müssen dann aber trotzdem weiterlaufen und die Daten verarbeiten können.

In einer zukünftigen Version, werden diese speziellen Situationen nicht mehr existieren, aber bis dahin sollte alles in etwa so bleiben, wie es ist. Deswegen wollte ich die Paradox-Tabellen auch erstmal erhalten. Embedded-Alternativen sind vermutlich auch ein Problem, da Multi-User-Zugriff weiterhin (begrenzt) möglich sein muss.

So wie ich das aber gerade an euren Antworten sehe, kommen wir wohl nicht daran vorbei, eine DB-Alternative zu finden.

Ich hatte gehofft, dass ich die 20 Jahre alten Sourcen nur geringfügig bearbeiten muss. Sieht dann aber wohl nach ein bisschen mehr aus.

Zitat:

Zitat von jobo (Beitrag 1437251)

Ach und nochwas:
"Die Datei hat nicht das passende Format" oder so ähnlich
Klingt nicht nach einer klassischen Delphi/ADO Fehlermeldung..

Das war meine Hoffnung und daher dachte ich an eine einfach Lösung dieses Problems, im Sinne von: Installiere mal das und jenes nach.

Zitat:

Zitat von jobo (Beitrag 1437251)

Eine Stichprobe auf irgendwelchen (Entwicklungs-)Rechnern ist kaum zielführend, vielleicht fliegt da sogar noch die BDE rum.

Auf meinem Rechner mit BDE, funktioniert es. Auf einem ohne leider nicht. Ich könnte noch ein paar Rechner prüfen, aber:

Zitat:

Zitat von jobo (Beitrag 1437251)

Lieber ein frisches W10 aufsetzen und dann schauen, was nachinstalliert werden muss (ins Programm Setup gehört)

Windows 10? Sowas modernes haben wir hier nicht. Aber ich verstehe, was du meinst.

[Delphi.Narium]

Über welche Datenmengen reden wir hier?

Multiuser und ADO und Access funktionieren.

Und wenn das sowieso eine Lösung ist, die nur bei Ausfall der "richtigen" DB einspringen soll, wäre das eventuell eine Option.

Was ist mit Multiuser gemeint?

'ne handvoll Nutzer oder hunderte?

'ne handvoll geht mit ADO und Access.

(Auch wenn Access jetzt nicht unbedingt das super Datenbanksystem ist, 'ne MDB-Datei (wieviele Tabellen werden eigentlich benötigt und wie groß sind sie? Anzahl Datensätze?) sollte eigentlich gehen.)

Wie lange ist noch bis zur zukünftigen Version? Plant Ihr schon konkret oder ist's eher so 'ne Idee mit (noch) ungewisser Aussicht auf Umsetzung?

[Jasocul]

• Die Anzahl der Datensätze bewegt sich im 5-stelligen Bereich.
• Die angebundenen Anwendungen nutzen immer die Paradox-Tabellen. Es ist also keine optionale Nutzung, da bekannt ist, dass diese Situationen eintreten.
• Die maximale Anzahl gleichzeitiger User dürfte einstellig sein.
• Die zukünftige Version befindet sich erst im Planungsstadium. Bisher auch noch ohne Zeitplan und Termin.

Access könnte ein Ansatz sein, da wir hier zumindest einen Kollegen mit Basis-Kompetenz haben. Der hat allerdings Null Ahnung von Delphi. Sollte aber nicht stören.

[p80286]

Trotz allem schlage ich Dir die MS-SQL-Sparversion vor, die kann auch Multiuser und muß nicht zwangsläufig auf einem (extra)Server installiert sein. Bei allem Verständnis für Deine Situation letztlich kommt es für den Benutzer nicht darauf an was genutzt wird sondern wie es sich anfühlt. Und diese Kompromisse haben ein langes und zähes und kostspieliges Leben.

Gruß
K-H

P.S.
Wenn die eingesetzten Programme eh Tabellenorientiert sind, dann geht das auch mit "richtigen DBMS"en

[mkinzler]

Zitat:

Trotz allem schlage ich Dir die MS-SQL-Sparversion vor

Oder ein anderes richtiges DBMS.
(FireBird, PosGresSQL, ...)

[Jasocul]

Zitat:

Zitat von p80286 (Beitrag 1437258)

... letztlich kommt es für den Benutzer nicht darauf an was genutzt wird sondern wie es sich anfühlt. Und diese Kompromisse haben ein langes und zähes und kostspieliges Leben.

Völlig richtig. Ich wollte nur den Aufwand möglichst gering halten.

@mkinzler:
Korrekt

[Bernhard Geyer]

Zitat:

Zitat von mkinzler (Beitrag 1437259)

Zitat:

Trotz allem schlage ich Dir die MS-SQL-Sparversion vor

Oder ein anderes richtiges DBMS.
(FireBird, PosGresSQL, ...)

Auch die Sparversion vom MS SQL Server ist ein richtiges DBMS.
Macht nur bei 10 GB Datenbankgröße "zu".
Davon ist man im aktuellen Anwendungsfall meilenweit davon entfernt.

[mkinzler]

Zitat:

Auch die Sparversion vom MS SQL Server ist ein richtiges DBMS.

Bezweifelt ja keiner

Zitat:

Oder ein anderes richtiges DBMS.

Sonst hätte ich ja das Wort anderes weggelassen.

[Delphi.Narium]

Für Access braucht man keine Kompetenz ;-)

Die Oberfläche oder sonst irgendwas vom "optischen" Access wird nicht benötigt.

Die Tabellen kann man (auch aus Delphi heraus) per SQL erstellen.

Wenn Du die Tabellen (wie oben beschrieben per TBatchMove) kopierst, brauchst Du nicht mal das.

In dem Fall benötigst Du einen ODBC-Treiber für die Access-DB. Die Access-DB kann man über die ODBC-Verwaltung von Windows erstellen lassen, es werden letztlich nur die Treiber für Access benötigt. Die Software Access (also die Oberfläche) ist nicht erforderlich.

Die BDE kann dann darauf einen Alias machen.

TBatchMove benötigt dann den Alias auf die Paradoxtabelle und den Alias auf die Access-DB. Das Erstellen der Tabellen in der Access-DB erfolgt automatisch (mode = batCopy).

Beim Kopieren der Daten per TBatchMove ist es letztlich aber egal, für welches Zieldatenbanksystem Du dich entscheidest.

Benötigt wird halt die BDE (für Paradox und TBatchMove) und ein ODBC-Treiber für die Zieldatenbank, der in die BDE per Alias eingebunden wird. (Wenn ich mich recht erinnere, erkennt die BDE aber die eingerichteten ODBC-Treiber selbständig, habe gerade bei mir mal nachgeschaut: In der BDE-Verwaltung sind alle eingerichteten ODBC-Treiber als BDE-Alias sichtbar.)

Grob könnte sowas schon ausreichen, sofern es sich um Tabellen "mit handelsüblichen Spalten" handelt, also Integer, Float, Strings, ob und wie das mit Blobs funktioniert weiß ich nicht, könnte aber auch so einfach gehen.

Delphi-Quellcode:

// tbSource und tbDestination = TTable
// bm = TBatchMove
  tbSource.Close;
  tbDestination.Close;
  tbDestination.FieldDefs.Clear;
  tbDestination.IndexDefs.Clear;
  tbSource.DatabaseName      := 'Paradox-Alias im Objektinspektor auswählen';
  tbDestination.DatabaseName := 'ODBC-Alias auf Access im Objektinspektor auswählen';
  tbSource.TableName         := 'paradox.db';
  tbDestination.TableName    := 'paradox';  // nur der Tabellenname ohne Dateiendung.
  bm.Mappings.Clear;
  bm.Mode := batCopy;
  bm.Execute;

Arbeitet Ihr im Programm irgendwo mit SQL? Wenn nein, könnte nach dem Kopieren der Daten eine Änderung der Tabellen von TTable nach TAdoTable bzw. von TQuery nach TAdoQuery per global Change in den DFM-Dateien bzw. den PAS-Dateien (wie von Jobo beschrieben) ausreichen.

SQLs müssen ggfls. in der Syntax angepasst werden.

[hoika]

Hallo,
man könnte auch erst mal bei der BDE bleiben,
aber auf Firebird umstellen.

So hatten wir das damals gemacht, das war noch zu glorreichen Zeiten von Interbase 6.

Mit DataPump könnte die Daten rüberziehen.
Ich hatte mir damals aber ein eigenes Copy-Programm geschrieben,
weil eben auch üöä-in den Paradox-Feldnamen standen.

Hier ist ein alter Artikel, der dass beschreibt und mir sehr geholfen hatte.

https://www.ibphoenix.com/resources/...gration/doc_74

[timog]

FireDAC per ODBC auf Paradox? In einem antiken (kleinen) Projekt habe ich mal mit reFind den Wechsel von BDE auf FireDAC gemacht. Ging tatsächlich in dem kleinen Projekt ohne Schmerzen (reFind ist nicht "intelligent", aber besser als von Hand).

http://docwiki.embarcadero.com/RADSt...ngen_(FireDAC)

oder auch

https://community.idera.com/develope...d-dbase-tables

Der Paradox ODBC Treiber muss halt vorhanden sein, damit das klappen kann.

[jobo]

Zitat:

Zitat von Delphi.Narium (Beitrag 1437269)

Für Access braucht man keine Kompetenz ;-)

:thumb:

Genau, mann muss nur die Tabellen und Basisdaten in eine +.mdb Datei bekommen. Access selbst ist wegen Kosten/ Lizenz maximal administrativ einzusetzen bzw. wird eigentlich nicht benötigt.

BDE zu behalten ist ja wohl genau die Schwierigkeit in einem halbwegs aktuellen (Citrix-) System. Dazu kann ich nichts sagen.

Wobei ich hier nicht so ganz verstehe, wie man Software entwickelt, wo es um Kompatibilität zu modernen Umgebungen geht, aber kein Windows 10 zum Test hat.

[Jasocul]

@Delphi.Narium:
Danke für die ausführliche Beschreibung. Ähnliches habe ich früher auch schon gemacht, ist aber bestimmt 20 Jahre her. So muss ich das nicht irgendwo wieder nachsehen.

@hoika:
Es ging ja darum, die BDE loszuwerden.:wink:

[hoika]

Hallo,

Zitat:

BDE zu behalten ist ja wohl genau die Schwierigkeit in einem halbwegs aktuellen (Citrix-) System

Ich denke, nicht die BDE ist das Problem, sondern Paradox.
"index out of date" -> wie hatte ich das gehasst nach dem Umstieg von Novell auf Windows NT.

[jobo]

Naja, was will man mit dem einen ohne das andere?

[Jasocul]

Zitat:

Zitat von jobo (Beitrag 1437276)

Wobei ich hier nicht so ganz verstehe, wie man Software entwickelt, wo es um Kompatibilität zu modernen Umgebungen geht, aber kein Windows 10 zum Test hat.

Die Software wird ja nicht entwickelt, sondern ist schon da. Bisher wurden ausschließlich Fat-Clients (W7) genutzt. Die Entscheidung für die Citrix-Variante ist ohne viel Vorlauf definiert worden und wir müssen nun sehen, dass dann alles rechtzeitig passt.

[hoika]

Hallo,
wie hatten damals ~ 2.Mio Zeilen Quellcode, gespickt mit der BDE,
viel TTable, wenig TQuery.

Wir konnten zumindestens in endlicher Zeit (2 oder 3 Monate) eine stabile
Nicht Paradox-Version ausliefern.

Bei uns war nicht die BDE das Problem, sondern das instabile Paradox bei MS-Netzwerken.

[DasWolf]

Zitat:

Zitat von hoika (Beitrag 1437278)

Hallo,

Zitat:

BDE zu behalten ist ja wohl genau die Schwierigkeit in einem halbwegs aktuellen (Citrix-) System

Ich denke, nicht die BDE ist das Problem, sondern Paradox.
"index out of date" -> wie hatte ich das gehasst nach dem Umstieg von Novell auf Windows NT.

Ich kann da voll und ganz zustimmen. Die BDE läuft auch in aktuellen Citrix-Systemen einwandfrei, problemlos, stabil, ohne zu zucken..und so weiter und so fort.
Meine These: Das wird auch in 100 Jahren noch so sein :wink:

Bei DBMS hingegen sollte man mittlerweile nicht mehr so lange nachdenken, ob man da irgendwo bei Paradox oder gleichwertigem Zeug bleibt.

[jobo]

Zitat:

Zitat von DasWolf (Beitrag 1437290)

Die BDE läuft auch in aktuellen Citrix-Systemen einwandfrei, problemlos, stabil, ohne zu zucken..und so weiter und so fort.
Meine These: Das wird auch in 100 Jahren noch so sein :wink:

Also wenn das so ist (mit den 100 Jahren würd ich mich nicht soweit aus dem Fenster lehnen), dann ist das doch für diese Konstellation eine hilfreiche Sache!
Dann braucht man tatsächlich nur den Paradox Ersatz.

Mal laut nachgedacht: Wenn die BDE auf Citrix stabil läuft und wenn Paradox von dort über einen eindeutigen lokalen Pfad angesprochen wird, gibt es vielleicht gar kein Problem mehr. Nach meiner Erfahrung war zumindest nicht Multiuser das Hauptproblem, sondern dabei dann eindeutige Netzwerk-Pfade. Mit einem lokalen Laufwerk, am besten das gleiche, was die Windows Installation hält, wäre man da schon recht weit (geringste Wahrscheinlichkeit einer unbeabsichtigten Änderung)

[Delphi.Narium]

Zitat:

Zitat von DasWolf (Beitrag 1437290)

Zitat:

Zitat von hoika (Beitrag 1437278)

Hallo,

Zitat:

BDE zu behalten ist ja wohl genau die Schwierigkeit in einem halbwegs aktuellen (Citrix-) System

Ich denke, nicht die BDE ist das Problem, sondern Paradox.
"index out of date" -> wie hatte ich das gehasst nach dem Umstieg von Novell auf Windows NT.

Ich kann da voll und ganz zustimmen. Die BDE läuft auch in aktuellen Citrix-Systemen einwandfrei, problemlos, stabil, ohne zu zucken..und so weiter und so fort.
Meine These: Das wird auch in 100 Jahren noch so sein :wink:

Bei DBMS hingegen sollte man mittlerweile nicht mehr so lange nachdenken, ob man da irgendwo bei Paradox oder gleichwertigem Zeug bleibt.

Wenn dem so ist, würde doch ein Kopieren der Daten in 'ne Access-DB (o. ä.) reichen, den BDE-Alias ändern und gut iss?

Vorhandenen BDE-Alias auf die neue Datenbank umstellen und im Idealfall ist dann am Programm selbst nix zu ändern.

Aber andererseite:
Die Probleme traten doch erst auf, als mit ADO auf Paradox zugegriffen werden sollte.
Wenn die BDE bleiben kann, kann auch Paradox bleiben.

@Jasocul

Habt Ihr es schonmal mit dem Programm und der BDE auf 'nem neuen Zielsystem probiert?

Gibt's irgendwelche Probleme? Wenn nein, dann ist nix zu machen.

[HolgerX]

Hmm..

Das Problem von ADO (Jet Engine) mit Paradox ist wohl eher, das nur bis Paradox 5 'einigermaßen' unterstützt wird.

Wenn die Tabellen aber Paradox 7 sind, dann geht es ohne die Installation der BDE auf allen Clients bzw. Citrix-Server nicht...

Somit würde ein Tausch aller BDE-Komponenten gegen entsprechende ADO-Komponenten unter Verwendung einer Konvertierung der Paradox-DB nach Access oder gleich SQL-Server die saubere Lösung sein.

Gerade, weil viele Admins es nicht mögen, wenn auf Ihren Citrix-Terminalserver irgendwelche 'Alt-Software' installiert werden muss, da ja i.R. hier die Clients bei jedem Login auf einem anderen Server landen können..

Und wenn Du dann ein paar dutzend Terminalserver am laufen hast, dann muss auf allen die BDE installiert werden...

Auch was die Kompatibilität mit anderen Programmen angeht, welche ja auch auf diesen Servern laufen.

Wenn nur lokale FatClients verwendet werden, dann wird auf diesen die BDE installiert und gut ist.. Aber Terminalserver ist da schon etwas anderes..

[Jasocul]

Da ich gleich in den Feierabend gehe, gebe ich noch ein paar Kommentare zur bisherigen Diskussion ab:

• Das neue System existiert noch nicht. Tests sind daher im Moment nicht möglich.
• Beim Googeln habe ich gelesen, dass Citrix und BDE problematisch sind. Schön, wenn das doch nicht so ist. Dennoch wäre der Abschied von der BDE nicht schlecht. (Anforderung ist übrigens, dass es kein Laufwerksmapping mehr geben soll. Ich meine, dass die BDE da auch mal rumgezickt hat)
• Es sieht wohl doch nicht so schlecht aus, die Daten auf den SQL-Server zu migrieren. Prüfung passiert morgen.
• Die Paradox-Tabellen sind alle V4 oder V5. Das macht deutlich, wie alt die Anwendungen sind.

Ich danke erstmal für die hilfreiche Unterstützung.

[hoika]

Hallo,
du musst bei der Umstellung auf jeden Fall das Locking (Sperren) von Datensätzen bei Mehrbenutzerbetrieb prüfen,
das läuft bei einem SQL-Server anders als bei Paradox,
oder genauer das bei Paradox idR benutzte pessimistische Locken, also Sperren vor der Änderung von Datensätzen, nicht so richtig.
wenn nur immer einer mit dem Programm arbeitet, hast du da aber kein Problem.

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

Zitat von Jasocul (Beitrag 1437233)

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:

Zitat von hoika (Beitrag 1437389)

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.

[MaBuSE]

Zitat:

Zitat von Jasocul (Beitrag 1437302)

• Beim Googeln habe ich gelesen, dass Citrix und BDE problematisch sind. Schön, wenn das doch nicht so ist. Dennoch wäre der Abschied von der BDE nicht schlecht. (Anforderung ist übrigens, dass es kein Laufwerksmapping mehr geben soll. Ich meine, dass die BDE da auch mal rumgezickt hat)
• Es sieht wohl doch nicht so schlecht aus, die Daten auf den SQL-Server zu migrieren. Prüfung passiert morgen.
• Die Paradox-Tabellen sind alle V4 oder V5. Das macht deutlich, wie alt die Anwendungen sind.

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

Das alte System würde ich aber erst mal auf BDE lassen.
Wenn Du auf eine Datenbank umstellst, dann solltest Du auch berücksichtigen, dass diese etwas anders arbeitet als eine "dateibasierende Tabellen Sammlung" ;)
In Paradox wirst Du wahrscheinlich ein Locate auf ein TTable machen. In einer SQL-Datenbank macht man SQL-Abfragen. Das ist ein etwas anderes arbeiten.
Aber das wirst du sicherlich wissen.

Ich möchte nur darauf hinweisen, dass es mit einem Batchmove auf die Datenbank und dann "nur" ein Austausch der Komponenten nicht getan ist.
Übrigens die BDE ist auch für das aktuelle Delphi Rio verfügbar: http://cc.embarcadero.com/item/30868
Du musst also nicht zwangsläufig mit dem alten Delphi arbeiten.
Du musst nur darauf achten, das bei Delphi 2007 und 2009 der Unicode Umbruch war.
Evtl wäre dann temporär ein Delphi 2007 die bessere Wahl.

Aber das sind nur ein paar Gedanken. ;)
Viel Spaß und Glück

[Jasocul]

Zitat:

Zitat von MaBuSE (Beitrag 1439007)

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.

Zitat:

Zitat von MaBuSE (Beitrag 1439007)

Das alte System würde ich aber erst mal auf BDE lassen.

Da meine Information zu BDE und Citrix möglicherweise falsch sind, werde ich erstmal einen Test veranlassen.

Zitat:

Zitat von MaBuSE (Beitrag 1439007)

Wenn Du auf eine Datenbank umstellst, dann solltest Du auch berücksichtigen, dass diese etwas anders arbeitet als eine "dateibasierende Tabellen Sammlung" ;)
In Paradox wirst Du wahrscheinlich ein Locate auf ein TTable machen. In einer SQL-Datenbank macht man SQL-Abfragen. Das ist ein etwas anderes arbeiten.
Aber das wirst du sicherlich wissen.

Es ist noch schlimmer. In den alten Anwendungen wird teilweise mit benutzergesteuerten Filtern gearbeitet. Die Unterschiede sind mir durchaus bewusst.

Zitat:

Zitat von MaBuSE (Beitrag 1439007)

Ich möchte nur darauf hinweisen, dass es mit einem Batchmove auf die Datenbank und dann "nur" ein Austausch der Komponenten nicht getan ist.

Korrekt

Zitat:

Zitat von MaBuSE (Beitrag 1439007)

Übrigens die BDE ist auch für das aktuelle Delphi Rio verfügbar: http://cc.embarcadero.com/item/30868
Du musst also nicht zwangsläufig mit dem alten Delphi arbeiten.
Du musst nur darauf achten, das bei Delphi 2007 und 2009 der Unicode Umbruch war.
Evtl wäre dann temporär ein Delphi 2007 die bessere Wahl.

Es läuft zumindest unter XE2 problemlos mit der BDE.

Zitat:

Zitat von MaBuSE (Beitrag 1439007)

Aber das sind nur ein paar Gedanken. ;)
Viel Spaß und Glück

Danke

An alle anderen Tippgeber:
Danke für eure Unterstützung.

Ich werde jetzt erstmal klären, ob es unter Citrix tatsächlich keine Probleme gibt. Wenn es denn so sein sollte, werde ich versuchen, die Umstellung sukzessive durchzuführen, da offensichtlich verschiedene Programme auf die selben Paradox-Tabellen zugreifen und die Dokumentation eher spärlich ist.

[Codehunter]

Zitat:

Zitat von Jasocul (Beitrag 1439451)

Zitat:

Zitat von MaBuSE (Beitrag 1439007)

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.

Zitat:

Zitat von Jasocul (Beitrag 1439451)

Ich werde jetzt erstmal klären, ob es unter Citrix tatsächlich keine Probleme gibt. Wenn es denn so sein sollte, werde ich versuchen, die Umstellung sukzessive durchzuführen, da offensichtlich verschiedene Programme auf die selben Paradox-Tabellen zugreifen und die Dokumentation eher spärlich ist.

Hat das noch nie gerumpelt bei konkurrierenden Zugriffen? Das tät mich sehr wundern.