![]() |
Datenbank: Oracle • Version: 11g • Zugriff über: versch.
DB-Funktionen von MSSQL in Oracle nachbauen
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. |
AW: DB-Funktionen von MSSQL in Oracle nachbauen
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.
![]() |
AW: DB-Funktionen von MSSQL in Oracle nachbauen
Zitat:
Zitat:
Zitat:
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. |
AW: DB-Funktionen von MSSQL in Oracle nachbauen
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 |
AW: DB-Funktionen von MSSQL in Oracle nachbauen
Zitat:
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? |
AW: DB-Funktionen von MSSQL in Oracle nachbauen
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. |
AW: DB-Funktionen von MSSQL in Oracle nachbauen
Zitat:
ISNULL ist SQL-Server spezifisch und NVL ist Oracle-spezifisch. COALESCE ist der SQL-Standard und funktioniert bei beiden DBMS. |
AW: DB-Funktionen von MSSQL in Oracle nachbauen
Zitat:
Zitat:
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:
|
AW: DB-Funktionen von MSSQL in Oracle nachbauen
Zitat:
|
AW: DB-Funktionen von MSSQL in Oracle nachbauen
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:
|
AW: DB-Funktionen von MSSQL in Oracle nachbauen
Zitat:
ISNULL war jetzt auch nur Beispielhaft genannt. |
AW: DB-Funktionen von MSSQL in Oracle nachbauen
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. |
AW: DB-Funktionen von MSSQL in Oracle nachbauen
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. |
AW: DB-Funktionen von MSSQL in Oracle nachbauen
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. ( ![]() 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 ![]() Da muss man dann wohl die passenden SQLs schlimmstenfalls je zu nutzendem DBMS separat vorhalten. Das ist nicht wirklich witzig und ziemlich pflegeaufwändig. |
AW: DB-Funktionen von MSSQL in Oracle nachbauen
@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') |
AW: DB-Funktionen von MSSQL in Oracle nachbauen
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. |
AW: DB-Funktionen von MSSQL in Oracle nachbauen
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. ![]() (wie das Teil mit den MS Funktionen umgeht, weiß ich nicht) Für 11 ![]() Auch hier brauchst Du ja nur einen Teil.. ![]() 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: ![]() ![]() |
AW: DB-Funktionen von MSSQL in Oracle nachbauen
Zitat:
Zitat:
Danke für die Links, da schau ich mal ob Zwischendurch was genannt wird, was mir einen Tip gibt. |
AW: DB-Funktionen von MSSQL in Oracle nachbauen
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 |
AW: DB-Funktionen von MSSQL in Oracle nachbauen
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. |
AW: DB-Funktionen von MSSQL in Oracle nachbauen
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 |
AW: DB-Funktionen von MSSQL in Oracle nachbauen
Zitat:
|
AW: DB-Funktionen von MSSQL in Oracle nachbauen
Zitat:
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 |
AW: DB-Funktionen von MSSQL in Oracle nachbauen
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:
Damit hat man dann schonmal ein Verzeichnis der SQLs, die überhaupt ein Problem machen könnten.
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; 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? |
AW: DB-Funktionen von MSSQL in Oracle nachbauen
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 |
AW: DB-Funktionen von MSSQL in Oracle nachbauen
Nein, prinzipiell bist Du auf dem richtigen Dampfer, aber:
Zitat:
Zitat:
Es wird also ein Weg gesucht, der das Zitat:
Sprich: Kommen wir irgendwie mit vertretbarem Aufwand vom ansonsten bestehenden "Mengenproblem" weg? |
AW: DB-Funktionen von MSSQL in Oracle nachbauen
Zitat:
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. |
AW: DB-Funktionen von MSSQL in Oracle nachbauen
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:
machen.
queryTest.SQL.Text := Replace(queryTest.SQL.Text,'IsNull(','Nvl');
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? ![]() ![]() ![]() Sind nur "Fundstücke" über ![]() ![]() Keine Ahnung, ob da was brauchbares bei ist oder es eventuell auch noch was "besseres" geben könnte. |
AW: DB-Funktionen von MSSQL in Oracle nachbauen
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. |
AW: DB-Funktionen von MSSQL in Oracle nachbauen
Nach der Aussage dort
![]() Oder eventuell hier: ![]() 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? ![]() |
Alle Zeitangaben in WEZ +1. Es ist jetzt 21:28 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz