Questions & Answers

[thoherme]

Hallo zusammen,

beim Versuch einen Datensatz in einer bestimmten Datenquelle zu löschen, erhalte ich Fehlermeldungen vom Typ

Cannot delete object!
   GID mismatch detected for entity '00000000-0000-0000-0000-000000000000, de.espirit.or.impl.IdentifierImpl$TemporalIdentifierLC@3659b659{standardtexts,fs_id=94239,fs_valid_from=1623271662518,fs_valid_to=9223372036854775807,fs_release_to=9223372036854775807}', expected: EntityGidEntry[34eb2cbc-3661-464c-9d11-f5e9a319ddce | schema=3659753, dbTable=standardtexts, id=94239]

Kennt jemand das Problem (und ggf. die Lösung)?
Lassen sich die Datensätze eventuell über einen direkten Zugriff zur Tabelle identifizieren und löschen?


Viele Grüße
Thomas

[hoebbel]

Hallo Thomas,

Um das Problem zu erklären, hole ich mal kurz etwas aus:
FirstSpirit benutzt UUIDs für die eindeutige Identifikation von Datensätzen. Diese UUIDs, im folgenden GIDs genannt, werden beispielsweise für die Verlinkung von Datensätzen verwendet, wenn diese nicht über eine Fremdschlüsselbeziehung in der Datenbank abgebildet werden und auch für die Identifikation von Datensätzen, wenn diese mittels Content Transport in ein Projekt eingespielt werden (gibt es einen Datensatz mit derselben GID, so wird dieser aktualisiert, ansonsten wird ein neuer Datensatz angelegt).

Aus technischen Gründen werden diese GIDs an zwei Stellen gespeichert. Einmal in der Spalte FS_GID an dem Datensatz selber und einmal in einer Backend Datenbank genannt Registry. Diese Stellen haben in diesem Fall unterschiedliche Werte gespeichert.

Die von dir gepostete Fehlermeldung bedeutet, dass in der Datenbank für den Datensatz mit der FS_ID 94239 die GID mit dem (falsch aussehenden) Wert 00000000-0000-0000-0000-000000000000 gespeichert ist, in der Registry aber mit dem (korrekt aussehenden) Wert 34eb2cbc-3661-464c-9d11-f5e9a319ddce. Die Datenbanktabelle ist im FS Schema mit der ID 3659753 konfiguriert und heißt standardtexts.

Bitte kontaktiere den Tech Support, damit das Problem analysiert werden kann. Abhängig davon, wie es zu dem Zustand kam, gibt es unterschiedliche Lösungsansätze. Die Analyse ist aber zu aufwändig, um die hier im Forum durchführen zu können. 

Viele Grüße
Holger

[thoherme · Accepted solution]

Hallo Holger,

vielen Dank für das schnelle Feedback und die Erklärung.

Wir haben das Problem jetzt über einen "Umweg" gelöst, indem, wir über die Bearbeitung des DB-Schemas  in einem externen Editor die Spaltennamen eines früheren Zustands (von dem wir wussten, dass er funktioniert) wiederhergestellt haben.

Anschließend ließen sich alle "korrupten" Datensätze (diejenigen mit Leerstrings in Pflichtfeldern)  löschen.

Möglicherweise ist das nur eine vorübergehende Lösung - für unsere Zwecke aber ausreichend.

Viele Grüße
Thomas