Vos tables sont-elles un gruyère ? Y a-t’il eu des anomalies d’alimentation à votre insu qui ont laissé des trous de date ? Dans le cadre d'un audit de serveur SQL, nous souhaitons vérifier rapidement la fiabilité des données. L'article ci-dessous présente une méthode semi-automatique de recherche de trous ou d'anomalies de date dans les tables, généralement dus à des erreurs d’alimentation.

Des performances exceptionnelles peuvent être obtenues lors des insertions massives de données telles que lors des imports à condition de minimiser les index et en particulier de supprimer tous les index qui ne sont pas fondamentalement nécessaires à assurer la cohérence des données.Cet article présente une technique qui automatise la désactivation temporaire des index et sa réactivation afin de satisfaire un tel besoin.

Il existe bien plus de commandes DBCC que ne le laisse supposer la documentation et certaines sont bien utiles à l'administrateur... Tous les secrets des commandes non documentées !
Pour SQL Server 7.0, 2000 et 2005

Il n’est pas rare de souhaiter exécuter la même instruction sur chacune de tables d’une base de données ou sur chacune des bases de données d’une instance SQL Server. Plutôt qu’écrire un bout de code avec un curseur travaillant sur SYSOBJECTS ou SYSDATABASES, essayez les procédures stockées sp_MSforeachtable et sp_MSforeachdb.

Vous souhaitez mieux comprendre mieux le fonctionnement des dates dans SQL Server...

L’objectif de cette présentation de base n’est pas de refaire ce qui existe déjà par ailleurs, mais de ‘rafraîchir’ la mémoire pour certains, ou de donner pour d’autres des notions basiques qui pourront être approfondies dans d’autres articles, livres, sites ou sources diverses et qui permettront de mieux comprendre le fonctionnement du journal de transactions.

Dans la version 2005 de SQL Server, vous pouvez envoyer des messages via SMTP par défaut avec SQLEmail. En version 7.0 et 2000, on passe par MAPI. Comment utiliser SMTP avec ces 2 versions ?