Paradox ohne BDE

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

[jobo]

Zitat von Delphi.Narium:

Für Access braucht man keine Kompetenz

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.

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

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

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

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

[jobo]

Zitat von DasWolf:

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

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 von DasWolf:

Zitat von 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.

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

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.