Neues Datenbank-Backend für meine Anwedung - Welches?

[berens]

Hallo zusammen und nochmal herzlichen Dank für die zahlreichen -sehr hilfreichen- Antworten.

Zur allgemeinen Erheiterung möchte ich noch das Best-Of der Besprechung mit meinem Kollegen (Vetrieb) zu den nun zur Verfügung stehenden Alternativen (bei Access bleiben, MS SQL (Express), Firebird) wiedergeben: "Dann implementier doch einfach alle Drei. Bei jeder Datenbankabfrage vorher ne kleine if-then Abfrage für die jeweils benötigten Komponenten - kann auch nicht mehr Arbeit sein als nur die eine neue Komponente zu implementieren.". Ja ne is klar.

Ich meine vom Grundgedanken hat er ja nicht unrecht: Kleine Kunden könnten auf "Einzelplatzlösungen" (1 Infobildschirm, 1 Redaktions-PC) ja auch in Zukunft -mit den bekannten Mankos- schon noch auf .mdb-Dateibasis weiterarbeiten. Auch die Demoinstallationen bei Interessenten wären auch hier noch schnell und einfach möglich. Und die Ansteuerung von MS SQL und Firebird über den ODBC-Treiber (danke @Delphi.Narium , nochmal gute Idee) würde ja die Änderungen (größtenteils) auf die TAdoConnection beschränken. Der Benutzer könnte ja dann mit der klassischen Installation anfangen (lokale Datenbank), und -auf Wunsch oder Anraten von unserem Support (mir ) auf ein größeres System migrieren. Den FireBird Server könnte man ja als optional installierbaren Punkt in unserem Installer anbieten, oder als zusätzliches Stand-alone Downloadmodul (oder natürlich den offiziellen Download verlinken). Den ODBC-Treiber für Firebird würde ich dann wahrscheinlich bei allen Installationen zwangs-mitinstallieren.

Wahrscheinlich würde ich die Migration so planen:
1) Einen Assistenten anbieten, um die Datenbankverbindung auswählen zu können (.mdb / MS SQL / Firebird), also entweder Dateipfad oder Server/IP, User/Pass (wie speichert man das wieder sicher?) , der dann zukünftig von der TAdoConnection verwendet wird.
2) Einen Upscaling-Assistenten anbieten, der in der leeren Datenbank auf dem Firebird/SQL Server alle notwendigen Tabellen erzeugt bzw. auf den aktuellen Stand bringt, und -nach Möglichkeit- direkt alle Daten 1:1 rüber kopiert.
3) Auslagern aller direkten Datenbankzugriffe von den jeweils Themenbezogenen Units in eine (oder mehrere) Datenbank-Units, wo situationsbezogen (als Prozeduren mit entsprechenden Parametern) der SQL-String und die Parameter vorbereitet werden, so dass ich in den themenbezogenen Units nur mit (q = TAdoQuery --> q.First, q.Next, q.EOF, q.FieldByName('Text1').AsString := 'Test'; q.Post, q.Close etc.) arbeite, aber alle Datenbank-nahen Befehle (q.SQL.Add('...'); q.Parameters.ParamByName(...) ) in dieser einen(?) Datenbankunit bleiben. Das hätte den Vorteil, dass ich recht einfach und übersichtlich hierfür dann Unit-Tests schreiben kann, die man ggf. auch zur Laufzeit beim Kunden laufen lassen kann, um eventuelle Inkompatibilitäten zu verschiedenen MS SQL / FireBird Versionen aufdecken zu können, die ggf. beim Kunden auftreten können. Ich rede hier nicht von eventuellen Bugs, aber von Erfahrungswerten nach dem Motto: Bei Access-SQL müssen/können bei Abfragen Tabellen/Feldnamen in [eckigen].[Klammern] stehen, WHERE TEXT1="" muss in FireBird-SQL evtl. WHERE TEXT='' lauten etc.etc. Halt diese kleinen Spitzfindigkeiten, bei denen ich mich auch gerne früher schon and den SQL92 Standard gehalten hätte, aber Access manche Sachen eben doch explizit anders haben will... Beispiel: Eine Tabelle nennt sich "Layout". Böses Wort, könnte als systemreserviert Interpretiert werden. Wenn ich nun "alle" meine SQL-Abfragen/Befehle/Unit-Tests beim Kunden nacheinandere ablaufen lasse(n kann), sehe ich z.B. falls

Code:

CREATE TABLE [Layout] ...

auf dem einen System fehlschlägt, und

Code:

CREATE TABLE "Layout" ...

auf dem Andern, und entsprechend darauf reagieren.

Somit wären denke ich mal gute Voraussetzungen für die neue Hauptversion geschaffen, und man kann diese ganzen Schritte auch wirklich Schritt für Schritt gehen, ohne das komplette Programm von jetzt-auf-eben "anders" zu haben. Die [zusätzlichen] Firebird-Komponenten wären das Sahnehäubchen, aber ich glaube die paar (Milli-) Sekunden leistungssteigung stehen -im Moment zumindest- in keinem Verhältnis zur der vorteilhaften Dreigleisigkeit über ADO/ODBC. Später aber gerne!

@Delphi.Narium: Danke für den Link zum komprimieren und reparieren der Datenbank. Dieses Verfahren setzen wir afaik bereits ein, dies scheitert jedoch tatsächlich in der Praxis daran, dass TADOConnection die Datenbankverbindung zum Reparieren nicht aufbauen kann, weil die Datenbank gerade defekt ist. Naja, Offtopic, anderes Thema.

Delphi-Quellcode:

    v := CreateOLEObject('JRO.JetEngine');
    try

      try
        // Datenbank komprimieren, diese wird unter neuem Dateinamen gespeichert
        V.CompactDatabase('Provider=Microsoft.Jet.OLEDB.4.0;Data Source=' + _DB,
                          'Provider=Microsoft.Jet.OLEDB.4.0;Data Source=' + CompressedFileName);
      except
        Result := False;
      end;

Zur Offline-Erkennung der Clients hatte ich ein ähnliches System wie @Hobbycoder, allerdings war es zuletzt am häufigsten vorgekommen, dass genau eben DURCH das Schreiben dieses "Status" in die Datenbank diese "zerstört" wurde. Gefühlsmäßig behaupte ich mal, dass die Existenz der MeineDatenbank.ldb - Datei schon ein guter Indikator ist, ob die Datenbank gerade gewartet werden kann (wenn sie existiert, dann nein). In der Regel läuft das Löschen der Datei -soweit ich mich erinnere- auch relativ zuverlässig. Klar kann "mal" ein Client abstürzen und sie wird nicht gelöscht (?), aber der nächste Client korrigiert das afaik, sobald dieser sich dann trennt. Somit sollte zumindest 1x die Woche eine "Offline-Wartung" technisch erkennbar und machbar sein - mit MS SQL oder Firebird hoffentlich wirkliche nie mehr notwendig!


Ich hake jetzt mal "offene Frage" ab, und bedanke mich herzlich bei allen Teilnehmern für die guten Beiträge, die meiner Meinung nach sehr gut zu einer klaren Richtung mit einem umsetzbaren Fahrplan geführt haben!

Zu der "Problematik", dass ich mir den Connection-String nun pro Benutzer/PC mit ggf. ServerIP, Name und PASSWORT merken muss, gibt es ja im Forum zahlreiche Beiträge, ebenfalls mit dem Verweis auf den Mixed-Mode, Trusted-Login etc., bei denen Windows ja einfach die Anmeldedaten (bzw. das Token) des aktuellen Benutzers verwendet. Falls ihr gerade ein "Best-Practise" zur Hand habt, wie der Benuzter die Datenbankverbindung an sinnvollsten (einfach!) konfiguriert,
1) ohne den kompletten TAdoConnection.ConnectionString-Assistenten zu verwenden
2) (Sicheres?) abspeichern dieses Strings trotz/mit Benutzername/Passwort?
bin ich natürlich total dankbar dafür, ich scheue mich aber natürlich auch nicht davor, brav die SuFu zu verwenden.

Nochmals Danke!