DB-Funktionen von MSSQL in Oracle nachbauen

[Jumpy]

Hallo,

wir haben ein Fremd-Programm, dass mit verschieden DBMS zusammenarbeiten kann übernommen und dabei von MSSQL nach Oracle migriert. Läuft soweit alles.
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.
Wir möchten jetzt vermeiden tausende SQL-Statements anzupacken und umschreiben zu müssen und würden gerne diese Funktionen in Oracle als eigene DB-Function nachbauen, also im Beispiel eine Function "ISNULL" schreiben, die dann intern mit Oracles "NVL" arbeitet.

Deswegen nun die Frage: Hat das vielleicht schon mal wer gemacht, gibt es da vllt. fertige Scripte um die gängigsten MSSQL-Function in Oracle nachzubauen.

[mkinzler]

Vielleicht so ein Ansatz wie bei Fyracle. Also ein (Proxy-)Server, der die Abfragen umwandelt und die angepassten Abfragen dann an das eigentliche DBMS weiterleitet.

http://sqlrelay.sourceforge.net/documentation.html

[Bernhard Geyer]

Zitat:

Zitat von Jumpy (Beitrag 1464653)

wir haben ein Fremd-Programm, dass mit verschieden DBMS zusammenarbeiten kann übernommen und dabei von MSSQL nach Oracle migriert. Läuft soweit alles.

Beileid. Aber wenn man meint das zu müssen ... (OK, war jetzt Off-Topic)

Zitat:

Zitat von Jumpy (Beitrag 1464653)

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.

Also habt ihr doch nicht Migriert. War euch nicht im Vorfeld klar das genau sowas auch zu einer Migration gehört?

Zitat:

Zitat von Jumpy (Beitrag 1464653)

Wir möchten jetzt vermeiden tausende SQL-Statements anzupacken und umschreiben zu müssen und würden gerne diese Funktionen in Oracle als eigene DB-Function nachbauen, also im Beispiel eine Function "ISNULL" schreiben, die dann intern mit Oracles "NVL" arbeitet.

Habt ihr wirklich zu eine 13 Jahre alten Oracle-Version gewechselt? (Es steht Oracle 11 am Ticket)

Hintergrund: Auch Oracle kann nicht dem SQL-Standard sperren und mit neueren Versionen (z.B. 18 als Long-Support-Version) lösen sich evtl. einige der Probleme in Luft auf, da Oracle dann evtl. mehr 1:1 Gegenstück zu solchen MS SQL Server Funktionen hat.

[p80286]

Wie wäre es mit einer Übersetzungssoftware replace(msstatement,oraclestatement)? Beide Systeme sind unterschiedlich, dann sind die Scripte es auch!
Hätte nebenher den Vorteil der Übersetzer wäre auch für andere Systemwechsel einsetzbar.

Gruß
K-H

[Bernhard Geyer]

Zitat:

Zitat von Jumpy (Beitrag 1464653)

wir haben ein Fremd-Programm, dass mit verschieden DBMS zusammenarbeiten kann übernommen und dabei von MSSQL nach Oracle migriert. Läuft soweit alles.

Auch wenn es OT ist.
Wieso macht man sowas?
In unserem Umfeld migriert man eher von Oracle weg, als nach Oracle.
Hat in euren Umfeld Oracle einen Unschlagbaren Vorteil, welche (wegen der scripts) doch sehr aufwendigen und teure Migration rechtfertigen würde?

[Jumpy]

Wir leben leider nicht auf der grünen Wiese.

Wir haben die Server und die Lizensen für Oracle und da auch ~20 Datenbanken für ~50 Kunden mit der Software am laufen. Die Umstellung auf Oracle ist auch normalerweise kein Problem und deswegen stellen wir darauf um, wenn der Kunde bisher selbstgehostet auf MSSQL unterwegs war und zu uns wechselt. Das geht auch rechtg problemlos, mit den Migration-Tools des Softwareherstellers.

Ist halt jetzt das erste mal, das ein Kunde sein eigenes Auswertungstool weiterhin mit seinen ganzen selbst gemachten Abfragen benutzen will und der Vertrieb, wie das nun mal so ist, gesagt hat, dass das natürlich weiterhin möglich sein wird :).

Zur alten Oracle Version für die noch ältere Software:
Die Oracle-Version wird von der Fremdsoftware vorgegeben 10i bis 12? ist derzeit supported und wird was man so hört nicht mehr neuer werden, da die mittlerweile auf PostgreSQL schielen. Wenn das mal soweit ist und stabil ist und wir uns das KnowHow angeeignet haben, werden wir da bestimmt mit gehen, allein schon aus Kostengründen.

[DasWolf]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1464656)

Hintergrund: Auch Oracle kann nicht dem SQL-Standard sperren und mit neueren Versionen (z.B. 18 als Long-Support-Version) lösen sich evtl. einige der Probleme in Luft auf, da Oracle dann evtl. mehr 1:1 Gegenstück zu solchen MS SQL Server Funktionen hat.

ISNULL ist nicht der SQL-Standard und wird in ORACLE auch keine Verwendung finden.
ISNULL ist SQL-Server spezifisch und NVL ist Oracle-spezifisch.

COALESCE ist der SQL-Standard und funktioniert bei beiden DBMS.

[Bernhard Geyer]

Zitat:

Zitat von Jumpy (Beitrag 1464759)

Wir leben leider nicht auf der grünen Wiese.

Kenn ich :-)

Zitat:

Zitat von Jumpy (Beitrag 1464759)

Wir haben die Server und die Lizensen für Oracle und da auch ~20 Datenbanken für ~50 Kunden mit der Software am laufen.

Wir können eigentlich auch Problemlos zwischen diversen DBMS-Systemen zwitschen.
Man darf halt nicht vergessen zu Fragen bzw. darauf hinzuweisen das es nur diese SW-Teil betrifft und "Hingestrickte" eigene Abfrage in eigenregie umgestellt werden müssen.

Zitat:

Zitat von Jumpy (Beitrag 1464759)

... und der Vertrieb, wie das nun mal so ist, gesagt hat, dass das natürlich weiterhin möglich sein wird :).

[Bernhard Geyer]

Zitat:

Zitat von DasWolf (Beitrag 1464762)

COALESCE ist der SQL-Standard und funktioniert bei beiden DBMS.

Coalesce war bei uns einer der Gründe das wir mit neueren Versionen der Anwendung definitiv kein alte Oracles mehr unterstützen, welche kein Coalesce können.

[himitsu]

ISNULL als Funktion() oder als Operator?

Postgres kennt auch sowas (x IS NULL, x IS NOT NULL, x ISNULL und x NOTNULL),
aber der Operator ließe sich im SQL-Export/Backup ja problemlos String-Replacen,
anstatt unnötig aufwändig diese Funktionen nachzubauen.

"ISNULL(" -> "COALESCE("
"NOT ISNULL" -> "IS NOT NULL"
"NOTNULL" -> "IS NOT NULL"
"ISNULL" -> "IS NULL"

Oracle kann kein COALESCE?

Zitat:

COALESCE ist der SQL-Standard und funktioniert bei beiden DBMS

klang so, als wenn wenigstens das ging

[Jumpy]

Zitat:

Zitat von himitsu (Beitrag 1464783)

ISNULL als Funktion() oder als Operator?

Als Funktion ala "Wenn das Feld Null ist dann ersatzweise dies hier".

ISNULL war jetzt auch nur Beispielhaft genannt.

[jobo]

Ich würde ein separates Package bauen, wo alle MS-SQL Funktionen (Prozeduren werden es wohl nicht sein) angelegt werden, die man braucht.
Das Teil dann Public setzen in der Hoffnung, dass nichts kollidiert -wenn ja, hat man vielleicht ein schlimmeres Problem- und dann muss der Kram laufen.
Das geht natürlich so wirklich nur für Funktionen, nicht für SQL Befehle, sagen wir mal wie z.B. - connect by prior von Oracle hier, kenne aus dem Stand keine derartigen MSSQL Geschichten.
Es gibt ja vielleicht auch diverse "Success" Stories, in denen solche Compatibility Packages bereits entstanden sind, einfach mal githuben oder auch so in der Wildnis nach solchen Geschichten suchen. Nicht zuletzt die Hersteller selber blasen ja gern jede derartige Nummer zu den genannten Stories auf und helfen dem Kunden ggf sogar dabei.

[jobo]

Kleiner Denkfehler, Public bedeutet ja nicht, dass der Package Name obsolet ist.
Also entweder gleich separate (eigenständige) Functions oder die Package Functions vielleicht mit Synonyms versehen.

Oder halt die MS-SQL spezifischen Functionsaufrufe mit <oracleersatzpackagename>.<ersatzfunktion> ersetzen.
Bei einer endlichen Anzahl N von fehlenden Ersatz Funktionen, wäre es auch nicht mehr als N mal Suchen /Ersetzen im ursprünglichen MS Code.

[Delphi.Narium]

Package bauen war auch mein erster Gedanke. Man hat braucht nur eine Stelle, an der man ergänzen, erweitern, Fehler korrigieren muss. Synonyme auf die einzelnen Routinen des Packages. Danach sollte die ganze "Übersetzungsgeschichte" recht transparent und pflegeleicht sein.

Im Idealfall werden vom Kunden, wenn er denn mal an die "MSSQL-Erbstücken" ran muss, diese auf Oracle (besser SQL-Standard) umgeschrieben, so dass das "Übersetzungspackage" und die Synonyme im Laufe der Zeit obsolet werden.

Andererseits: Wenn Ihr sowieso Richtung Postgres schielt, wäre eventuell die Packagelösung die sinnvollste.

Jetzt baut Ihr eins für Oracle. Später eins für Postgres.
(PostgreSQL 7.3.21 Documentation - Porting from Oracle PL/SQL)

Wenn das gut gelingt ist es für die Kunden-MSSQL-Altlast jetzt bei Oracle, später bei Postgres, transparent und Ihr müsst euch um dass, was der Kunde bisher gezaubert hat und in Zukunft noch zaubern wird, keinen Kopp machen. Und wenns irgendwann mal wieder zurück nach MSSQL geht, muss sich auch keiner Gedanken machen.

Viel blöder find ich in diesem Zusammenhang eher so Sachen wie SQL TOP, LIMIT or ROWNUM, die kann man nicht "so mal eben" durch 'ne Ersatzfunktion "überbügel", ohne dass es jemand merkt.

Da muss man dann wohl die passenden SQLs schlimmstenfalls je zu nutzendem DBMS separat vorhalten. Das ist nicht wirklich witzig und ziemlich pflegeaufwändig.

[Jumpy]

@Jobo: Es geht nur um Funktionen.

Die Package-Lösung klingt sinnvoll. Ich versuche mal weiter im Netz was fertiges dazu zu finden, dass man ggf. anpassen kann. Wenn das nichts wird, bauen wir uns da halt was eigenes und erweitern das nach und nach.


Mir sind mittlerweile in den SQL-Statements auch ein paar andere Schoten aufgefallen, wo es wahrscheinlich nicht anders geht, als die betroffenen Statements anzupacken, aber vielleicht hat da ja auch noch einer eine Idee:

1) Ein Datum als String wird in MSSQL zum Teil automatisch in ein Datum konvertiert und kann für Vergleiche genutzt werden. In Oracle brauch ich da immer ein To_Date() drum.

2) Zum Teil alte SQL-Syntax bei Joins mit den (+) Geschichten. Da dürfen bei Oracle solche Felder nicht im Zusammenhang mit dem "Or" oder "in" Operator benutzt werden. War mir neu, benutz die alte Syntax aber selbre auch kaum. Bei MSSQL scheint das wohl zu gehen. Sinngemäßes Beispiel:

SQL-Code:

Select irgendwas From Tabelle1, Tabelle2
Where
  Tabelle1.Feld = Tabelle2.Feld(+)
  and (Tabelle2.Nachname(+)='Müller' or Tabelle2.Nachname(+)='Maier')

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

Zitat von Delphi.Narium (Beitrag 1464826)

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:

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 :-D.
Danke für die Links, da schau ich mal ob Zwischendurch was genannt wird, was mir einen Tip gibt.

[mschaefer]

Moin zusammen,

einiges kann man per Oracle-Function nachbauen. Coalesque gibt es meine erachtens auch bei 11g schon, aber das waere auch ueber eine Funktion kein Problem. Diese isnull Sachen gehen wahrscheinlich nicht nachzubauen. Es werden einem die Freuden der Migration daher einholen.

Grüße in die Runde

Martin

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

Zitat von jobo (Beitrag 1464848)

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:

Zitat von Jumpy (Beitrag 1464865)

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?:gruebel:
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:

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:

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:

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:

Zitat von Delphi.Narium (Beitrag 1464890)

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

Delphi-Quellcode:

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