Bonjour à tous,

Imaginons que vous n'ayez pas installé votre ferme SharePoint selon les bonnes pratiques, et qu'au lieu d'utiliser un alias SQL Server vous ayez directement saisi le nom du serveur pour la création des services (c'est ballot mais c'est courant...).

Imaginons maintenant que vous souhaitiez refaire les choses bien et que vous recréiez les services avec un alias (c'est un bon consultant ça ! oh oui un bon consultant...).

Il est probable qu'ensuite vous souhaitiez supprimer le serveur de BDD référencé dans la section "Servers in farm".

Sage décision, le ménage ça fait toujours du bien (ma femme m'a obligé à mettre cette phrase...), cependant lorsque vous cliquez pour supprimer le serveur vous obtenez le message suivant :


An object in the SharePoint administrative framework, "SPDatabaseServiceInstance Name=NOMINSTANCE Parent=SPServer Name=NOMSERVEUR", could not be deleted because other objects depend on it. Update all of these dependants to point to null or different objects and retry this operation. The dependant objects are as follows :

Grosso modo, il existe des objets dépendant de celui-ci, et SharePoint ne peut pas le supprimer. Cependant la section listant les objets concernée est vide !! (Bizarre ça ne m'étonne même plus, je dois être trop habitué à SharePoint...)

Après un rapide tour sur Internet, vous trouvez un certain nombre de posts qui vous encouragent à aller faire une requête sur la base de données pour voir les objets dépendants et à les supprimer, par exemple : http://www.mylifeinaminute.com/2008/07/23/manually-removing-servers-in-moss-2007/

Pas de chance, cette requête ne retourne rien... On aurait pu s'en douter puisque c'est sûrement la même requête qui a été utilisée dans le message d'erreur ci-dessus.

En allant un peu plus loin vous pourriez tomber sur un post comme celui-ci : http://www.jeremytaylor.net/2010/01/09/sharepoint-moss-shared-services-ssp-delete-unprovisioning/ qui vous encourage à supprimer directement les objets par l'utilisation de STSADM, ce qui semble plus propre mais revient au même : la suppression d'une ligne directement dans la base. Pas de chance là également car l'exécution de cette commande vous renvoie exactement le même message que précédemment...

Dans votre quête de connaissance, vous continuez à chercher et tombez sur ce post : http://sharepointwillem.blogspot.com/2010_06_01_archive.html. Cette fois-ci on va encore plus loin dans le risque pour modifier temporairement la structure de la base de données SharePoint....(L'aaaaaamour du risque, Jonathan et Jennifer... tout ça, tout ça)


STOP !!!!


Bon honnêtement, là j'ai pas pu, je me suis dit qu'il devait y avoir un autre moyen... Et en regardant les contraintes de clés étrangères que le post précédent expliquait comment faire sauter (tout en disant qu'il ne faut pas le faire :o/), je me suis rendu compte qu'il y avait une autre forme de dépendance plus implicite (parce que non indiquée dans la table "dependencies") : la relation Parent / Enfant. En effet les tables des Objets SharePoint donne pour chaque objet quel est l'id de son parent (dont il dépend donc).

J'ai donc fait une recherche rapide sur les objets dont le parent est mon instance SQL Server (après avoir récupéré son Id), et j'ai trouvé le problème : la base de données du service de recherche d'aide WSS était encore stockée sur cette instance... Après avoir redéployée ma base de données du service de recherche d'aide via mon alias, j'ai pu supprimer ma référence de serveur sans soucis...

Ce cas illustre encore une fois le risque de suivre les actions données sur Internet, surtout si celles-ci vont à l'encontre des bonnes pratiques : on ne doit pas toucher aux bases SharePoint !!! Microsoft ne supporte même pas les requêtes SELECT sur ces bases, il ne s'agit donc pas juste de modifier la base, mais rien que lire les données de cette base en dehors des API SharePoint n'est pas supporté... Notez que pour SharePoint 2010 il me semble avoir lu que MS supporte la lecture, mais toujours pas évidemment l'écriture en direct dans les bases (sauf peut-être celle de logging, à vérifier)


Bon code à tous,
Edgar


Note : les plus perspicaces d'entre-vous se seront rendu compte que ma requête pour retrouver les objets parent n'est donc pas supportée... Gardez cela à l'esprit si vous suivez cette démarche (bon en même temps je ne pense pas que cela gêne quoi que ce soit sur la table Objects...).