7 Replies Latest reply on Apr 12, 2013 3:46 AM by _Mel_

    Schemaerweiterung

    Nice2010 Expert
      Hallo, ich habe zwei/drei Fragen zum Thema Schemaerweiterung.

      Ich unterstütze derzeit einen Kunden der für die Clients zwei Gruppen für die Schemaerweiterungen angelegt. In eine Gruppe habe ich einen neuen Wert hinzugefügt. Wenn ich jetzt versuche mit ModifyObjectProperty in diesen Wert zu schreiben, wird mir die ganze Gruppe nicht angezeigt. Mir wird nun eine Gruppe angezeigt. Dann habe ich eine eigene Gruppe mit meiner neuen Eigenschaft angelegt. Beides wird mir dann auch bei ModifyObjectProperty angezeigt. Wenn ich nun ein Script erstelle, dass diese Eigenschaft mit leben füllt, erhalte ich diese Meldung im Logfile:

      15:00:12.049 2        -> ModifyObjectProperty(f_CurrentComputer,'CustomDuerrClientOptions','NewPropertyDef','18.07.2012')/TW
      15:00:12.049 2         SWMSClntLib: Commit is disabled: object changes are not written to JSON cache

      Die Eigentschaft wird entsprechend nicht angezeigt. Was ist mit "SWMSClntLib: Commit is disabled" gemeint und wie kann ich das ändern?

      Dann interessiert mich noch ob und wie ich diese Wert später abfragen kann.

      Vielen Dank
        • 1. Re: Schemaerweiterung
          uppereastside Apprentice
          Hallo,

          habe soeben das gleiche Problem.. Ich möchte mit ModifyObjectProperty eine Custom Schema Erweiterung befüllen, bekomme aber auch die Meldung zurück:

          17:23:33.704 2         SWMSClntLib: Commit is disabled: object changes are not written to JSON cache



          Wie hast du das lösen können?

          danke!

          Grüße
          Jochen
          • 2. Re: Schemaerweiterung
            CalumField1 Expert
            Tagchen Jochen,

            diese Meldung tritt auf wenn man der Skript mit F7 installiert - mittels normale Zuweisung sollte es wie gewünscht funktionieren.
            • 3. Re: Schemaerweiterung
              uppereastside Apprentice
              Hi Calum,

              danke für den Tipp! Natürlich..... hhmm... man darf dem F7 einfach nicht trauen ;-)

              lg
              Jochen
              • 4. Re: Schemaerweiterung
                Markus.Zierer Expert
                Hallo,

                Also ich kann nur raten, F7 u. F8 zum testen möglichst gar nicht zu verwenden. Die F7 bzw. F8 funktion ist primär dazu gedacht, die Scriptlogik zu prüfen, also den Code an sich, da aber jede Menge Kleinigkeiten zu beachten sind, ist aus meiner Sicht der Nutzen äusserst Zweifelhaft.

                Die bessere Lösung ist meiner Erfahrung nach die, Paket(e) per Pilotinstallation auf einen Testrechner (am besten VM) zuweisen und diese dann dort regulär installieren lassen. Das funktioniert i.d.R. wie gewünscht und spart unterm Strich auch Zeit, weil man nicht erst solche dämlichen Fehlerchen suchen muss.

                Das mag jetzt vielleicht nicht offizielle FR Policy sein, ist aber die Erfahrung aus einigen Jährchen intensiver Paketierung.
                • 5. Re: Schemaerweiterung
                  _Mel_ Master
                  und wenn man den rechner auch in der infrastruktur als testcomputer definiert hat, dann kann man sich inzwischen auch das vorbereiten/verteilen der pakete sparen - und damit ist der mMn größte vorteil von F7 keiner mehr...
                  • 6. Re: Schemaerweiterung
                    Klaus Salger Expert
                    Ich finde die Tatsache, dass man bei Testcomputern nicht auf die Replikation warten muss auch sehr angenehm.
                    Davon, dass damit alles normal funktioniert kann man allerdings leider nicht ausgehen.
                    Bei Testcomputern weicht die Installation vom Normalfall ja etwas ab - das Staging läuft aus den Work-Rev-Verzeichnissen,  deren Inhalte gezippt sind, was im Install-Verzeichnis im Regelfall nicht so ist.

                    Ich habe bei DSM v7.1 beobachtet, dass es bei Testcomputer gehäuft zu Installationsabbrüchen kam wenn mehr als 1 Paket installiert werden sollte (z.B. bei der Grundinstallation). Dann kommen sich Installation und Staging in die Quere und das Ganze endet mit could not make files available weil sich  die fürs unzippen zuständige DLL unsanft beendet.

                    In neueren DSM-Versionen ist das womöglich gefixt (habe ich mir nicht angeschaut) aber falls jemand bei Testcomputern auf die beschriebenen Symptome trifft würde ich empfehlen es mit Nicht-Testcomputern nochmal zu versuchen.

                    Ciao
                      Klaus
                    • 7. Re: Schemaerweiterung
                      _Mel_ Master
                      bei neueren DSM versionen wird direkt der inhalt des work verzeichnisses verwendet (also nicht der rev ordner und damit muß man auch kein prepare distribution mehr machen)

                      es ist natülich nicht ganz gleich, weil die daten direkt vom netz benutzt werden anstatt aus dem lokalen cache
                      -> könnte probleme machen mit externen programmen, die nicht mit netzwerkshares zurechtkommen
                      -> kann sein, daß es nur funktioniert, wenn der benutzer unter dem der installer läuft zugriff auf's share hat

                      ...aber spätestens nach der zwanzigsten änderung an einem paket, nach der man wieder auf die distribution wartet ist es mMn ein echter vorteil (ich persönlich finde bereits einmal auf die distribution zu warten zu viel, aber ich bin auch ungeduldig )