Paradox ohne BDE

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

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

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

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.

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

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

[Jasocul]

Zitat von jobo:

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.

[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