So ein Update hat ja immer was Spannendes … kurzum: Hat alles wunderbar funktioniert, soweit.
Aber zwei Fragen und ein Hinweis:
Gibt es keine Möglichkeit, bei der Datensicherung vor dem Versionswechsel die Spaltendefinitionen und Benennungen bei Containern mit zu übernehmen? Das ist etwas lästig, sich das alles wieder zurechtschubsen und umbenennen zu müssen.
Ähnlich den Einstellungen beim address-pickup … Da würde ich mir wünschen, dass die zuvor eingestellte Solution und was, wie, wohin soll(te), als Voreinstellung aus der vorherigen Version bestehen bleibt. Falls ich nach dem Update auch Solutions und oder pickup-Einstellungen variieren will, kann ich das tun; so muß ich aber Sachen (erneut) einstellen, die ich nicht verändert habe(n will). Ist nicht wirklich ein Problem und jammern auf hohem Niveau, kam mir aber grad etwas unütz vor.
Hinweis:
Kleines Anzeigeproblem bei der pickup-Konfiguration …
Wenn ich das Fenster aufziehe, bleibt die Scrolleiste stehen bzw. verdoppelt sich (s. Bild)
Wahrlich auch nicht schlimm, ich wollte es einfach nur mitteilen.
Das ist etwas lästig, sich das alles wieder zurechtschubsen und umbenennen zu müssen.
…
Ähnlich den Einstellungen beim address-pickup
Ihre individuelle Spaltenkonfiguration hätte auch bei einem Update ganz normal beibehalten werden sollen, wenn Sie eine ganz normale Update-Installation durchführen, d.h. die neue Version „in“ das Verzeichnis der alten Version installieren. Dadurch wird das „Update-Szenario“ (spätestens) erkannt und es sollte zu einem eleganten Übergang zur neuen Version kommen und Ihre Einstellungen wären dann auch beibehalten worden (bzw. hätten es sollen).
Sollten Sie selbst zuerst händisch die alte Version deinstalliert haben, weil Sie evtl. dann „frisch“ die neue Version installieren wollten, dann ja dann räumt die Deinstallationsroutine „sauber“ alles weg.
Ihre individuellen Spaltenkonfiguration (wenn Sie sie nicht „als Projektvoreinstellung“ gespeichert haben) und Ihre address pick-up Feldzuordnungen stecken in der Registry unter HKCU/Software/combit und sollte „gefälligst“ einen Update-Prozess überleben. Jedenfalls hätten wir das gerne so gewollt.
Sie sehen schon, ich drücke mich vage aus, weil die Kombinationsmöglichkeiten diverser Szenarien vielfältig und zahlreich sind. Ich mag nicht ausschließen, dass wir irgendwas Spezielles übersehen haben.
Im „normalen“ Fall
cRM10 Hauptinstallation auf Server
cRM10 Client Installation auf Clients
cRM11 Hauptinstallation auf Server in den Ordner von cRM10
cRM11 Clientinstallation auf cRM10 Clients (hier gibt es auch vollautomatische Rollout Möglichkeiten, siehe Handbuch bzw. Knowledgebase)
bleiben Ihre Einstellungen entsprechend erhalten.
Wenn wir in Ihrem Fall da noch etwas eruieren sollen, erstellen Sie doch einfach kurz einen Support Case unter Angabe des Datums Ihrer Setup-Exe-Datei und der darin enthaltenen Version der cRM.ovl (Dateieigenschaften im Explorer) - bevor Sie das aktuellste Service Pack darüber installiert haben. (Wenn das mittlerweile zu spät ist, auch egal, das Dateidatum der Setup exe ist schonmal gut.)
Einen Case anzulegen geht direkt aus dem cRM heraus über ‚Datei > Hilfe > Support > Supportanfrage stellen‘, wenn Sie die V11 schon online registriert haben) - ansonsten das erst noch kurz per ‚Datei > Hilfe > Online Registrierung‘ vorziehen.
Dadurch wird das „Update-Szenario“ (spätestens) erkannt und es sollte zu einem eleganten Übergang zur neuen Version kommen und Ihre Einstellungen wären dann auch beibehalten worden (bzw. hätten es sollen).