Neuer Domänenname Datenmigration Sage 100, DMS & xRM

Ich rate prinzipiell von solchen Experimenten ab.
Sicherung vom alten Server (Domäne) auf dem neuen Server (neue Domäne) einlesen. Danach die üblichen Checks laufen lassen und Berichte umstellen. Die Migration hat eigentlich relativ gut bisher funktioniert. Musst eben noch das ganze PrintAddin geraffel nach der Migration entfernen. Auf die neuen Forms und Berichte umstellen.
Wen Du xRM bereits verwendet hattest auf dem alten Server musst Du aber auch mindestens die Version Build .228 inklusive nachfolgendem LiveUpdate durchführen, bevor Du versucht die Sicherung zu importieren. Sonst raschelt es gewaltig. Auch die Benutzer sollten vorher bereits angelegt sein mit NT-Authentifizierung. Die alten Benutzer kannst Du nach der Migration löschen.
 
Wir haben eine db Sicherung auf dem alten Server erstellt und auf dem neuen eingelesen. (Domänenname ist unterschiedlich)
In der db stehen doch weiterhin die alten UID's (mit dem alten Domänennamen) mit dem alten Domänennamen...
 
Wir haben von der Build Sage_100 _Setup_Build_246_ 8_1 _228.iso bei der Installation verwendet. Aber leider nur Probleme an etlichen stellen...

Das Problem bleibt aber weiterhin bestehen wenn ich die Benutzer lösche und neu anlege da sämtliche Einträge z.B. To-Do Liste (vom xRM) dem User mit der alten Domäne zugeordnet sind. (deshalb möchte ich alle db-Einträge gerne per Script ändern wie beschrieben)

Sehe aber das scheinbar noch keiner in der doofen Situation war sein Domänennamen ändern zu müssen...
 
Domain-Name String in der DB sollte per Script ja machbar sein. Und wenn der neue Domain Benutzer auch im Sage Admin so angelegt ist, sollte ihm nach der Änderung auch alle verknüpften Dokumente etc. wieder zur Verfügung stehen.
 
@mandreck danke für deine Antwort.
Das denke ich mir auch aber was sagst du zu meinen Lösungsansätzen bzw. den Ideen wie man das Problem mit den Primary Key oder eine Primary Key Row?

Und was zu dem DMS-Benutzerfeld "String abschneiden oder das Feld in der Länge erhöhen"? (abscheniden wäre natürlich "unschön")
 
Zuletzt bearbeitet:
@Manuel Goldschmidt, da wird nicht praktikabel sein, da mit jedem LiveUpdate etc. ja das DB Schema neu gelesen wird und die Werte entsprechend wieder angepasst werden, so das Du nicht Update sicher bist und nach jedem Update die Werte wieder händisch ändern müsstest. Abgesehen davon, das beim Update -f ja Deine Werte ebenfalls automatisch abgeschnitten werden könnten.

Hier solltest Du Dich mit Sage in Verbindung setzen und um eine prinzipielle Erhöhung bitten, dass Sie das mit einfließen lassen in ein nächstes Update. Was ja nicht das Problem sein sollte. Weil ja für alle anderen Anwender sich ja dadurch nichts ändert, wenn die Feld Länge vergrößert wird. Kurze Schilderung Deines Problems, mit FQDN von Dir + Benutzer Name etc. sollte denen dann auch klar sein, das da etwas gemacht werden müsste.
 
@mandreck
Danke - werde Sage mal bitten die Feldlänge zu erhöhen...
Glaube zwar nicht dran das was passiert aber die Hoffnung stirbt zu letzt.


Was sagst du zu den Primary Key oder eine Primary Key Row Problem?
 
Ich weiß nicht 100% was Du wissen willst, aber hier mal einige Anmerkungen.

Der wahre Primärschlüssel für eine Rowid-Tabelle (der Wert, der als Schlüssel zum Nachschlagen von Zeilen in der zugrunde liegenden Speicher-Engine verwendet wird) ist die Rowid .

Die PRIMARY KEY-Einschränkung für eine Rowid-Tabelle (sofern es sich nicht um den wahren Primärschlüssel oder INTEGER PRIMARY KEY handelt) entspricht in Wirklichkeit einer UNIQUE-Einschränkung . Da es sich nicht um einen echten Primärschlüssel handelt, dürfen die Spalten des PRIMARY KEY NULL sein, was gegen alle SQL-Standards verstößt.

Auf die Zeilen-ID einer Zeilen-ID-Tabelle kann zugegriffen werden (oder sie kann geändert werden), indem in eine der Spalten "rowid" oder "oid" oder "_rowid_" gelesen oder geschrieben wird. Wenn die Tabelle nur deklarierte Spalten enthält, die diese speziellen Namen verwenden, beziehen sich diese Namen auf die deklarierten Spalten und nicht auf die zugrunde liegende Zeilen-ID .
Der Zugriff auf Datensätze über rowid ist hochoptimiert und sehr schnell.
 
@mandreck es bezog sich auf das hier:

"Durch das Änderung von 'ALTER-Domänenname\' in 'NEUER-Domänenname' würden doppelte Daten entstehen, welche gleichzeitig ein Primary Key oder eine Primary Key Row sind

Fehlermeldungen:
- Violation of PRIMARY KEY constraint 'PK_[Name]'. Cannot insert duplicate key in object 'dbo.[Name]'.
- Cannot insert duplicate key row in object 'dbo.[Name]' with unique index 'ZZ_[IndexName]'.

Mögliche Lösung:
Die doppelten Primary Keys löschen oder umbenennen nach z.B. 'ALTER-Domänenname-ALTER-KEY'. Falls es vorige Verknüpfungen in anderen Tabellen gab, müssten diese eigentlich umgehängt sein (außer es gibt dort wiederum doppelte Daten)."
 
@mandreck DANKE!

Mir ist soeben noch etwas aufgefallen...
Es geht um das Feld [editor] in Tabelle [D3OL].[dbo].[audit_trail]. (dies ist die db vom d3 DMS)
Die Einträge welcher in der Tabelle stehen sind "durcheinander"
d.h. manche sind mit FQDL bzw. abgeschnitten ...GH\Benutzername
Manche enthalten nur den Benutzernamen ohne Domäne und es gibt täglich (fast zu gleichen Uhrzeit) Benutzername und benutzername (einmal Groß und einmal mit einem kleinen ersten Buchstaben)

Wie ist das bei euch?
Hat Sage an der Stelle mal was geändert?
 
Eventuell noch doppelte Einträge in der DB vorhanden für die Benutzer. Einmal altes Anmelde Verhalten einmal nur mit NT. Deswegen auch meine Aussage aus einem anderen Thread. Zuerst die NT Benutzer anlegen, danach die alten löschen, hier muss teilweise auch händisch nachgesteuert werden und dann erst verknüpfen.

Auch der Sage Benutzer ist bei unseren Kunden vollständig entsorgt.
 
Wie kann ich das prüfen mit den alten Anmeldeverfahren? Wo wird das gespeichert?

Wie löscht du die alten User?
Direkt über ein Script aus der db?
 
Unter dem Administrator von Sage, zuerst alle überflüssigen soweit möglich entfernen.
Danach in die DB schauen unter DB/Sicherheit/Benutzer was da noch steht und dort die Reste von alten Benutzern entfernen, die durch das Admincenter nicht entfernt wurden.
Manchmal erstelle ich auch erst einen neuen Benutzer ohne NT damit ich allte Einträge komplett entsorgen kann.
Melde mich testweise aber auch mit diesem an der DB an er erhält alle Rechte. So das auch mit diesem Benutzer auf die Funktionen Module zugegriffen werden kann. Danach lösche ich alle anderen aus der DB siehe oben und lege meine Domain Benutzer neu über das Admincenter an. Danach kannst Du mit suchen und ersetzen die Strings tauschen. So das jeder Benutzer alt Max Müller mit dem neuen Benutzer \\DOMain-XZ\Max Mueller (keine Umlaute verwenden, diese können in der Bezeichnung verwendet werden) aus. So bekommt jeder Benutzer auch in der neuen Domaine seine ihm bereits zu geordneten Dokumente wieder.

Wichtig immer eine Sicherung vorher nochmals erstellen, falls etwas zu viel gelöscht wird im Eifer des Gefechtes. Mandanten DB. Globale DB nur bedingt wichtig. Bei mehreren Mandanten natürlich von jeder DB eine Sicherung.

Altes Verfahren, steht immer nur der Benutzername, bei NT-Authentifizierung steht immer \\Station oder Domain Name\gefolgt vom Benutzer Namen ohne Umlaute.
 
Das Thema ist komplex / kompliziert und deswegen kann ich es hier nicht vollumfänglich beantworten.

Wenn meine Kommentare hier im Forum sinnvoll und hilfreich sind, dann freut mich das.
Aber ich werde auf keinen Fall in Diskussionen eintreten, ob, was, wie etc. von Sage sinnvoll oder verbesserungsfähig ist.

Wenn im SQL-Server ein NT-Benutzer - egal ob über den Sage 100 Administrator oder über das SQL Server Management Studio - angelegt wird, wird dabei automatisch die SID (Security ID) dieses NT-Benutzers im SQL-Server gespeichert.
Umbenannter NT-Benutzer (z.B. wegen Heirat) in gleicher Domäne:
Ein in der Domäne umbenannter NT-Benutzer kann dann nicht angelegt werden, da er auch nach der Umbenennung die SID behält und der SQL-Server keine zwei Benutzer mit der gleichen SID akzeptiert. In diesem Fall muss erst der "alte" NT-Benutzer komplett gelöscht werden, bevor der "neue" angelegt werden kann.
Neuer NT-Benutzer in anderer Domäne:
Da hier der Benutzer UND die SID anders sind, sollte das kein Problem sein.

Auf Tabellenebene Benutzer zu ändern ist extrem riskant.
Speziell die USys….. Tabellen sollten dabei nicht angefasst werden.
Z.B. kann es dabei passieren, dass in der Buchungserfassung Sitzungen des "alten" NT-Benutzers nicht mehr ausgewählt werden können oder oder oder…..

Wiederholung:
Wenn meine Kommentare hier im Forum sinnvoll und hilfreich sind, dann freut mich das.
Aber ich werde auf keinen Fall in Diskussionen eintreten, ob, was, wie etc. von Sage sinnvoll oder verbesserungsfähig ist.

Und wegen mir möge irgendjemand ein Bashing beginnen…..
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben