Kennt ihr diese kleinen fiesen Probleme, die aus dem Nichts auftauchen und einem so dermaßen auf den Senkel gehen, dass man sie unbedingt lösen will? So eins lief mir heute, nein inzwischen ist es schon gestern, über den Weg.
Ich habe insgesamt 6 Datenbanken von einer SQL-Server-Instanz auf eine andere auf einem anderen Server umgezogen. Da sich der Server änderte, musste ich auch die Logins, d.h. Windows-Benutzerkonten, ändern. Bei 5 der Datenbanken ging das problemlos, nur die sechste machte Stress. Genauer gesagt beglückte mich das SQL Server Management Studio beim Versuch, den alten Benutzer aus der Anmelde-Liste der Datenbank zu löschen, mit der Meldung:
"The database principal owns a fulltext catalog in the database, and cannot be dropped."
Oder auf Deutsch:
"Der Datenbankprinzipal besitzt ein Volltextkatalog-Objekt in der Datenbank und kann nicht gelöscht werden."
Das Problem: die Datenbank besitzt eigentlich keinen Volltextkatalog, zumindest war mir keiner bekannt. Und da es sich beim Datenbank-Server um eine Express-Version handelt, liefert das Management Studio leider auch kein passendes GUI zur Volltextkatalog-Verwaltung mit.
So begann ein etwa zweistündiges Stochern im Dunkeln, was zwischendurch sogar darin gipfelte, dass ich eine Sekunde darüber nachdachte, meine Kreditkartendaten bei Experts Exchange zu hinterlegen, was den einzigen brauchbaren Treffer zu liefern schien - aber eben nur gegen Registrierung samt Kreditkarteninfo. Ansonsten war im ganzen Netz nichts zu finden, nicht mal die MSDN Library konnte mit der Fehlernummer 15138 etwas anfangen.
Irgendwann entschied ich mich dann, den alten Benutzer einfach drin stehen zu lassen, was soll's. Doch halt. Nachdem mein Rechner schon im Ruhezustand war, kam mir die Idee. Wenn ich schon kein GUI habe, dann erstelle ich mir halt einfach ein vollständiges Script der Datenbank und suche darin nach dem Benutzer, irgendwas wird sich schon finden. Denn zumindest das geht seit der 2008er Version. Gedacht, getan. Und tatsächlich fand sich etwas:
1: CREATE FULLTEXT CATALOG [YafSearch]WITH ACCENT_SENSITIVITY = ON
2: AUTHORIZATION [ALTERSERVER\IUSR_xyz]
3: GO
Bei der Installation von YAF wurde augenscheinlich auch ein Volltextkatalog eingerichtet. Gut zu wissen. Von hier aus war es dann nur noch etwas try&error mit ALTER AUTHORIZATION bis zur Lösung:
1: ALTER AUTHORIZATION ON Fulltext Catalog::[YafSearch] TO [NEUERSERVER\IUSR_xyz];
Anschließend ließ sich dann der alte Benutzer problemlos aus der Datenbank löschen. Liest sich jetzt vollkommen belanglos, kann aber tierisch nerven. Ich hoffe dass ab sofort dank Google und meiner kurzen Erklärung die Administratoren dieser Welt weit weniger Probleme damit haben werden :-).
