kscheuing
I'm new here

CMS_INPUT_RADIOBUTTON - Datentyp

Jump to solution

Hallo Commnity,

einfache Frage die mich jetzt schon seit einer Stunde in der Dokumentation suchen lässt.

Welcher Datentyp sollte für das Mapping eines CMS_INPUT_RADIOBUTTON in eine Datenbank Schema verwendet werden ?

Per default würd ich sagen, klar - Firstspirit-Editor. Doch offensichtlich ist das Feld (mit einer max größe von 65535) zu klein...

Caused by: java.sql.SQLException: ORA-12899: value too large for column "Datenbank"."TT"."TT_HEADLINE_TOGGLE" (actual: 154, maximum: 64)

TT_HEADLINE_TOGGLE ist dabei ein CMS_INPUT_RADIOBUTTON mit drei Auswahlmöglichkeiten.

In einem anderen Post habe ich jetzt gelesen, dass man String verwenden soll. Macht aber irgendwie kein Sinn für mich.

Leider find ich nicht wirklich eine Aussage dazu in der Doku.

Danke im vorraus und Viele Grüße, Kai

0 Kudos
1 Solution

Accepted Solutions

Hallo Kai,

das ist doch die FirstSpirit-seitige Definition, oder? Ich meinte die (native) Datenbankdefinition. Eventuell besteht da eine Inkonsistenz.

Beste Grüße

Stefan

View solution in original post

0 Kudos
5 Replies
StefanSchulz
I'm new here

Hallo Kai,

ein Radiobutton hat nur einen Wert, String scheint mir dafür doch perfekt geeignet zu sein. Was spricht aus deiner Sicht dagegen?

Eine Firstspirit-Editor-Spalte schreibt die XML-Persistenz des Radiobutton komplett in das Datenbankfeld. 64kByte sollten jedoch auf jeden Fall genügen. Wie genau sieht die Definition der Datenbankspalte aus?

Beste Grüße

Stefan

0 Kudos

Hallo Stefan,

Datatype: EditorWrapper

Length: 65535

Allow Empty Value --> yes

Das bei dem Radiobutton nur der Value gespeichert wird, war mir nicht klar. Dann machts natürlich Sinn.

Ich werds mal mit String versuchen, denke das sollte hin hauen. Ich geb dann nochmal Feedback,

Viele Grüße, Kai

0 Kudos

Hallo Kai,

das ist doch die FirstSpirit-seitige Definition, oder? Ich meinte die (native) Datenbankdefinition. Eventuell besteht da eine Inkonsistenz.

Beste Grüße

Stefan

0 Kudos

Hallo Stefan,

ich hab jetzt nochmal im/beim Projekt geforscht. Tatsächtlich war es eine Inkonsistenz in der Datenbank.

Doofer Umstand: Der Client ist wohl beim Löschen (bzw. verändern) der Column abgestürzt und hat das Datenbankfeld in einem Inkonsistenten Zustand hinterlassen - In Firstspirit war das Feld gelöscht, die Datenbank hatte davon allerdings nichts bemerkt oder bzw. hing in der Transaktion.

Ganz genau kann ich das leider nichtmehr sagen, da es mir Systemseitig verwehrt blieb nach blocking querys zu suchen.

Gibt es hier bei Firstspirit Mechanismen diesen (zugegeben unwahrscheinlichen Fall) abzudecken ?

Lösung: Manuelles beheben der Inkonsistenz.

Danke für deinen Input!

0 Kudos

Hallo Kai,

ein solcher Mechanismus ist mir nicht bekannt.

Freut mich, dass du eine Lösung finden konntest.

Beste Grüße

Stefan

0 Kudos