Diskussion:Oracle: CharacterSet ändern

WE8MSWIN1252 und UTF8

Vorhin hat eine IP folgende Änderung eingefügt:

Eine Kovertierung von UTF8 nach WE8MSWIN1252 ist nicht möglich, da (lt. sqlplus) WE8MSWIN1252 keine Untermenge von UTF8 ist.

Quelle hier

In der Form ist das offensichtlich falsch: WE8MSWIN1252 ist eine echte Untermenge von UTF8. Die Konvertierung ist durchaus möglich, aber zwangsläufig mit Verlusten verbunden. Ich habe den Satz deshalb geändert. Allerdings könnte es sein, dass im Zusammenhang mit dem ganzen Kapitel und dem Verweis auf sqlplus etwas ganz Anderes ausgedrückt werden sollte. Deshalb wollte ich meine Änderung hier kurz erläutern. -- Jürgen 11:49, 3. Mai 2012 (CEST)

Abgesehen davon, dass ALTER DATABASE CHARACTER SET ... bereits seit Oracle 10.1 nicht mehr verwendet werden sollte (siehe ALTER DATABASE) stimmt die Aussage nicht. Eine verlustfreie, d.h. für mich auch "fehlerfreie" Konvertierung ist nur möglich wenn im alten Character Set jedes Zeichen durch das selbe Byte repräsentiert wird wie im neuen Character Set, siehe Migrating Character Data Using the ALTER DATABASE CHARACTER SET Statement:

* Each and every character in the current character set is available in the new character set.

* Each and every character in the current character set has the same code point value in the new character set. For example, US7ASCII is a strict subset of many character sets.

Wie wurden die Konvertierungen getestet? Gab es auch exotische Objekte in der Datenbank wie CREATE TABLE "Zeichensätze" (Zeichensatz VARCHAR2(50), "Abkürzung" VARCHAR2(5)); -- Wernfried 09:37, 10. Mär. 2017 (Signatur nachgetragen von: Jürgen 10:16, 10. Mär. 2017 (CET)-- bitte signiere deine künftigen Beiträge selbst mit 4 Tilden ~~~~)

Hallo @Wernfried, abgesehen davon, dass mein Hinweis und die damalige Bearbeitung schon fast fünf Jahre alt sind: Durch meine Formulierung habe ich auf das Problem "verlustfrei" aufmerksam gemacht. Du hast mit deinem Hinweis natürlich recht, was eine Zeichensatz-Konvertierung genau genommen bedeutet. Es bleibt dir unbenommen, den Punkt "(Rückwärts-)Konvertierung" völlig anders zu beschreiben und das Kapitel hinsichtlich ALTER DATABASE CHARACTER SET ... komplett zu überarbeiten.

Da die Hinweise "getestet unter..." sehr knapp ausgefallen sind und von verschiedenen Autoren zu unterschiedlichen Zeiten eingefügt wurden, ist davon auszugehen, dass nur einzelne Situationen getestet worden sind. – Trotz UTF8 habe ich für die SQL-Beispieldatenbank zwar die (vor meiner Zeit eingeführten) deutschen Spaltennamen behalten, aber auf Umlaute verzichtet (natürlich um Problemen von vornherein aus dem Weg zu gehen). -- Jürgen 10:16, 10. Mär. 2017 (CET)

Empfehlung zur Löschung

Der ganze Artikel sollte eingestampft werden. Der Befehl alter database character set internal_use ... ist eigentlich nirgendow so dokumentiert. Der Parameter internal_use weist ja auch irgendwie darauf hin, dass das nur für internal user gedacht ist und nur angewendet werden soll, wenn alle Voraussetzungen stimmen. Das Statement wird deshalb 'erfolgreich' durchgeführt, weil der Parameter internal_use bewirkt, das keinerlei Überprüfungen durchgeführt werden und damit auch keine Fehler aufgezeigt werden. Mit 'testen' meint der Autor wohl, dass er das Statement auf Datenbanken dieser Versionen durchgeführt hat, und die Datenbank sich danach immer noch da war. Alles in allem ist das aber eine gute Möglichkeit, eine Datenbank zu zerstören.

Es ist ziemlich verantwortungslos, so etwas zu veröffentlichen.

Miracle173 11:55, 25. Nov. 2021 (CET)