Paradox ohne BDE

[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

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

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