Schema-Layer-Aktualisierung über CorporateContent unterbinden

[tweihing]

Hallo Zusammen,

ist es möglich die Aktualisierung des Layers eines Schemas beim Update über das CorporateContent zu unterbinden?

Konkretes Problem:

Projekt A beinhaltet DB-Schema mit abhängigen Templates und ist dementsprechend einem DB-Layer (Layer A) zugewiesen.

Projekt B soll Schema und Templates aus Projekt A über das Abonnement erhalten und aktualisieren. Projekt B soll dabei aber einen eigenen Layer (Layer B) verwenden. Wenn man nun manuell die Layer Zuordnung von Projekt B auf Layer B ändert, so wird jedes Mal beim Update eines Paketes in Projekt B der Layer wieder auf Layer A gestellt.

Hat hier jemand Erfahrung oder eine Idee?

Vielen Dank & Grüße

Tobias Weihing

[tenter]

Hallo Tobias,

wir wollen uns das Problem genauer anschauen - kannst du uns zur Hilfe noch deine verwendete FirstSpirit-Version sagen?

Grüße,

Hannes

[sense]

Hi,

dafür gibt es ein Script namens "switchDatabaseLayer", habe ich gerade auch aktuell in einem Projekt. Frag da einfach mal beim e-Spirit Support an. Damit lässt sich nach jedem Aktualisieren des Abos über einen Workflow der Layer wieder zurück switchen. Das Ganze funktioniert so:

1. Aktualisierung des Abos im Zielprojekt (Layer wird überschrieben)
2. Ereignis greift, wo ein entsprechender Workflow mit Script angebunden ist (-> e-Spirit Support)
3. Layer wird dann über das Script auf den entsprechenden Layer zurückgesetzt

[chwal]

Hallo Tobias,

kann dir vielleicht die Antwort von Sven Culley bereits weiterhelfen?

Viele Grüße,

Sebastian

[tweihing]

Hallo Zusammen,

erst einmal vielen Dank für die Antworten.

Die Firstspiritversion um die hier geht ist die 5.2.

@Sven, dann werde ich mein Glück mal beim e-Spirit Support versuchen. Ich hoffe es war der HelpDesk gemeint, die Professional Services tendieren ja dazu einen zu ignorieren.

Besten Dank und ich aktualisiere den Thread nochmal, falls das mit dem Script dann erfolgreich ist.

Viele Grüße

Tobias

[Knuth]

Hallo Herr Weihing,

Sie scheinen schlechte Erfahrungen mit meinem Professional Services Bereich gemacht zu haben. Ich bin sehr daran interessiert, mehr darüber zu erfahren. Leider habe ich keine Kontaktdaten von Ihnen. Könnten Sie mir vielleicht eine e-Mail schreiben (waltenberg@e-spirit.com)?

Herzlichen Dank im Voraus!

Mit freundlichen Grüßen

Knuth Waltenberg

[hoebbel]

Hallo Tobias,

> Die Firstspiritversion um die hier geht ist die 5.2.

In der Version 5.2 sollte das Verhalten eigentlich so sein, dass bei der Aktualisierung eines Abonnements der Layer so gesetzt wird, wie er auch beim Anlegen des entsprechenden Schemas definiert würde. Das wurde unter der internen ID 164343 entsprechend abgepasst und ist seit der Version 5.2.18 enthalten)

Das klingt komplizierter als es ist.

Bei deinem Beispiel:

Projekt A -> Layer A (ich vermute in Datenbank A)

Projekt B -> Layer B (ich vermut ein Datenbank B)

sollte es eigentlich keinerlei Probleme geben, sofern der Transport erstmals mit dem Fix ausgeführt wurde. Dann wurde das Schema im Zielprojekt mit dem Layer B angelegt.

Da Du aber Probleme hast, vermute ich, dass folgendes passiert ist:

- Das Szenario wurde mit der Version 5.1 (oder älter) aufgesetzt

- Beim initialen Import wurden die Informationen für den Datenbanklayer in der Schema-Konfiguration aus dem Quellprojekt übernommen. Das führte dann dazu, dass die Tabellen in einem Tabellenraum in der Datenbank gelandet sind, der dem des Quellprojektes entsprach.

- Solange die alte Version ohne den Fix genutzt wurde, funktioniert möglicherweise alles problemlos (hängt von der eingesetzten Datenbank B ab, ob die einen anderen Namen für den Tabellenraum unterstützt)

- Nach dem Fix wird nun aber der dbname für das Schema (Definition des Tabellenraums) anhand der vorliegenden Daten berechnet, also immer der Name genommen, den FirstSpirit auch bei einer Neuanlage vergeben würde. Dies führte nun dazu, dass mit dem Fix die vorhandenen Tabellen nun nicht mehr gefunden werden können.

Gelöst werden kann das Problem,wenn meine Vermutung korrekt ist, auf zwei Arten:

- Quickfix wäre es, nach jeder Paketaktualisierung das Schema zu patchen (mit dem von Sven angesprochenen Modul/Skript)

- Langfristige Lösung wäre es, das Projekt einmal zu exportieren und dann wieder zu importieren. Dann werden die Tabellen in der Datenbank in dem korrekten Tabellenraum angelegt und bei einer Paketaktualisierung wird die Konfiguration nicht mehr überschrieben.

Anmerkung: Die Antwort beruht auf einigen Annahmen, die ich auch oben erwähnt habe (insbesondere, dass das Ganze mit einer Version kleiner als 5.2 aufgesetzt wurde). Wenn diese nicht korrekt sind, funktioniert auch der Vorschlag mit dem Export/Import des Projektes nicht.

Viele Grüsse aus Dortmund,

Holger