DB-Funktionen von MSSQL in Oracle nachbauen

[Delphi.Narium]

Frage:

In welcher Form liegen die alten SQLs vor?

Alle irgendwie einzeln?

In einer Textdatei und der Anwender sucht sie sich da raus?

Im Quelltext irgendeiner oder mehrere Anwendung(en)?

Bin in der Vergangenheit recht gut damit gefahren, die SQLs in 'ner Datenbanktabelle vorzuhalten.

Da kann man dann eine Spalte für die MSSQL-Syntax machen, eine Spalte für die Oracle-Syntax u.s.w. für alle zu unterstützende Datenbanken.

Jede Zeile der Tabelle hat 'ne eindeutige ID.

Die Software, die die SQLs braucht, kennt dann nur noch diese ID und weiß um welche Datenbank es sich handelt.

Soll also ein SQL ausgeführt werden, holt sie sich per ID und Info zur verwendenen Datenbank das passende SQL aus der Tabelle, versorgt es ggfls. mit Parametern, und führt es aus.

Oder man macht für jede Datenbank 'ne View, die dann nur die ID und die SQL-Spalte der entsprechenden Datenbank liefert. Dann muss die Software nur die ID wissen, gegen welches DBMS sie dann läuft, ist für die Software "wurscht". Sie sieht nur, was sie konkret benötigt.

Oder man macht je DBMS eine Tabelle und nutzt dann dort immer das datenbankspezifische Befüllscript.

Ist eigentlich recht pflegeleicht und wenn man das einmal in 'ner Anwendung drinne hat, muss die Anwendung bei Änderungen am SQL nicht jedesmal angepasst werden.

Wird 'ne weitere Datenbank unterstützt, bekommt die Tabelle 'ne weitere Spalte und die Software kann dann die SQLs dort herholen.

Die Pflege der Tabelle kann man dann jemandem anvertrauen, der sich in der SQL-Welt gut auskennt und weiß, wie man die einzelnen Datenbankspezialitäten am besten übersetzt bzw. wie man es hinbekommt, dass sich die SQLs zwischen den einzelnen Datenbanken nicht mehr so gravierend unterscheiden.

Im Idealfall ist das für die die SQLs nutzende Software absolut transparent.

Der erstmalige Aufbau eines derartigen Konzeptes kann schon ziemlich viel Arbeit sein, die sich aber in der Regel auch recht schnell amortisiert.

[jobo]

1) Implizite Datumskonvertierung geht leider auch in Oracle, das ist nur eine Frage der passenden locale settings in der session. Ich würde versuchen das alles zu finden und durch explizite Konvertierung mit Maske auszutauschen. Aber notfalls tut es auch die adaptierte Standardeinstellung für Datumsmaske im client oder sogar in der session.

2) Oracle + Joins würde ich ebenfalls in die Tonne treten, das ist ja auf jeden Fall etwas, womit Du nur gewinnen kannst. Die Standard Join Syntax ist kompatibler, mächtiger und bestimmt seit einiger Zeit auch sicher besser supported (Bugs, Optimizer, …)

Hier sind ein paar Links, die Idee eines Kompatibilitätspackages findet man im Netz interessanter Weise nicht.
https://www.oracle.com/database/tech...to-oracle.html
(wie das Teil mit den MS Funktionen umgeht, weiß ich nicht)

Für 11
https://www.oracle.com/webfolder/tec...server_otn.htm
Auch hier brauchst Du ja nur einen Teil..

http://www.sqlines.com/sql-server-to...-sql-functions
Wie vollständig das ist, schwer zu sagen, isnull() fehlt z.B.

Angenommen, Postgres ist nahe an Oracle (spätestens mit compatibility extension) kann man auch mal hier drauf schauen:
https://severalnines.com/database-bl...ou-should-know
https://wiki.postgresql.org/wiki/Mic...by_Ian_Harding

[Jumpy]

Zitat von Delphi.Narium:

Frage:
In welcher Form liegen die alten SQLs vor?

In einer (lokalen?) Datenbank, die aber nicht bei uns liegt. Ist vllt. ein Ansatz den man auch verfolgen kann, ob man nicht die gespeicherten SQL-Statements selber irgendwie updated. Aber dazu muss ich da erst mal Zugang zu bekommen.

Zitat von Jobo:

die Idee eines Kompatibilitätspackages findet man im Netz interessanter Weise nicht.

Das ist genau das, was ich auch gesucht habe und nicht finden konnte. Darum der Thread hier, da ich gehofft habe, dass zumindest andere Suchbegriffe als Stichworte durch eure Hilfe aufkommen. Aber wenn du da nichts finden kannst, beruhigt mich das zumindest in soweit, als das ich nicht zu blöd zum googlen bin .
Danke für die Links, da schau ich mal ob Zwischendurch was genannt wird, was mir einen Tip gibt.

[jobo]

Ich vermute, sowas gibt es nicht, weil es sich nicht "lohnt". Das liegt vielleicht einerseits an der geringen Zahl von nicht passenden Funktionen, andererseits daran, dass die Migration Software von Oracle persönlich existiert und ihre Sache vielleicht gut macht. Also wirklich SQL umschreibt, bspw., Type Mapping macht usw.
Richtig verstanden?:
Die Statements befinden sich in einer DB, also nicht als Views, sondern als Datensätze in Textform?
Das Problem an der Datenbankmigration dürfte sein, dass sie nur Dinge konvertiert, die Bestandteil des DM sind, also DB Objekte. Also müsste man die Statements m.E. am besten in Views umwandeln. Dann die Konvertierung anwerfen und die Views später wieder zurück führen.

[mschaefer]

Das mit den Views wäre auch mein Weg, selbst wenn die bei 1000 Stück dann Nummern bekommen würden. Damit bekommt man auf dem Oracle Server die Oracle Views und auf dem MS-SQL-Server die Gegenstücke. Mit diesem Konstrukt kann man perfekt Programmtests fahren und hat bis zur Umstellung einen Fallback.

Da Migration so meine Brot mit Beilagen-Beschäftigung ist, habe ich mir eine Datebank mit alten und neuen SQL-Statements angelegt. Gleichzeitig bekommt jedes Memo-Feld (SQL_Ora, SQL,MSSQL) jeweils ein Boolean Feld "Aktuell" und ein Datums-Feld zugeordnet "Letzte Änderung". Irgendwann hat man nämlich das Problem das die SQL-Statements der neuen Datenbank überarbeitet werden und dann ist dieses Statement das alleinig aktuell. Das Gegenstück bekommt sein Aktuell= true nur, wenn es auch mit geändert wurde, was aus Zeitgründen / Sinngründen schonmal entfallen kann.

Grüße in die Runde

Martin

[Jumpy]

Zitat von jobo:

Richtig verstanden?:
Die Statements befinden sich in einer DB, also nicht als Views, sondern als Datensätze in Textform?

Genau.Die SQL-Statements liegen in Textform in einer Datenbank vor, die mit dem ganzen Kram nichts zu tun hat und zu der externen Auswertungs/Reporting Software gehört.

[p80286]

Zitat von Jumpy:

Genau.Die SQL-Statements liegen in Textform in einer Datenbank vor, die mit dem ganzen Kram nichts zu tun hat und zu der externen Auswertungs/Reporting Software gehört.

Und die kann nicht mit Oracle umgehen?
Ich bin bisher davon ausgegangen, daß es sich um selbstgebasteltes handelt. Gibt es da vllt. eine Exportfunktion sodaß man von einem MS-Reporter in einen Oraclereporter übertragen könnte?

Gruß
K-H

[Delphi.Narium]

Wenn die SQLs in 'ner Datenbank liegen, könnte man ja zuerst mal schauen, dass man einen Export der entsprechenden Tabelle(n) bekommt.

Hab' sowas mal mit Hilfe eines Delphiprogrammes ansatzweise gemacht, sinngemäß sowas:

Delphi-Quellcode:

begin
  querySQL.Close:
  querySQL.SQL.Text := 'select * from SQL-Tabelle';
  querySQL.Open:
  while not querySQL.EoF do begin
    queryTest.Close;
    queryTest.SQL.Text := querySQL.FieldByName('SQL-Spalte').AsString;
    try
      queryTest.Open;
    except
      on e : EDatabaseError do begin // Hier den für die jeweils genutzt Datenbankkomponente am besten geeigneten Fehlertyp nehmen.
        LogFile.Add(Format('Fehler ins SQL Nr.: %d',[querySQL.FieldByName('SQL_ID').AsInteger);
        LogFile.Add(querySQL.FieldByName('SQL-Spalte').AsString);
        LogFile.Add(e.Message);
        // Hier ggfls. noch alle Infos mit ausgeben, die mit der Exception EDatabaseError (o. ä.) geliefert werden.
      end;
    end;
    querySQL.Next;
  end;
  queryTest.Close;
  querySQL.Close:
end;

Damit hat man dann schonmal ein Verzeichnis der SQLs, die überhaupt ein Problem machen könnten.

Wenn man sich die SQL-Tabelle um 'ne Spalte Ok erweitert, könnte man sich dort auch 'nen Schalter setzen, der im Try hinter dem Open auf True gesetzt wird und in Except auf False.
Dann kann man hierüber auch 'ne Auswertung über die Fehlermenge machen und bei wiederholtem Aufruf der Routine nach 'ner Fehlerbehebung prüfen, wie groß die Restmenge der fehlerhaften SQLs ist.
Natürlich könnte man sich auch die Fehlermeldung in 'ne Fehlerspalte der SQL-Tabelle schreiben, darüber wären dann auch Auswertungen möglich, um zu prüfen, welche Fehlersorte wie oft vorkommt. Dann kann man sich einzelne Fehler raussuchen, die man erstmal überall behebt und muss sich nicht einzeln um jedes SQL kümmern.
Hier ist halt ein bisserl Kreativität gefordert, um das jeweils beste Vorgehen für die konkrete Situation zu finden.
Für 'nen ersten Überblick könnte es aber einfacher sein, als erst für alles Views zu erstellen und die dann automatisch migrieren zu lassen und dann aus den Views wieder SQLs zu machen.

Wobei:

Wenn man einmal die Views erstellt hat und migriert hat, dann kann man die doch eigentlich weiter nutzen. Ob die Fremdsoftware nun in ihrer SQL-Tabelle jeweils ein select * from view findet oder irgendein (mehr oder weniger) komplexes SQL, dürfte eigentlich egal sein. Wichtig ist doch "nur", dass die in der SQL-Tabelle befindlichen Abfragen die korrekte Ergebnismenge liefern.

Die Frage die sich dabei halt stellt: Will man diese "Unmenge" von Views wirklich dauerhaft in seinen System haben?

[p80286]

Augenblick mal, Ich gehe davon aus daß diese Reportsoftware es ermöglicht sich eine Abfrage mit anschließender Ausgabe zusammen klicken kann. Irgendwann bastelt dann irgendjemand was neues und dann?
Da muß dann eine Oracle-kompatible Bib zur Verfügung stehen oder die neu erstellte Abfrage muß dann nochmal nachbereitet werden, was auch für Modifikationen gelten würde.

Oder bin ich da auf einem ganz falschen Dampfer?

Gruß
K-H

[Delphi.Narium]

Nein, prinzipiell bist Du auf dem richtigen Dampfer, aber:

Zitat von Jumpy:

Der Kunde setzt nun aber zu Auswertungs-Zwecken tausende (keine Übertreibung!) selbstgebastelte SQL-Statements ein und in diesen finden sich dann auch klassische SQL-Funktionen von MSSQL, ich sag mal als Beispiel die Funktion ISNULL.

und

Zitat von Jumpy:

Wir möchten jetzt vermeiden tausende SQL-Statements anzupacken und umschreiben zu müssen

Und es geht halt momentan darum, ob es möglich ist, den durchaus möglichen, aber nicht unerheblichen, manuellen Aufwand zu reduzieren.

Es wird also ein Weg gesucht, der das

Zitat von p80286:

oder die neu erstellte Abfrage muß dann nochmal nachbereitet werden, was auch für Modifikationen gelten würde.

möglichst verhindert oder zumindest den Umfang wesentlích verkleinert.

Sprich: Kommen wir irgendwie mit vertretbarem Aufwand vom ansonsten bestehenden "Mengenproblem" weg?