Manuel Goldschmidt
Aktives Mitglied
dito ;-)
bei so vielen votes müsste man ja fast prüfen ob man es als Developer-Partner programmiert
Christian Schaller
Neues Mitglied
Bis Sage hierzu vielleicht eine Lösung erstellt wäre es wohl möglich kurzfristig einen neuen AD-User anzulegen. Und dann in allen entsprechenden Tabellen den UserName (oder wie das jeweilige Feld in den Tabellen heisst) mittels eines Skripts zu ersetzen. Ausser natürlich unter USysSecurityUser und ähnlichen Tabellen, in welchem die User selber angelegt werden.
Christian Schaller
Neues Mitglied
Mit zum Beispiel diesem Skript https://stackoverflow.com/questions/15757263/find-a-string-by-searching-all-tables-in-sql-server hat man bereits die halbe Miete und findet so ohne grossem Aufwand alle Tabellen und Spalten in welchen der bestehende AD-User vorkommt. Eventuell kann man dies noch vereinfachen, wenn man die Zeile
SET @SearchStr2 = QUOTENAME('%' + @SearchStr + '%','''')
durch
SET @SearchStr2 = QUOTENAME(@SearchStr,'''')
ersetzt. Denn wird nur genau nach dem Ausdruck SEARCH_TEXT gesucht und nicht nach LIKE. Aber dies müsste man überprüfen ob dies dann nicht ungewollt Tabelleneinträge ausschliesst.
Wenn man das sich daraus ergebende Resultat richtig liest kann man damit ganz einfach das entsprechende Skript erstellen. Womit die Punkte bezüglich Datenintegrität, Datenschutz sowie historische Daten eigentlich kein grosses Thema mehr sein sollten.
SET @SearchStr2 = QUOTENAME('%' + @SearchStr + '%','''')
durch
SET @SearchStr2 = QUOTENAME(@SearchStr,'''')
ersetzt. Denn wird nur genau nach dem Ausdruck SEARCH_TEXT gesucht und nicht nach LIKE. Aber dies müsste man überprüfen ob dies dann nicht ungewollt Tabelleneinträge ausschliesst.
Wenn man das sich daraus ergebende Resultat richtig liest kann man damit ganz einfach das entsprechende Skript erstellen. Womit die Punkte bezüglich Datenintegrität, Datenschutz sowie historische Daten eigentlich kein grosses Thema mehr sein sollten.
Ich muss da @R.Ziemer zustimmen.
Den Arbeitsaufwand und das Risiko das was nicht klappt steht in keinem Verhältnis zu dem Nutzen - finde ich.
Wir legen einfach bei Namenswechsel einen neuen User an und gut ist.
Ja, die Person hat dann erstmal keine direkt Historie und muss unter dem alten Namen schauen.
Aber wenn man es genau nimmt, waren ja zB die Buchungen "damals" auch unter dem alten Namen.
Daher bin ich mir gar nicht sicher wie das aussieht wenn zB in der Buchhaltung bei der Buchungen im Jahr 2021 "Sandra Müller" steht, obwohl sie zu diesem Zeitpunkt noch "Sandra Schmitt" hieß.
Abgesehen davon kommt das ja nicht ständig vor (sollte zumindest nicht), dass jemand seinen Namen wechselt.
Den Arbeitsaufwand und das Risiko das was nicht klappt steht in keinem Verhältnis zu dem Nutzen - finde ich.
Wir legen einfach bei Namenswechsel einen neuen User an und gut ist.
Ja, die Person hat dann erstmal keine direkt Historie und muss unter dem alten Namen schauen.
Aber wenn man es genau nimmt, waren ja zB die Buchungen "damals" auch unter dem alten Namen.
Daher bin ich mir gar nicht sicher wie das aussieht wenn zB in der Buchhaltung bei der Buchungen im Jahr 2021 "Sandra Müller" steht, obwohl sie zu diesem Zeitpunkt noch "Sandra Schmitt" hieß.
Abgesehen davon kommt das ja nicht ständig vor (sollte zumindest nicht), dass jemand seinen Namen wechselt.
Manuel Goldschmidt
Aktives Mitglied
Ich hatte darüber bereits 2019 was geschrieben.
Bei uns ging es auch um "Namensänderungen" aber im Zuge von einem neuen Domänennamen.
siehe hier:
Bei uns ging es auch um "Namensänderungen" aber im Zuge von einem neuen Domänennamen.
siehe hier: