SQL Server - NULL, or NOT NULL : that is the question !

Il arrive assez souvent de constater dans les script de création de tables (CREATE TABLE) ou de modification de structures de tables (ALTER TABLE), que certaines colonnes ne sont dotées d'aucune mention précisant leur caractère nullable ou non-nullable.

SQL Server - Gestion des exceptions TRY .. CATCH.. Rendre une application plus robuste

I - Introduction

Depuis SQL Server 2005, (et donc valable également sous SQL Server 2008, 2008 R2 etc.), il est enfin possible de gérer sérieusement les exceptions au travers les constructions TRY CATCH.
La gestion des erreurs dans les versions précédentes, sous SQL Server 2000 par exemple, n'était pas vraiment à la hauteur et n'était pas digne d'un langage évolué moderne.
Sous SQL Server 2000, la détection et la gestion des erreurs déclenchées par les commandes T-SQL ne pouvaient être effectuées qu'en vérifiant le contenu de la variable système globale @@error. Celle-ci retourne le numéro d'erreur déclenchée par la dernière instruction T-SQL exécutée. Donc, sous SQL Server 2000, Il fallait lire le contenu de la variable @@error après chaque instruction T-SQL ! Il faillait, en plus, généralement, stocker le contenu de @@error dans une variable locale ! En effet, la variable globale @@error est effacée et réinitialisée (remise à zéro) à chaque exécution d'une instruction. Cette approche complètement archaïque conduisait à surcharger le code T-SQL des procédures par des instructions comme « IF @@error <> 0 .. » jusqu'à le rendre illisible !

La construction TRY ..CATCH disponible depuis SQL Server 2005 (et donc valable également sous SQL Server 2008, 2008 R2 etc.), offre une syntaxe beaucoup plus lisible, avec laquelle les développeurs sont déjà habitués au travers d'autres langages évolués comme C# ou C++.

Dans cet article, je vais vous présenter, au travers d'exemples concrets, comment grâce à la construction TRY CATCH, combinée à l'option XACT_ABORT, et à la fonction XACT_STATE(), vous pouvez écrire du code T-SQL robuste intégrant une gestion sérieuse et solide des erreurs. Dans cet article, j'explique également comment, au travers ces nouvelles constructions (TRY CATCH, etc.),  annuler et mettre fin aux transactions en erreur et libérer ainsi les verrous posés sur les enregistrements par les transactions.

La conjecture des nombres premiers jumeaux

Deux nombres premiers jumeaux sont deux nombres distants de 2 unités.
Parmi les plus petits nombres premiers jumeaux, vous avez :
3-5,  7-9,  11-13,  17-19,  29-31, etc.

La conjecture des nombres premiers jumeaux stipule ceci :
« Il existe une infinité de nombres premiers jumeaux »

Les observations numériques et des raisonnements heuristiques semblent justifier la conjecture, mais aucune démonstration n'en a encore été faite !

SQL Server - Démystifier le type DATETIME et utiliser le format ISO 8601


I - Introduction

La manipulation des dates sous SQL Server a toujours été un cauchemar pour les utilisateurs et même pour les développeurs. Dans les forums dédiés à SQL Server, vous rencontrerez une avalanche de questions au sujet de type DATETIME.

Ces difficultés, à mon sens, proviennent, d'une part du fait que les fonctions, fournies par SQL Server, ne sont pas assez évoluées pour une manipulation aisée des dates (des améliorations ont été apportées sous SQL Server 2012 pour combler cette lacune, mais au moment où je rédige cet article, tout le monde n'utilise pas encore SQL Server 2012 ! Aussi je n'aborde pas le sujet.), d'autre part, de la confusion, ou de la non compréhension, du type DATETIME, tel qu'il est perçu par les utilisateurs et même par les développeurs.

Ces difficultés se déclinent sous 2 aspects :
- L'aspect expression des dates. C'est à dire, « comment exprimer, de manière littérale, une constante date ».
- L'aspect présentation des dates. C'est à dire, « comment présenter les dates au format chaîne de caractères pour les besoins de reporting etc ». Exemple « le Lundi 12 octobre 2012 à 15h20 ».

Le présent article traite et met l'accent sur le premier aspect du problème, c.à.d « l'expression et la manipulation des constantes DATETIME sous forme littérale ».

Comment déboguer les procédures, fonctions et triggers sous SSMS 2008 (SQL Server 2008 Management Studio)


Vous trouverez ci-dessous le lien vers un article que j'ai publié sur le site  developpez.com, un des plus importants sites francophones dédiés au développement informatique.

Cet article explique comment déboguer une procédure stockée, une fonction ou un trigger sous SSMS 2008 (SQL Server 2008 Management Studio). En d'autres termes, il explique comment définir des points d'arrêts, comment faire du pas à pas dans les blocs T-SQL, comment consulter le contenu des variables locales et variables systèmes @@, etc.

Comment déboguer les procédures, fonctions et triggers sous SSMS 2008 (SQL Server 2008 Management Studio)

La version de l'article au format  pdf ainsi que la version, hors lignes, au format html, sont  téléchargeables depuis le même lien ci-dessus.

La conjecture des nombres parfaits impairs

On connait des nombres pairs qui sont égaux à la somme de leurs diviseurs propres. Exemple :
6 = 1+2+3
28 = 1+2+4+7+14
On dit que 6 et 28 sont des nombres parfaits. On connait, en tout et pour tout aujourd’hui, 47 nombres parfaits ! Mais on ne sait pas s'il en existe une infinité (?). On conjecture que 'Oui'.
Plus intéressant encore, on ne connait aucun nombre parfait impair, sans que jamais personne n'ait pu démontrer qu'il n'en existe pas.
L'affirmation « Il n'existe aucun nombre parfait impair » est une conjecture jugée aujourd'hui très vraisemblable mais non prouvée !
On a juste pu établir et démontrer que si n est un nombre parfait impair, alors il possède au moins 300 chiffres (donc pas la peine de chercher des nombres parfaits impairs à la main !).

Décidabilité, indécidabilité algorithmique d'un problème et programmes informatiques


Définition : Décidabilité, indécidabilité algorithmique d'un problème
Un problème est dit décidable s'il existe un algorithme, une procédure qui termine en un nombre fini d'étapes, qui le décide, c'est-à-dire qui réponde par oui ou par non à la question posée par le problème.
S'il n'existe pas de tels algorithmes, le problème est dit indécidable.

Exemple de problème indécidable : L'indécidabilité du problème de l'arrêt
L'indécidabilité du problème de l'arrêt a été démontrée par Alan Turing en 1936 :
« Il n'existe pas d'algorithme qui permette de décider si, étant donnée une machine de Turing quelconque et son état initial, le calcul de celle-ci s'arrête ou non ».

Du fait de la thèse de Church (du mathématicien Alonzo Church), ce résultat est très général. Depuis l'apparition de l'informatique, on peut l'interpréter ainsi :
« Il n'existe pas de programme permettant de tester n'importe quel programme informatique écrit dans un langage suffisamment puissant, tel que tous ceux qui sont utilisés aujourd'hui en pratique, afin de conclure dans tous les cas s'il s'arrêtera en un temps fini ou bouclera à jamais ! »

L'infini et l'hypothèse du continu (HC)


Pendant très longtemps, jusqu'à la fin du XIX siècle, l'étude de l'infini était considérée comme n'appartenant pas à la science. L'étude de l'infini était du domaine de la philosophie voire même de la religion. C'est grâce à la témérité de Bolzano et de Cantor que l'infini devient un sujet mathématique légitime.
Avant d'exposer l'hypothèse du continu (HC), je voudrais, avant toute chose, rappeler quelques définitions.

SQL Server - Quel type de données choisir Float ou Decimal ?

Il arrive assez souvent, lors de la conception d'une base de données, que certains hésitent sur le choix du type de données d'une colonne. Ils se posent la question, tout à fait légitime : « Dois-je choisir le type Float ou le type Decimal ? » (pour ne citer que ces 2 types de données numériques). 
Il est vrai que la réponse n'est pas évidente et fait même parfois l'objet de discussions interminables sur les forum ! 
Cet article se propose de vous aider ou du moins de vous éclairer et vous permettre de faire un choix, en toute connaissance de cause.