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.

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

Zitat von Jumpy:

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

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

Zitat von Jumpy:

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.

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

Zitat von Jumpy:

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?

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.

Zitat von Bernhard Geyer:

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.

Zitat von Jumpy:

Wir leben leider nicht auf der grünen Wiese.

Kenn ich

Zitat von Jumpy:

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 von Jumpy:

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

Zitat von DasWolf:

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.

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