DB-Funktionen von MSSQL in Oracle nachbauen

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

[Jumpy]

Zitat von Delphi.Narium:

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

Genau das ist was ich erreichen will.

Klar kann ich alle SQL-Statements des Kunden updaten und darin ISNULL( durch NVL( ersetzen, da die Syntax beider Funktionen ansonsten recht gleich ist und schon hab ich ein Problem gelöst, wenn man mal hofft das ISNULL( nicht aus irgendeinem Grund irgendwo als String steht oder so.

Aber bei Funktionen mit komplett anderer Syntax sehe ich als Lösung derzeit nur, die Funktion nachzubauen:

DateAdd([year/month/day],anzahl,Datum1) kann man nicht sinnvoll durch irgendein update via SQL-Statement durch was anderes ersetzen, vor allem, da das ja beliebig komplex werden kann und man da schon halb auf dem Weg zum Parser-Bau ist.

Da ist es doch einfacher sich eine Databasae Function DateAdd selber zu bauen und da wird es bei uns wohl drauf hinauslaufen, weil im Netzt da nichts fertiges zu finden ist.

[Delphi.Narium]

Daher auch mein Vorschlag, erstmal die SQLs in 'ner Schleife durchprobieren und die Fehlermeldungen sammeln.

Dann kann man schauen, was am Häufigsten vorkommt.

Lautet die Meldung halt dahingehend, dass IsNull nicht existiert, kann man schonmal hergehen, in dem Statement ein queryTest.SQL.Text := Replace(queryTest.SQL.Text,'IsNull(','Nvl'); machen.

Hat man hier schon einen "Erfahrungsschatz" gesammelt, könnte man dieses Replace (oder was auch immer erforderlich ist) vor dem Ausführen des SQLs machen und bei erfolgreicher Ausführung in der SQL-Tabelle schonmal aktualisieren.

Und IsNull wird nur in den Statements ersetzt, in denen die Fehlermeldung hergibt, dass IsNull ein Problem macht.
Damit sinkt dann die Wahrscheinlichkeit, irgendwas SQL-typisches versehentlich in Zeichenfolgen zu ersetzen.

Dadurch kann man durch wiederholtes Ausführen der Routine und jeweilige Ergänzung durch neue Erkenntnisse, die SQL-Tabelle auf einen etwas orcalekonformeren Stand bringen. Mit ein bisserl Glück muss man dann nicht mehr an eine Unmenge von SQLs ran, sondern nur noch an die, bei denen sich die Syntax grundlegend unterscheidet. Das dann zu "reparieren" dürfte immer noch mehr als reichlich Arbeit werden.

Kennst Du dasda schon?
https://www.oracle.com/database/tech...to-oracle.html
https://smarttechways.com/2017/07/05...ver-to-oracle/
http://oracle-mssql-dba.blogspot.com...racle-10g.html

Sind nur "Fundstücke" über migration mssql oracle und dort dann gesagt, dass man keine Ergebniss zu MySQL haben möchte also dashier (hoffentlich): https://www.google.com/search?q=migr...e&start=0&sa=N

Keine Ahnung, ob da was brauchbares bei ist oder es eventuell auch noch was "besseres" geben könnte.

[Jumpy]

Mal eine Frage zu Oracle-Packages:

Wenn ich die gewünschten Funktionen nachbaue in einem Package, dann muss ich sie im SQL-Statement scheinbar mit dem Package-Namen aufrufen, also z.B. meine neue ISNULL-Funktion wäre dann aufzurufen als:

Select MYPACKAGENAME.ISNULL(NULL,'Ersatz') From DUAL

Kann man das irgendwie so hinkriegen, dass man den Packagename nicht davor angeben muss, denn das würde mir in meiner Situation nicht helfen. Was ich so beim googlen finde, kann man das nur beim Oracle STANDARD Package weglassen, wo Oracle eigne Funktionen mit ausliefert.

Ich habe nämlich festgestellt, das Overloading nur in Packages geht, nicht in Stored Functions direkt, da müssen Funktionsnamen eindeutig sein, drum wäre es schon schön Packages verwenden zu können.

[Delphi.Narium]

Nach der Aussage dort https://asktom.oracle.com/pls/apex/f...:4743759113231 geht es wohl nicht.

Oder eventuell hier: https://stackoverflow.com/questions/...kage-in-pl-sql

Hatte eigentlich gedacht, dass es gehen müsste. Wäre da dann wohl auch erstmal auf die Nase gefallen.

Eventuell hier doch noch was zu finden?

https://www.google.com/search?q=orac...utf-8&oe=utf-8