Problème de DBNull

Version imprimable

Problème de DBNull

:salut:

J'ai un problème dans le traitement des valeurs de type DBNull. J'ai peux tester ce que je veux, rien n'y fait...
Code:

1 2 3 4 5 w.InsertText("InfosNomAggloAss", IIf(Not _ds.V_INFOS_GENERALES.Item(0).NOM_AGGLO_ASS = "", _ds.V_INFOS_GENERALES.Item(0).NOM_AGGLO_ASS.ToString(), "")) ... w..InsertText("InfosNomAggloAss", IIf(Not _ds.V_INFOS_GENERALES.Item(0).IsNOM_AGGLO_ASSNull(), _ds.V_INFOS_GENERALES.Item(0).NOM_AGGLO_ASS.ToString(), "")) ... w.InsertText("InfosNomAggloAss", IIf(Not _ds.V_INFOS_GENERALES.Item(0).NOM_AGGLO_ASS Is DBNull.Value(), _ds.V_INFOS_GENERALES.Item(0).NOM_AGGLO_ASS.ToString(), ""))
Y a-t-il une autre solution ? J'ai une quinzaine de lignes de ce genre à la suite et j'aimerais éviter de mettre un bloc Try pour chacune d'entre elles :aie:
Le retour m'indique que mon champ est DBNull mais bon, c'est bien ce que je test quoi, c'est un peu débile leur histoire :weird:

:merci:

23/03/2016, 13h51
Kropernic

Perso, j'ai aussi toutes les peines du monde à traiter les marqueurs NULL en .NET.

Du coup, je m'arrange pour que mes requêtes ne renvoient JAMAIS de marqueurs NULL.

Et alors tout est beaucoup plus simple :)

Maintenant, je ne connais pas ton besoin ni ton process flow. Peut-être que ce n'est pas envisageable dans ton cas... (ce serait con :aie:)
23/03/2016, 14h49
mermich

Salut,

A une epoque j'avais fait un helper qui faisait un try catch bien degueux pour mutualiser ce genre de chose. Cela prenait une lambada en parametre et un second parametre qui definissait la valeur en cas de catch (j'ai plus les sources).

a l'utilisation ca donnait un truc du genre:

Code:

w.InsertText("InfosNomAggloAss", _ds.V_INFOS_GENERALES.Item(0).EvaluateOr(i=>i.NOM_AGGLO_ASS.ToString(), "")

De plus, je crois que tu le sais mais le IIF en vbnet execute les deux cotes du if, donc utilisation a proscrire.
23/03/2016, 15h06
J@ckHerror

Bonjour,

Je ne comprends pas le problème, je dois passer à coté de quelques choses mais je ne vois pas l’intérêt d'entourer ces lignes d'un try/catch :weird: la partie de test sur le DBNull ne peut pas générer d'exception, c'est d'ailleurs à mon sens le but de ce test.
En tout cas je n'ai jamais eu de problème avec les DBNull, après il est vrai que tous mes champs en base sont not null (sauf les blob) mais je tests les champs DBNull pour par exemple savoir si une jointure a échoué.

Sinon pour info (et que mon poste apporte quelque chose :D ) il existe Convert.IsDBNull

J@ck
23/03/2016, 15h14
mermich

@J@ckHerror:
le premier probleme vient du fonctionnement de la methode IIf elle meme:

Citation:

Because the IIf function does not use short-circuit evaluation, it always evaluates all three of its arguments.

cf:https://msdn.microsoft.com/en-us/lib...or=-2147217396

donc meme si t'as tester le dbnull dans la premier partie du iif, eh bien ceci sera evalue:

Code:

_ds.V_INFOS_GENERALES.Item(0).NOM_AGGLO_ASS.ToString()

Donc oui la methode IIf est une plaie de vbnet

Ensuite le second 'probleme' vient de la verbosite du truc, c'est hyper penible a copier colle ce genre de ligne. :aie:

Merci Mermich ,
Je suis plus C# du coup les subtilités de IIf me sont inconnues, je pensais que le problème était sur la détection des champs DBNull.
Sinon oui en effet c'est verbeux ... ! il faut tester tous les champs.

Peux être qu'une méthode d’extension sur Object permettrait de rendre le test plus sexy. On passe en paramêtre la valeur par défaut si c'est DBNull.

Quoique avec les type générique un truc comme
Code:

1 2 3 4 5 6 7 8 public static T GetValueOrDefaut<T>(this object me) { if (!Convert.IsDBNull(me)) return (T)me; else return default(T); }
devrait même être encore plus sexy 8-)
Il faudra peut être renforcer les tests pour être sur que le transtypage ne plante pas, mais c'est déjà pas mal comme ça.

Je vais le tester tiens ...

J@ck.

[EDIT] désolé c'est du c#
le code VB equivalent doit pas être loin de :
Code:

1 2 3 4 5 6 7 8 <Extension()> Public Sub GetValueOrDefaut(Of T)(ByVal aObject As Object) As T If not Convert.IsDBNull(aObject) return CType(aObject,T) End If return CType(Nothing, T) End Sub

24/03/2016, 23h30
Invité

Bonsoir,
Si tu concatène un chaine vide avec un chaine null tu as un chaine vide!
"" + _ds.V_INFOS_GENERALES.Item(0).NOM_AGGLO_ASS.ToString()
25/03/2016, 14h53
J@ckHerror
Bonjour,

@rduRupt j'ai pas compris ton intervention !
Nous ne parlons pas de chaine null mais de DBNull ici ! Je pense que tu es hors sujet.

Sinon j'ai testé ma petite méthode d'extension et c'est formidable 8-) !
Plus sérieusement c'est fonctionnel, je l'ai nommée autrement mais sinon elle est ok.

Dans l'exemple donné par @Franck.H ça donnerait :
Code:

1 2 w.InsertText("InfosNomAggloAss", _ds.V_INFOS_GENERALES.Item(0).NOM_AGGLO_ASS.GetValueOrDefaut<string>())
Bon week end et Joyeux Pâques

J@ck.
25/03/2016, 15h01
Invité

Bonjour,
oui en effet je suis hors sujet! dessolé :oops:
30/03/2016, 08h09
Franck.H

:salut:

Désolé pour le retard dans mes réponses... Effectivement, j'avais complètement oublié la particularité du IIf... Une méthode d'extension me paraît effectivement pas mal du tout, cela évite de mettre des conditions à tout va dans le code, du moins directement et ça rendra le code plus lisible, c'est que j'essayais de faire avec IIf :mrgreen::aie:

Merci pour votre aide ;) :ccool:

Au passage, je vous donne mon code.

Code:

1
2
3
4
5
6
7
8
9
10
11
12
Imports System.Runtime.CompilerServices
 
Module ExtensionMethods
    <Extension()>
    Public Function GetValueOrDefault(Of T)(ByVal o As Object) As T
        If Not Convert.IsDBNull(o) Then
            Return CType(o, T)
        End If
 
        Return CType(Nothing, T)
    End Function
End Module

30/03/2016, 08h43
Franck.H

Cela dit, j'ai tout de même un problème avec cette méthode d'extension:

Code:

.InsertText("InfosNomAggloAss", _ds.V_INFOS_GENERALES.Item(0).NOM_AGGLO_ASS.GetValueOrDefault<String>())

Citation:

Erreur 1 Le paramètre de type 'T' pour la méthode d'extension 'Public Function GetValueOrDefault(Of T)() As T' définie dans 'ExtensionMethods' ne peut pas être déduit.
Erreur 2 'String' est un type classe et ne peut pas être utilisé en tant qu'expression.

[EDIT]
Correction:

Code:

.InsertText("InfosNomAggloAss", _ds.V_INFOS_GENERALES.Item(0).NOM_AGGLO_ASS.GetValueOrDefault(Of String)())

C'est vu VB pas du C#... Le temps que je percute... :aie:
30/03/2016, 09h00
Franck.H

Finalement, ça me déclenche tout de même une exception :weird:
30/03/2016, 09h10
J@ckHerror

Bonjour,

Étrange :weird:! qu'elle est l'exception ?
Pour moi, en C#, je n'ai pas eu de problème, après vérification je ne convertie qu'en int pour le moment, mais je vois pas de raison que string ne passe pas...

J@ck.
30/03/2016, 09h21
Franck.H

Citation:

Envoyé par J@ckHerror

Étrange :weird:! qu'elle est l'exception ?

Comme d'habitude...

Code:

La valeur pour la colonne 'NOM_AGGLO_ASS' dans la table 'V_INFOS_GENERALES' est DBNull.
30/03/2016, 12h08
J@ckHerror

ouep :weird: bizarre cette affaire.

Je ferais des tests ce midi ou en début d'aprem...
Au cas ou vous auriez déjà débuggé la méthode, si vous savez qu'elle ligne retourne l'exception et si on rentre ou pas dans la méthode d'extension dans le cas d'un DBNull (dans mon cas j'ai essayé et je rentre dedans même pour un DBNull)

J@ck.

Re,

Je ne comprends pas :calim2:, je me suis fais un petit programme de test vite fait et pas de problèmes avec les string 8O
Le problème vient peut-être de la traduction vers VB.net que je ne connais pas vraiment.

Mon petit test =>
Code:

1 2 3 4 5 6 7 8 9 10 string ordre = "SELECT reference, Texte FROM TempMax"; DataTable dt = SQLRequeteLibre.GetDataTable(ordre); foreach(DataRow r in dt.Rows) { Console.WriteLine("Res => {0}", r["Texte"].ParseDBNullValue<string>()); } Console.ReadKey();
Bien entendu dans le champs TempsMax.Texte j'ai des DBNull et des chaines.

Et le code de l'extension =>
Code:

1 2 3 4 5 6 7 8 public static T ParseDBNullValue<T>(this object me) { if (!Convert.IsDBNull(me)) return (T)me; else return default(T); }
Pour le coup je pense pas pouvoir en dire beaucoup plus ne connaissant pas VB.net, en tout cas l'idée est là et c'est fonctionnel en C#.

J@ck.

30/03/2016, 15h20
Kropernic

Hello,

Juste une question.

Je comprends tout à fait l'intérêt à vouloir traiter les DBNULL d'un point de vue académique (apprendre à faire les choses) et même plus simplement pour avoir la satisfaction d'avoir réussi à franchir l'obstacle mais ne serait-il pas plus simple, à condition que ce soit une requête propre au projet et pas une utilisée par d'autres applicatifs, de faire en sorte de "supprimer" les DBNULL du résultat ?

Je veux dire, un DBNULL quand on attend un string, on va quand même afficher une chaîne vide. Du coup, pourquoi ne pas laisser faire le SGDB qui fait ça beaucoup mieux que .NET à l'aide d'un simple COALESCE ? En plus, j'me demande même si ce ne serait pas plus performant (juste une intuition, aucun vrai argument là-dessus par contre).
30/03/2016, 15h41
J@ckHerror

Bonjour Kropernic,

Personnellement, et comme dit plus haut, tous mes champs sont not null, et si j'ai un null c'est qu'une jointure (left outer) a échouée.
Cela restant assez rare toutefois.

J@ck.
30/03/2016, 15h49
Kropernic

Citation:

Envoyé par J@ckHerror

Bonjour Kropernic,

Personnellement, et comme dit plus haut, tous mes champs sont not null, et si j'ai un null c'est qu'une jointure (left outer) a échouée.
Cela restant assez rare toutefois.

J@ck.

Oui oui j'ai bien compris. Et le fait que toutes tes colonnes (en DB, ce ne sont pas des champs mais des lignes et des colonnes) soient NOT NULL est un bon signe quant à la normalisation que tu appliques à tes DB.
Après, bien sûr qu'une jointure externe (que soit LEFT OUTER JOIN, RIGHT OUTER JOIN ou FULL OUTER JOIN) peut apporter des marqueurs NULL dans un résultat. Heureusement d'ailleurs. Mais ça n'empêche que personnellement, plutôt que de me faire ch*** avec .NET (d'ailleurs, dans un dataset, dès qu'il y a un NULL, ça gueule rien que lorsqu'on essaie de le remplir), je travaille à la source où ça va très vite puisqu'il suffit d'un coalesce avec toute la brochette de paramètres qu'on aurait envie de lui mettre.

Bien sûr, c'est une convention qui m'est propre et que je fais appliquer où je bosse (en même temps, on est deux et c'est moi le chef pour les DB, ça aide^^). Ca simplifie directement les choses au niveau .NET. On affiche et c'est tout. Si c'est null. Bin on a directement le bon affichage.
30/03/2016, 16h15
J@ckHerror

Ok et merci pour les infos.

Pour être franc je n'ai jamais utilisé coalesce, mais je vais le tester. Il est vrai que ces derniers temps (années :roll:) j'étais plus attentif à .net pour augmenter mon niveau et j'avais un peu délaissé la partie DB. Maintenant que je suis seul pour tout faire, je me rend compte que la partie DB peux aider pas mal, mes premières fonctions et procédures sont toutes récentes par exemple et là vous venez de me donner un nouvel axe de progression, et pour ça :merci:

J@ck.
30/03/2016, 16h54
DotNetMatt

Citation:

Envoyé par Kropernic

plutôt que de me faire ch*** avec .NET (d'ailleurs, dans un dataset, dès qu'il y a un NULL, ça gueule rien que lorsqu'on essaie de le remplir), je travaille à la source où ça va très vite puisqu'il suffit d'un coalesce avec toute la brochette de paramètres qu'on aurait envie de lui mettre.

Bien sûr, c'est une convention qui m'est propre et que je fais appliquer où je bosse (en même temps, on est deux et c'est moi le chef pour les DB, ça aide^^). Ca simplifie directement les choses au niveau .NET. On affiche et c'est tout. Si c'est null. Bin on a directement le bon affichage.

C'est bizarre car au final ca n'est pas bien sorcier... Il faut juste se rappeler que null en C# et null en SQL sont 2 choses différentes (sans parler de "" qui est encore autre chose).

Quand tu dis "on a directement le bon affichage", c'est probablement vrai dans la majorité des cas, mais il y a des moments où on pourrait vouloir traiter le null dans le code et là avec ta méthode ca ne fonctionnera pas car on ne pourra différencier entre null et "". Par exemple on peut avoir un truc du genre "si null, alors je récupère tel enregistrement pour afficher telle info".

Enfin, quand tu dis que le dataset gueule quand il y a des null, c'est une bonne raison de plus pour s'en passer ! Le dataset fait partie de la préhistoire de .NET et était surtout utile pour combler l'absence des listes (ou plus généralements des objets qui implémentent IEnumerable et autre). Rien de tel que des listes et si on a pas le temps de se palucher une DAL, Entity Framework (ou tout autre ORM) permet d'automatiser bien des choses sans avoir toute la lourdeur du DataSet...
31/03/2016, 09h17
Kropernic

Citation:

Envoyé par DotNetMatt

C'est bizarre car au final ca n'est pas bien sorcier... Il faut juste se rappeler que null en C# et null en SQL sont 2 choses différentes (sans parler de "" qui est encore autre chose).

Quand tu dis "on a directement le bon affichage", c'est probablement vrai dans la majorité des cas, mais il y a des moments où on pourrait vouloir traiter le null dans le code et là avec ta méthode ca ne fonctionnera pas car on ne pourra différencier entre null et "". Par exemple on peut avoir un truc du genre "si null, alors je récupère tel enregistrement pour afficher telle info".

Enfin, quand tu dis que le dataset gueule quand il y a des null, c'est une bonne raison de plus pour s'en passer ! Le dataset fait partie de la préhistoire de .NET et était surtout utile pour combler l'absence des listes (ou plus généralements des objets qui implémentent IEnumerable et autre). Rien de tel que des listes et si on a pas le temps de se palucher une DAL, Entity Framework (ou tout autre ORM) permet d'automatiser bien des choses sans avoir toute la lourdeur du DataSet...

Oh mais je n'utilise pas les datasets, bien au contraire. Même si cela me prend un rien plus de temps, j'écris toujours ma DAL moi-même. Comme ça, je suis sûr que les choses sont bien faites et en cas de bug, je n'ai pas à m'interroger si oui ou non il pourrait survenir dans un brique que je n'ai pas construite et sur laquelle je n'ai pas la main.

Sinon, concernent "on a directement le bon affichage", tu as tout à fait raison quand tu dis que, parfois, on ne voudra pas une chaîne vide à la place du NULL. Personnellement, je gère tous les accès DB via des procédures stockées (et les users n'ont accès qu'à ces dernières). Du coup, en cas dans NULL dans une requête, je peux gérer au cas par cas ce que je veux afficher. Mais faut bien dire que j'ai assez rarement des NULL dans mes requêtes.
31/03/2016, 13h42
sinople

Hello

Si l'instruction Iif() évalue effectivement les 3 arguments, ce qui la rend peu pratique pour ce genre de cas. L'instruction If() n'évalue que la condition nécessaire.

Il suffit donc d'enlever un i à ton iif() pour que ça fonctionne correctement (faut juste pas s'emmêler les pinceaux avec les deux instructions). Au passage ceci s'avéra aussi fort pratique pour vérifier qu'un objet ne soit pas Nothing avant d'accéder à une de ces propriétés.

Quand à l'utilisation d'un COALESCE dans la requête pour ne pas avoir de NULL, c'est acceptable dans certains cas (typiquement pour du reporting ou autre opération à sens unique). Mais c'est inacceptable pour du traitement de donnée vu qu'une absence de valeur n'est pas égale à un champ vide.

Pour la petite histoire, l'article suivant aurait pu se nommer. Madame Null est devenue une expert mondial d'audit de qualité de programmation sans faire d'étude (j'ose pas imaginer son cousin germain Mr. Drop table).
http://www.20min.ch/ro/multimedia/st...story/25432909
31/03/2016, 15h06
Kropernic

Outre le côté cocasse de l'histoire qui m'a fait rire, ça démontre juste que ceux qui ont codés les applications en question ont codé ça avec les pieds.

Car pour moi (mais je suis sûr que pour toi aussi), la chaîne "NULL" est strictement différent du marqueur NULL et ne peuvent pas se confondre.

Je programme des applications de gestion interne pour la boite où je bosse tous les jours et je n'ai jamais utilisé une seule requête qui renvoie un marqueur NULL dans son résultat. Pourtant, tout va très bien (madame la marquise).

De plus, j'ai dit que je ne renvoie jamais de marqueur NULL dans un résultat mais je n'ai jamais dit que je n'en passais pas à mes procédures stockées au besoin.

Bref, attention à ne pas tout mélanger (comme les programmes de l’article).
31/03/2016, 16h20
sinople

Sauf que quand tu mets un COALESCE dans ta requête, tu remplaces les NULL par une valeur (-1,0,"","null","n.a", je sais pas quoi).

Quand tu remontes l'enregistrement pour un update, il devient impossible de savoir si la valeur de remplacement doit représenter un NULL ou la valeur de substitution (et c'est bien ce qui a l'air d'arriver dans l'article cité.). Sauf si bien sur tu as un champ supplémentaire boolean (HasValue) stockant cette information d'absence de donnée sur un autre champ (ou que ça soit écrit dans le marbre que cette valeur ne fasse pas partie l'ensemble de travail), mais là on rentre dans un autre débat.

Dans certains cas, il est plus intéressant de ne pas accepter de NULL sur le champ dans la BD et de mettre une valeur par défaut (chaîne vide sur un text), surtout sur les champs valeur (pas les clés étrangères) qui sont optionnels.

Enfin on rencontre la même problématique avec les variable d'objet en référence (le fameux Nothing), la preuve avec Entity Framework ont ne travaille plus avec des DBNull mais des nothing. Donc savoir comment gérer ça correctement (pas avec le Iif()) me semble être essentiel.