Announcement

Collapse
No announcement yet.

Portierung von Paradox nach MS SQL-Server, wie?

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Portierung von Paradox nach MS SQL-Server, wie?

    Hallo Zusammen,

    Ich möchte eine größere Anwendung von Paradox nach SQL-Server portieren, da sowohl Paradox als auch die BDE schon seit längerer Zeit nicht mehr weiterentwickelt werden. In Sachen Datenbank bin ich (leider?) auf den Microsoft SQL-Server festgelegt.
    Meine Frage an Euch wäre nun, wie ich den SQL-Server am besten von Delphi 7 aus anspreche. Bisher favorisiere ich ADO, jedoch habe ich auch schon an einigen Stellen gelesen, dass dies ein Auslaufmodell sei.
    Im Forum habe ich bereits einige hilfreiche Beiträge zu diesem Thema gelesen. Mich interessiert jedoch vor allem der Aspekt des Portierungsaufwands, da das Projekt sehr umfangreich ist.
    Für alle Antworten im Voraus vielen Dank!

  • #2
    Hallo!<br>
    MS SQL ist KEIN leider. Funktioniert einfach nur gut und ist schön schnell.<br>
    --Mich interessiert jedoch vor allem der Aspekt des Portierungsaufwands, da das Projekt sehr umfangreich ist<br>
    Unter SQL funktionieren einige Dinge komplett anders, als unter einer Filedatenbank. Dinge wie scannen oder positionieren von Datensätzen sind unter SQL nicht die beste (schnellste) Wahl. Je mehr dein PDW System mit SQL Statements arbeitet, desto schneller die Umstellung. Wir haben die gleiche Arbeit mal von PDW => Interbase gemacht. War ein irrer Spass....<br>
    Sehr viele kleine Kniffe in PDW haben uns bei der Umstellung das Leben sehr schwer gemacht.<br>
    Momentan arbeiten wir mit einer mehrschichtigen Architektur, wie sie hier z.B. im COM Ordner behandelt wird. Das würde ich mir mal ansehen, BEVOR man an die Umstellung geht. Wenn dann gleich richtig....<br>
    BYE BERN

    Comment


    • #3
      Hallo Philipp,

      ADO ist <b>kein</b> Auslaufmodell, solange du noch mit D7 (bzw. für die Win32-Schiene) entwickelst.

      ADO ist <b>ein</b> Auslaufmodell (bzw. wird nicht direkt optimal unterstützt) wenn Du für .NET-Entwickelst (sei es nun D8 oder C#, VB.NET).

      Der Portierungsaufwand kann so nicht über den Daumen gepeilt werden, da es darauf ankommt wie dein Programm entwickelt wurde.

      - Ist die Datenbankschnittstelle über alle Units verteilt (schlecht)?<br>
      - Wird eine Datenbankabstraktionsschicht verwendet (gut)?<br>
      - Werden DB-Sensitive Controls verwendet (evtl. Aufwendig)?<br>
      - Werden sehr viel Datenbankspezifika verwendet?

      Also je nach Programm dauert die Portierung 1 Tag - mehrere Mannmonate. Und wenn Du portierst solltest Du die DB-Schnittstelle so kapseln, das Du auch relativ einfach weitere DB's unterstützen könntest (Stichwort: Bridge-Pattern)

      Comment


      • #4
        Hallo Philipp,<p>
        bevor Du anfängst, solltest Du zwingend das Ado-Buch von Andreas Kosch kaufen. Uns hat es damals bei einer Umstellung von InterBase/BDE auf MSSQL/Ado sehr geholfen. Der Teufel liegt hier nämlich im Detail.<p>
        Unsere alte Anwendung hat fleißig vom Table-Objekt und den Befehlen wie Locate oder Findkey Gebrauch gemacht. Hier ist der SQL-Server wesentlich konsequenter und nicht alle Funktionen standen zur Verfügung (weil sie einfach keinen Sinn machen). Da mussten wir viel Zeit investieren, aber es hat sich gelohnt!<p>
        Schöne Grüße, Mario Noac
        Schöne Grüße, Mario

        Comment


        • #5
          Hallo nocheinmal,

          Vielen Dank erstmal für Eure schnellen und kompetenten Antworten!
          Mich würde noch eure Meinung zu dbExpress interessieren! Habt ihr damit schon Erfahrungen gemacht, und wenn ja, wie waren die?

          Auch hier vielen Dank fürs Antworten

          Comment


          • #6
            Hallo,

            &gt; ....wie waren die?

            die Antwort auf diese Frage hängt davon ab, mit welcher Datenbankversion (Treiber) und welchen Datentypen gearbeitet wird. In der <i>readme.txt</i> zu Delphi 7 ist eine lange Auflistung aller Einschränkungen, die man nicht ignorieren darf (d.h. in der Datenbank dürfen bestimmte Datentypen nicht verwendet werden). Die für die unterstützten Datenbanken gemeinsam genutzten dbExpress-Komponenten unterliegen dem Prinzip des kleinsten gemeinsamen Nenners, so dass zwangsläufig nicht jedes Feature eines bestimmten SQL Servers unterstützt wird. Außerdem spielt es eine Rolle, ob es sich um eine klassische Client/Server-Anwendung oder um eine (zustandslose) Three-Tier-Anwendung handelt.

            Vor jedem Start eines dbExpress-Projekts sollte daher ein Last-Test den vollen Wertebereich aller benötigten Datentypen testen.

            Comment

            Working...
            X