alors que AuthorUrl est bien evidement typé en string et que le champ AuthorUrl est vide dans ma bdd.
J'aimerais connaitre votre facon de faire pour éviter ce genre d'erreur, quelle est la solution la plus simple d'apres vous car j'ai pas envie de me lancer dans un gestion d'erreur compliqué alors qu'il existe peut etre une astuce :)
SharpMao
Messages postés1024Date d'inscriptionmardi 4 février 2003StatutMembreDernière intervention 7 juin 201069 24 nov. 2004 à 09:34
Au lie de travailler avec des exception, tu peut vérifier avant d'affecter
if(myReader.Item("AuthorUrl")) != DBNull.Value)
_ArticleInfo.AuthorUrl = @(myReader.Item("AuthorUrl"));
Amicalement, SharpMao
jesusonline
Messages postés6814Date d'inscriptiondimanche 15 décembre 2002StatutMembreDernière intervention13 octobre 201029 24 nov. 2004 à 01:39
ok merci, c'est surement une solution que j'aurais adopté, mais je voulais etre sur qu'il n'existe pas une astuce caché dans le fin fond du framework ;)
jesusonline
Messages postés6814Date d'inscriptiondimanche 15 décembre 2002StatutMembreDernière intervention13 octobre 201029 24 nov. 2004 à 13:20
oula, un petit bug de CS :big)
Je recommence :
La méthode de SharpMao fonctionne aussi, il faut remplacer le = par un is :)
Je prefere cette méthode que l'utilisation d'un try/ catch, je trouve que ca fait "rustine".
j'ai malgré tout une question, avec cette méthode, on fait appel deux fois au datareader, une fois pour vérifier qu'il ne soit pas nul, une autre fois pour assigner la valeur.
Je me souviens plus si le datareader travaille comme un dataset, en mode déconnecté, si oui la question ne se pose pas, sinon, on a deux appel à la source de données, ce qui entraine une perte de temps, et puis si on a pas de chance, la valeur dans la bdd change entre les deux lignes (oui faut vraiment pas etre chanceux) ca va bugger, dans ce cas il faut mieux utiliser le try ? qu'en pensez vous ?