DB-Funktionen von MSSQL in Oracle nachbauen

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

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