Juil 30

SQL-Server-2012Certaines opérations sur les bases de données Sql Server nécessitent qu’il n’y ait plus aucun utilisateur connecté à la base de données, par exemple la restauration d’un backup.

Le problème, c’est que Sql Server n’est pas très généreux en ce qui concerne les outils d’administration et qu’il n’est pas toujours simple de savoir si des utilisateurs sont connectés ou de les déconnecter.

La solution passe donc par quelques commandes SQL.

Pour désactiver la base de données en déconnectant tous les utilisateurs :

ALTER DATABASE db_AdventureWorks SET OFFLINE WITH ROLLBACK IMMEDIATE

Et pour la réactiver une fois l’opération terminée :

ALTER DATABASE db_AdventureWorks SET ONLINE
Juil 24

sqlserver_connectUn problème qui finit toujours par arriver aux utilisateurs de Sql Server 2008 : l’interface de connexion finit par être polluée par de nombreux serveurs ou utilisateurs qui ne sont pas ou plus utilisés !

En effet, Sql Server a tendance à enregistrer un peu tout ce que l’on saisit que ce soient les serveurs ou les utilisateurs, même les erreurs ou des logins qui ne fonctionnent pas.

Ainsi, il arrive assez souvent que l’on ait envie de supprimer des éléments de ces listes qui ne font que s’allonger. Apparemment c’est une question que beaucoup se posent et malheureusement la réponse la plus courante ne me satisfait pas, car elle implique de supprimer toutes les valeurs, au lieu de juste supprimer celles qui ne nous intéressent pas.

La solution pour supprimer uniquement les valeurs que l’on souhaite est de passer par le logiciel Sql Server 2008 MRU Updater qui se charge de faire les modifications.
Je l’ai testé et il marche nickel !

A noter que cette fonctionnalité a été intégrée à Sql Server 2012.

Fév 25

SQL-Server-2012Une chose assez ennuyeuse dans SQL Server Management Studio (SSMS), c’est que la fonction de génération de scripts SQL n’inclut pas par défaut les index. Il y a probablement (enfin j’espère) une bonne raison derrière ce choix, mais il s’avère que dans la pratique, j’ai systématiquement besoin que ces index soient présents et je me suis fait avoir plusieurs fois, à me retrouver avec des soucis de performances suite à une livraison.

Ainsi, avec les options par défaut, les index (autres que les clés primaires, étrangères et index uniques) ne sont pas générés lorsqu’on demande la génération du script SQL pour la création d’une table.

Pour changer cela, il suffit d’aller dans les options de SSMS, qui permettent de choisir toutes les valeurs par défaut pour la génération de script :
Donc, dans SSMS, aller dans Tools –> Options –> SQL Server Object Explorer –> Scripting et positionner Script indexes à True.

options-scripting-sql-server

Source : Forum MSDN

Fév 18

Logo Visual StudioDans un précédent article, nous avons abordé la question de la transformation du fichier App.Config, en fonction de l’environnement cible.
Or généralement, la cible par défaut, Debug est uniquement utilisée pour le développement et utilise donc une configuration particulière qui ne doit pas forcément être publiée.

Ainsi, sur tous mes projets, je créé les cibles Recette, Qualif, Production (et autres, en fonction du besoin), tout en conservant les cibles existantes Debug et Release. La première étant la configuration utilisée pour le développement, la seconde étant rarement utilisée.
Le problème est donc qu’il arrive occasionnellement de lancer une publication sans avoir changé l’environnement cible, ce qui provoque la copie de paramètres de configuration de débogage sur un environnement ne correspondant pas à cette configuration.

Afin d’éviter de publier accidentellement en configuration Debug, il suffit d’ajouter les lignes suivantes à la fin du fichier *.csproj de votre projet principal (à ouvrir avec un éditeur texte), juste avant la balise de clôture </project> :

<Target Name="BeforePublish">
	<Error Condition="'$(Configuration)'=='Debug'" Text="Ce projet ne doit pas être publié en DEBUG. Choisissez l'environnement cible approprié." />
	<Error Condition="'$(Configuration)'=='Release'" Text="Ce projet ne doit pas être publié en RELEASE. Choisissez l'environnement cible approprié." />
</Target>

Cette modification va interrompre la publication si la configuration actuellement sélectionnée est Debug ou Release (car je ne l’utilise pas) en affichant le message spécifié.

Jan 22

Logo Visual StudioEric Lippert, développeur ayant participé au design du langage C# chez Microsoft et ayant participé au développement du compilateur publie actuellement sur son blog, Fabulous Adventures In Coding, une série de billets extrêmement intéressants concernant les décisions prises et les nombreuses optimisations mises en place lors de l’introduction de la classe Nullable<> pour la version 2.0 du Framework .NET.

Ils sont notamment intéressants car ils permettent d’avoir une toute petite idée du travail titanesque qu’est la création d’un langage et d’un compilateur, des choix qu’il est nécessaire de faire, de tous les facteurs qu’il faut garder en tête lorsque l’on décide de la moindre modification, surtout quand on considère qu’il s’agit là uniquement de l’ajout d’une seule classe (certes très utile). Il est également impressionnant de voir la quantité de techniques utilisées pour optimiser la compilation du code.

Attention, ces billets sont très techniques (et en anglais) !

Je mettrais à jour l’article lorsqu’Eric ajoutera d’autres chapitres.