MOSS 2007 : Activer les statistiques d’un site

Comment accéder à de magnifiques rapports d’utilisation du site ? (camemberts, diagrammes…)
Voici les 3 manipulations à effectuer pour activer les statistiques sur un site MOSS :

  • Activer le journal de traitement de l’analyse
  •  » Admin centrale Sharepoint > Opération > Traitement de l’analyse de l’utilisation « 
  • Cocher  » Activer le journal « 
  • Emplacement : Donner (pourquoi pas) le même répertoire que les logs wss.
  • Nombre de fichiers : Nb de serveurs de BDD * 3 (préconisation MS).
  • Cocher  » Activer le traitement « .
  • Donner un intervalle de temps d’au moins 1/2 heure, le midi ou le soir.
  •  » OK « 

Dans les services partagés du site :

  • Cliquer sur « Rapports d’utilisation » dans la section « Rapports d’utilisation d’Office SharePoint ».
  • Cocher les deux cases, et faire « OK »

L’URL de la page qui va contenir les stats du site est :
http://mon_site/_layouts/SPUsageWeb.aspx

MOSS 2007 : Restaurer une liste ne restaure pas les ID des enregistrements !

Catastrophe : vos identifiants d’items de liste n’ont plus rien à voir avec ceux d’antan !
Imaginons qu’une liste contient des enregistrements qui sont référencés par d’autres listes via leur champ ID (champ présent dans toute liste).
Maintenant restaurons cette liste (pour une raison lambda).
Bam ! Là, c’est le drame.Les ID ne sont pas restaurés… C’est une colonne auto-increment, donc les nouveaux ID reprendront là ou le dernier enregistrement s’était arrêté.
Tous les liens vers les autres listes sont cassés…
Moralité : éviter les liens vers cette colonne ID (autant créer son propre champ identifiant).
Solution 1 : Faire des UPDATE AllUserData SET ID = 111 etc. pour remettre d’équerre tous ces ID (bon courage)
Solution 2 : Je ne la connais pas encore, mais il y a sans doute moyen de forcer à quel ID commencer. En supprimer la liste, et en la recréant… A voir.

MOSS 2007 : Error logs 6482 7076 et 6398 toutes les minutes.

Solution naturelle à un bug surnaturel.
Comment réussir à stopper net ces trois erreurs récurrentes du minuteur : 6482, 7076 et 6398 ?
Pour ma part, j’avais toute les minutes ces erreurs de générées dans le journal des événements.
Les messages ressemblaient à ça : “ Old format or invalid type library ” ("Ancien format ou bibliothèque de types non valide") ou “ Not enough storage ” ("Espace insuffisant pour traiter cette commande").
Pour autant, ma ferme SharePoint fonctionnait normalement.
Solution :Installer les deux KB suivants disponibles via ce lien :

  • KB923028
  • KB918642

Ces vilaines traces devraient disparaitre… MSDN ? Lave plus blanc que blanc.

SQL Server : Fichier de Log (.LDF) qui devient énorme.

Comment diminuer de taille le fichier de transactions en un seul script SQL ?
Lorsqu’une base de données est en mode de récupération « Full » (Complète), les fichiers journaux .LDF peuvent devenir énormes (toutes les transactions sont enregistrées).
En lancant le script SQL ci-dessous, vous allez sauvegarder vos bases et fichiers de transaction, et diminuer la taille du fichier LDF :

-- Sauvegarde complète
BACKUP DATABASE MaBase TO DISK = ’S:mssqlMaBase.bak’
GO
BACKUP LOG MaBase TO DISK = ’S:mssqlMaBase_log.bak’
GO
USE MaBase
GO
-- (MaBase_log est le nom LOGIQUE du fichier LDF physique... A vérifier donc !)
DBCC SHRINKFILE(MaBase_log)
GO

NB : le fait de faire une sauvegarde complète d’une BDD vide le fichier de log « LDF »… mais ne diminue pas sa taille ! C’est pourquoi il faut faire un SHRINKFILE.
NB2 : C’est pourquoi il est important de faire une sauvegarde complète une fois par jour, afin d’empêcher le fichier LDF de grossir démesurément (le fichier se « videra » puis l’espace sera réutilisé…)
NB3 : Il faut également réfléchir à passer en mode de récupération SIMPLE. Le fichier LDF ne grossira pas autant, mais la perte de données admissible en cas de crash sera plus grande.
 

SQL Server : Erreur lors d’un update de plusieurs lignes en même temps.

« La sous-requête a retourné plusieurs valeurs. Cela n’est pas autorisé… »
Une commande UPDATE toute simple mettant à jour plusieurs enregistrements peut facilement dégénérer en une erreur fort intrigante.
Exemple :
UPDATE ma_table SET departement = 44 WHERE ville = ’Nantes’
SQL Server va renvoyer l’erreur suivante :

Msg 512, Niveau 16, �tat 1, Procédure reconduite_u, Ligne 14
La sous-requête a retourné plusieurs valeurs.
Cela n’est pas autorisé quand la sous-requête suit =, !=, <, <= , >, >= ou quand elle est utilisée en tant qu’expression.
L’instruction a été arrêtée.

Sans entrer dans les détails, il faut d’abord vérifier la présence d’un éventuel TRIGGER attaché à cette table. Il suffit de le désactiver pour que la commande UPDATE se passe bien.

MOSS 2007 : Problème de backup dans une topologie 3-tiers

Dans une topologie 3-tiers (1 serveur de BDD, 1 serveur d’admin WSS, 1 serveur web frontal), il est important de respecter certaines proconisations pour lancer un stsadm -o backup :

  • Utiliser un chemin UNC (\SERVERNAMEetc.) pour décrire le chemin physique de stockage du fichier de backup. En effet, le serveur de BDD va écrire dans ce répertoire. Etant donné qu’il est « distant », il faut lui donner un chemin d’accès adéquat.
  • Donner les droits d’écriture pour ce répertoire au compte de service de SQL Server.

SQL Server : Passer des paramètres à un fichier .sql avec la commande sqlcmd

Voici un exemple de fichier script.sql :

USE ma_base
GO
UPDATE ma_table SET un_champ = ’Une valeur’ WHERE un_autre_champ = ’$(Parametre1)’
GO

Notez la présence de $(Parametre1) qui indique que le script attend une valeur passée en paramètre, dont le nom est Parametre1
Maintenant, voici le fichier .bat qui va appeler ce script SQL via la commande sqlcmd :

@echo off
sqlcmd -S mon_serveur_de_bdd -i script.sql -v Parametre1="Une autre valeur"
pause

Du coup, la requête lancée sera :
UPDATE ma_table SET un_champ = ’Une valeur’ WHERE un_autre_champ = ’Une autre valeur’
C’est pas beautiful ça ?

BATCH : Codes retour (errorlevel )

Dans un fichier .bat, il est souvent nécessaire de retourner un code erreur afin de vérifier son bon fonctionnement.
A la fin du fichier, il suffit d’entrer la commande exit /b number
errorlevel est une instruction qui retourne le code erreur le plus élevé retourné durant l’exécution du batch.
En faisant if errorlevel 3 exit /b 3, on teste si il y a eut une erreur durant le script, et on sort avec ce même code erreur
Le code complet serait :

if errorlevel 3 exit /b 3
if errorlevel 1 exit /b 1
if errorlevel 0 exit /b 0

ATTENTION, si le code erreur est 3, alors errorlevel 3 renvoie vrai, mais aussi errorlevel 2 ou 1, ou 0 !
Errorlevel renvoie VRAI si le code erreur est inférieur ou égal au nombre.

T-SQL : Boucler sur un curseur

Etant donné que j’oublie à chaque fois cette structure de code, je la placeune fois pour toute :

DECLARE @ma_var1 VARCHAR(255), @ma_var2 VARCHAR(255)
DECLARE mon_curseur CURSOR FOR
   SELECT col1, col2 FROM ma_table
OPEN mon_curseur
FETCH NEXT FROM mon_curseur INTO @ma_var1, @ma_var2
WHILE @@FETCH_STATUS = 0
BEGIN
   FETCH NEXT FROM mon_curseur INTO @ma_var1, @ma_var2
END
CLOSE mon_curseur
DEALLOCATE mon_curseur