cube
Occasional Observer

DB Schema: Spalte nachträglich in mehrsprachig ändern

Jump to solution

Hallo Community,

ich habe in meinem DB-Schema eine Spalte "paygroup" (Datentyp string) als sprachunabhängig definiert.

Nach Änderungen der Anforderungen sollen die Daten in "paygroup" künftig aber mehrsprachig gespeichert werden (sprich:

ich benötige eine Unterscheidung in "paygroup_DE" und "paygroup_EN").

Lässt sich die Spalte der Tabelle nachträglich in mehrsprachig ändern? Wenn ja, wie?

0 Kudos
1 Solution

Accepted Solutions
hoebbel
Crownpeak employee

Hallo Steffen,

ein kurzer Hinweis noch: Dadurch, dass mit der zweiten Anleitung nicht mehr der "Standardname" für die Spalte in der Datenbank verwendet wird, kann es (bei älteren FirstSpirit Versionen) zu Problemen kommen, wenn das Schema in andere Projekte verteilt wird (per Content-Transport oder external Sync, wahrscheinlich aber nicht, wenn CorporateContent genutzt wird). Sollte eines dieser Transport-Szenarien genutzt werden, bitte kurz beim TechSupport eine Anfrage stellen, ob das Vorgehen mit der verwendeten FirstSpirit Version problemlos möglich ist.

Gerne auch mit Hinweis auf mich oder diese Anleitung hier Smiley Happy

Viele Grüße

Holger

View solution in original post

0 Kudos
3 Replies
hoebbel
Crownpeak employee

Hallo Steffen,

Steffen Kube schrieb:

Lässt sich die Spalte der Tabelle nachträglich in mehrsprachig ändern? Wenn ja, wie?

Zur Zeit ist das leider nur manuell möglich.

Annahme: die Spalte paygroup ist NULLABLE

Abhängig davon, ob bereits Daten gepflegt wurden und wenn ja, ob diese weiter verwendet werden sollen, geht das so:

Daten werden nicht benötigt:

Schema bearbeiten starten

Spalte paygroup löschen

Spalte paygroup neu anlegen, dabei den Haken für mehrsprachig setzen

Schema bearbeiten beenden

--> Effekt: Es werden neue Spalte paygroup_<Abbreviation> in der Datenbank angelegt.

Daten sollen weiterhin zur Verfügung stehen:

Schema bearbeiten starten

Aus dem Kontextmenü auf dem Schema "Extern bearbeiten/Datenbankschema" auswählen

In einem externen Programm (z.B. notepad++) öffnet sich das XML des Schemas [WICHTIG: Das Programm sollte xml ohne Anpassungen speichern können]

in dem XML die Spalte paygroup suchen. Die sieht beispielsweise so aus:

<xs:element dbName="PAYGROUP" javaType="java.lang.String" length="64" name="paygroup" nullable="1" type="xs:string"/>

Die Zeile für jede benötigte Sprache einmal kopieren (wenn ich es richtig verstehe, also genau einmal für EN kopieren)

Die kopierten Zeilen mit den sprachabhängigen Abbreviations erweitern - sowohl für die Attribute dbName als auch name. Die Originalzeile nur für das Attribut name entsprechend erweitern. Das sieht dann so aus:

<xs:element dbName="PAYGROUP" javaType="java.lang.String" length="64" name="paygroup_DE" nullable="1" type="xs:string"/>

<xs:element dbName="PAYGROUP_EN" javaType="java.lang.String" length="64" name="paygroup_EN" nullable="1" type="xs:string"/>

In dem externen Programm speichern

In dem Popup Fenster in FirstSpirit Änderungen übernehmen und schließen anklicken

Im Schema prüfen, ob es korrekt aussieht (also nun zwei Spalten paygroup_DE und paygroup_EN da sind)

Schema bearbeiten beenden

Erklärung: Im zweiten Fall wird das XML so bearbeitet, dass es die beiden sprachabhängigen Spalten gibt (Attribut name). In der Datenbank wird aber nur eine der beiden Spalten neu angelegt. Die andere (im Beispiel paygroup_DE) verweist aber weiterhin auf die bereits vorhandene, bisher sprachunabhängige Spalte in der Datenbank.

Da in Textspalten der Inhalt der Eingabekomponenten unverändert gespeichert wird, sind dort keinerlei Informationen darüber enthalten, zu welcher Sprache der entsprechende Inhalt gehört. Erst die Zuordnung des Attribut dbname (Name der Spalte in der Datenbank) zu dem Attribut name (Name der Spalte für FirstSpirit) definiert, welche Datenbankinhalte für welche Sprache genutzt werden sollen.

Im ersten Fall (in dem die Inhalte verworfen werden können) hat das Löschen der Spalte erst einmal keinen Effekt, außer das FirstSpirit die Zuordnung nicht mehr kennt. Durch das Neuanlagen der Spalte mit demselben Namen werden zwei neue Spalten in der Datenbank angelegt (paygroup_de und paygroup_en), so dass anschließend drei entsprechende Spalten in der Datenbanktabelle existieren. Die dritte Spalte wird von FirstSpirit zukünftig ignoriert werden.

WICHTIG: Wenn die Spalte paygroup NOTNULLABLE ist (also Leerwerte nicht erlaubt sind), kann das Ganze etwas komplizierter werden. In dem Fall wende Dich bitte an den TechSupport, da hier weitere Informationen über die verwendete Datenbank... benötigt werden. Funktionieren wird aber auch dann höchstwahrscheinlich der zweite Weg.

Viele Grüße

Holger

0 Kudos
cube
Occasional Observer

Hallo Holger,

vielen Dank für Deine Antwort!  Für uns träfe der zweite Fall zu (bisherige Daten wurden bereits im Produktivsystem gepflegt und sollen beibehalten werden) und glücklicherweise wurde die Spalte als NULLABLE deklariert 🙂

Ich denke, mit Deiner verständlichen und ausführlichen Beschreibung sollte klar sein, wie wir vorgehen müssen.

Beste Grüße,

Steffen

0 Kudos
hoebbel
Crownpeak employee

Hallo Steffen,

ein kurzer Hinweis noch: Dadurch, dass mit der zweiten Anleitung nicht mehr der "Standardname" für die Spalte in der Datenbank verwendet wird, kann es (bei älteren FirstSpirit Versionen) zu Problemen kommen, wenn das Schema in andere Projekte verteilt wird (per Content-Transport oder external Sync, wahrscheinlich aber nicht, wenn CorporateContent genutzt wird). Sollte eines dieser Transport-Szenarien genutzt werden, bitte kurz beim TechSupport eine Anfrage stellen, ob das Vorgehen mit der verwendeten FirstSpirit Version problemlos möglich ist.

Gerne auch mit Hinweis auf mich oder diese Anleitung hier Smiley Happy

Viele Grüße

Holger

0 Kudos