Partager via

Comment gérer null et DBNull

  • Article

Cette rubrique décrit les comportements que l'on peut attendre de valeurs nulles associées à différents types, et traite des options de vérification de l'absence ou de l'existence d'un champ ou membre donné.

XML

Les points suivants s'appliquent aux valeurs XML :

  • Une valeur XML ne sera jamais retournée d'un document comme étant null. Elle correspond soit à une chaîne vide soit à une erreur « n'existe pas ». Lorsqu'il s'agit d'une chaîne vide, une erreur pourra se produire lors de la conversion de certains types, par exemple des champs spécifiés comme appartenant à un type entier au moment de la création des règles.

  • Le compositeur de règles métier ne vous permet pas de définir un champ sur null ou de définir le type d’un champ sur un objet.

  • Via le modèle objet, vous pouvez définir le type sur Objet. Dans ce cas, la valeur retournée est le type auquel le XPath évalue : float, booléen ou string, en fonction de l’expression XPath.

classes .NET

Les règles suivantes s'appliquent aux classes .NET :

  • Vous n’êtes pas autorisé à comparer à null si votre type de retour n’est pas un type d’objet .

  • Vous pouvez transmettre null comme paramètre pour les paramètres qui ne sont pas des types de valeur mais, selon l'implémentation du membre, une erreur d'exécution se produira.

  • Vous pouvez définir des champs de types dérivés de l’objet sur null.

Connexion de données

L'exemple suivant s'applique à une connexion de données :

  • Vous pouvez comparer n’importe quelle colonne de table de base de données à null, si la table autorise les valeurs null pour la colonne et que le type de colonne n’est pas text, ntext et image.

    Notes

    Le compositeur de règles métier vous permet d’utiliser des colonnes de type, texte et ntext, dans des conditions. Toutefois, lorsque vous exécuterez la stratégie, vous recevrez un message d'erreur vous indiquant que les types de données text, ntext et image ne peuvent être comparés ou triés, hormis avec les opérateurs EST NULL ou COMME.

  • Vous pouvez définir toute colonne de table de base de données sur la valeur null si la table autorise ce type de valeur pour la colonne.

  • Le compositeur de règles métiers définit automatiquement le type de membre dans la liaison sur un objet, si vous comparez ou définissez la valeur null pour un type valeur ; il revient au type d’origine si vous réinitialisez ou remplacez l’argument.

  • Pour un type de chaîne, il change le type en objet si vous le définissez sur null, mais le laisse comme chaîne si vous comparez à null.

  • Vous ne pouvez pas comparer ou définir sur DBNull.Value à partir du Compositeur de règles métier, car il ne changera pas le type de colonne en objet.

  • Le moteur convertira une valeur DBNull en null à des fins de comparaison et convertira null en valeur DBNull en vue d'une insertion dans la base de données.

  • Les tests ignoreront les valeurs null (c'est ainsi que fonctionne SQL Server). Par exemple, si vous avez la règle « IF db.column > 5 THEN . », seules les lignes qui ont une valeur dans db.column sont testées. Les lignes avec null sont ignorées.

TypedDataTable et TypedDataRow

Les points suivants s'appliquent à TypedDataTable et TypedDataRow :

  • Le compositeur de règles métiers modifie le type de champ en objet de la même manière qu’avec dataConnections.

  • À moins que vous n'effectuiez des comparaisons avec null, les tests échoueront pour les valeurs null. Par exemple, il y aura une erreur dans la règle « IF db.column > 5 THEN », si une ligne déclarée a une valeur null.

    Notez que, étant donné que les conditions sont évaluées en parallèle, les tests tels que « IF db.column != NULL AND db.column > 5 THEN » échouent toujours, car les deux tests sont potentiellement évalués sur chaque ligne.

Vérification de l'absence ou de l'existence

Lorsque l'on écrit des règles d'entreprise, il est naturel de vérifier l'existence d'un champ avant de comparer sa valeur. Toutefois, si le champ est null ou qu'il n'existe pas, la comparaison de la valeur génèrera une erreur. Supposons que la règle suivante existe :

SI le produit/la quantité existe ET le produit/la quantité > 1

Une erreur sera levée dans la règle si Product/Quantity n'existe pas. L'un des moyens de contourner ce problème est de transmettre un nœud parent à une méthode d'assistance qui retourne la valeur de l'élément si elle existe ou autre chose sinon. Voir les règles qui suivent.

Règle 1

IF EXISTS(Product/Quantity) THEN ASSERT(CREATEOBJECT(typeof(Helper), Product/Quantity)

Règle 2

IF Helper.Value == X THEN...

Une autre solution consiste à créer une règle telle que celle-ci :

IF Product/Quantity Exist Then CheckQuantityAndDoSomething(Product/Quantity)

Dans l'exemple précédent, la fonction CheckQuantityAndDoSomething vérifiera la valeur du paramètre et s'exécutera si la condition est remplie.

Notes

Vous pouvez également modifier la propriété XPath Field pour le fait XML afin d’intercepter les erreurs, mais ce n’est pas l’approche recommandée.