Zum Inhalt springen
100% lokal

SQL-Dialect-Konvertierung

SQL zwischen PostgreSQL, MySQL, SQLite und SQL Server konvertieren.

Eingabe
Ausgabe

SQL-Dialect-Konvertierung

Fügen Sie eine für eine Datenbank geschriebene Abfrage ein und erhalten Sie sie für eine andere neu geschrieben. Der Konverterer deckt Zeilenlimit-Syntax, allgemeine Datums- und String-Funktionen, String-Verkettung, Bezeichneranführungszeichen und Spaltentpten über PostgreSQL, MySQL, SQLite und SQL Server ab – nützlich bei der Migration eines Projekts von MySQL zu PostgreSQL, beim Portieren eines Scripts von SQL Server zu SQLite oder beim Überprüfen, wie eine Abfrage in einem anderen System aussehen würde.

Quell-Dialect und Ziel-Dialect legen die beiden Enden der Konvertierung fest. Die Kontrollkästchen darunter aktivieren oder deaktivieren einzelne Konvertierungen: Bezeichneranführungszeichen normalisieren tauscht doppelte Anführungszeichen, Backticks und eckige Klammern gegen den eigenen Stil des Ziels; Zeilenlimit-Klausel konvertieren wechselt zwischen LIMIT, TOP und OFFSET…FETCH FIRST, ohne jemals einen Offset stillschweigend zu überspringen; Datums- und String-Funktionen konvertieren NOW()/GETDATE()/datetime('now'), LENGTH()/LEN(), SUBSTRING()/SUBSTR() und COALESCE()/IFNULL()/ISNULL() um; String-Verkettung konvertieren wechselt zwischen || und CONCAT()/+; Spaltentpten konvertieren ordnet SERIAL, AUTO_INCREMENT, IDENTITY(1,1), BOOLEAN, TEXT und TIMESTAMP-ähnliche Deklarationen ihren nächsten Entsprechungen zu. Kommentare behalten steuert, ob -- und /* */ Kommentare die Umschreibung überstehen.

Einige Konstrukte haben wirklich keine Entsprechung – PostgreSQLs RETURNING und ON CONFLICT oder MySQLs ON DUPLICATE KEY UPDATE – und anstatt eine Umschreibung zu vermuten, lässt das Tool sie an Ort und Stelle und listet sie in einem Warnblock auf, der der Ausgabe angehängt ist. Es schreibt Anweisungstext um, anstatt einen vollständigen Ausführungsplan zu analysieren. Überprüfen Sie das Ergebnis daher vor der Ausführung gegen eine echte Datenbank, insbesondere bei verschachtelten Subabfragen oder ungewöhnlicher Formatierung. Multi-Statement-Scripts funktionieren auch: Jede durch Semikolon getrennte Anweisung wird eigenständig konvertiert.

Alles läuft lokal in Ihrem Browser: Keine Abfrage, Tabellenname, Spaltenname oder Verbindungsstring wird jemals irgendwohin gesendet. Kopieren Sie das Ergebnis, laden Sie es als .txt-Datei herunter oder senden Sie die Ausgabe direkt zurück in die Eingabe, um einen weiteren Durchgang durchzuführen.

Häufige Fragen

Werden der SQL tatsächlich geparst oder erfolgt nur Textersetzung?
Der Konverterer schreibt bekannte Muster um – Zeilenlimit-Klauseln, allgemeine Funktionen, Verkettung, Bezeichneranführungszeichen und Spaltentpen – mit gezielten Textersetzungen anstelle eines vollständigen SQL-Parsers. Überprüfen Sie das Ergebnis daher immer vor der Ausführung gegen eine Datenbank.
Was geschieht mit Konstrukten, die es im Ziel-Dialect nicht gibt?
Sie werden an Ort und Stelle gelassen und in einem Warnblock aufgelistet, der der Ausgabe angehängt ist, z. B. PostgreSQLs ON CONFLICT bei der Konvertierung zu SQL Server.
Kann ich Multi-Statement-Scripts konvertieren?
Ja – Jede Anweisung, die durch Semikolons getrennt ist, wird eigenständig verarbeitet, sodass ein Script mit mehreren CREATE TABLE- oder SELECT-Anweisungen in einem Durchgang konvertiert wird.
Wird meine SQL irgendwo hochgeladen?
Nein. Die Konvertierung läuft vollständig in Ihrem Browser – Ihre Abfragen, Schemas und Daten verlassen Ihr Gerät nie.