je ne crois pas que c'etait l'objet de la question...
si le champ est un int, on fait
int valeur = (int)MyDataRow["aField"] ;
toute autre forme de conversion est un masque qui dissimule les erreurs. enfin bon, ce que j'en dis...
Faust
/_Ambassadeur Kosh_ avait prétendu/ :
je ne crois pas que c'etait l'objet de la question...
bien heureux celui qui était capable de comprendre l'objet réel de la question ;) je ne faisais que faire resortir le fait qu'il pouvait demander une méthode générique permettant de convertir un champ en string
si le champ est un int, on fait
int valeur = (int)MyDataRow["aField"] ;
toute autre forme de conversion est un masque qui dissimule les erreurs. enfin bon, ce que j'en dis...
hum, personnelement, je prefère largement un Convert.ToInt(MyDataRow["aField"]);
parce que le transtypage brutal c'est un peu... brutal: mydatarow renvoit des object... il faut donc s'assurer que aField est bien un Integer si la structure du champ change ou si, dans un prochain framework, mydatarow renvoit un objet autre qu'un integer (un IntegerField par exemple) on est obligé réécrire tout le code
amha
-- Mephitiquement votre, Faust ICQ #161252577
/_Ambassadeur Kosh_ avait prétendu/ :
je ne crois pas que c'etait l'objet de la question...
bien heureux celui qui était capable de comprendre l'objet réel de la
question ;)
je ne faisais que faire resortir le fait qu'il pouvait demander une
méthode générique permettant de convertir un champ en string
si le champ est un int, on fait
int valeur = (int)MyDataRow["aField"] ;
toute autre forme de conversion est un masque qui dissimule les erreurs.
enfin bon, ce que j'en dis...
hum, personnelement, je prefère largement un
Convert.ToInt(MyDataRow["aField"]);
parce que le transtypage brutal c'est un peu... brutal: mydatarow
renvoit des object... il faut donc s'assurer que aField est bien un
Integer
si la structure du champ change ou si, dans un prochain framework,
mydatarow renvoit un objet autre qu'un integer (un IntegerField par
exemple) on est obligé réécrire tout le code
je ne crois pas que c'etait l'objet de la question...
bien heureux celui qui était capable de comprendre l'objet réel de la question ;) je ne faisais que faire resortir le fait qu'il pouvait demander une méthode générique permettant de convertir un champ en string
si le champ est un int, on fait
int valeur = (int)MyDataRow["aField"] ;
toute autre forme de conversion est un masque qui dissimule les erreurs. enfin bon, ce que j'en dis...
hum, personnelement, je prefère largement un Convert.ToInt(MyDataRow["aField"]);
parce que le transtypage brutal c'est un peu... brutal: mydatarow renvoit des object... il faut donc s'assurer que aField est bien un Integer si la structure du champ change ou si, dans un prochain framework, mydatarow renvoit un objet autre qu'un integer (un IntegerField par exemple) on est obligé réécrire tout le code
amha
-- Mephitiquement votre, Faust ICQ #161252577
Ambassadeur Kosh
> bien heureux celui qui était capable de comprendre l'objet réel de la question ;)
à le relire, sans a priori, c'est pas évident, mais quand on connait les habitudes de beaucoup...
hum, personnelement, je prefère largement un Convert.ToInt(MyDataRow["aField"]);
oui, et toute la question est "à quoi sert Convert".
parce que le transtypage brutal c'est un peu... brutal: mydatarow renvoit des object... il faut donc s'assurer que aField est bien un Integer
et c'est la tout l'interet du typage.
si la structure du champ change ou si, dans un prochain framework, mydatarow renvoit un objet autre qu'un integer (un IntegerField par exemple) on est obligé réécrire tout le code
sauf si cette portion de code est dans un DataReader typé au meme titre qu'un Dataset typé... ce qu'on a fortement interet à faire.
il est interessant d'avoir le comportement "soit Int, soit Excetpion". Convert est une passoire à erreurs de typage... un decimal par exemple sera arrondi à l'entier inferieur. c'est forcément souhaitable comme comportement...
> bien heureux celui qui était capable de comprendre l'objet réel de la
question ;)
à le relire, sans a priori, c'est pas évident, mais quand on connait les
habitudes de beaucoup...
hum, personnelement, je prefère largement un
Convert.ToInt(MyDataRow["aField"]);
oui, et toute la question est "à quoi sert Convert".
parce que le transtypage brutal c'est un peu... brutal: mydatarow renvoit
des object... il faut donc s'assurer que aField est bien un Integer
et c'est la tout l'interet du typage.
si la structure du champ change ou si, dans un prochain framework,
mydatarow renvoit un objet autre qu'un integer (un IntegerField par
exemple) on est obligé réécrire tout le code
sauf si cette portion de code est dans un DataReader typé au meme titre
qu'un Dataset typé...
ce qu'on a fortement interet à faire.
il est interessant d'avoir le comportement "soit Int, soit Excetpion".
Convert est une passoire à erreurs de typage... un decimal par exemple sera
arrondi à l'entier inferieur. c'est forcément souhaitable comme
comportement...
> bien heureux celui qui était capable de comprendre l'objet réel de la question ;)
à le relire, sans a priori, c'est pas évident, mais quand on connait les habitudes de beaucoup...
hum, personnelement, je prefère largement un Convert.ToInt(MyDataRow["aField"]);
oui, et toute la question est "à quoi sert Convert".
parce que le transtypage brutal c'est un peu... brutal: mydatarow renvoit des object... il faut donc s'assurer que aField est bien un Integer
et c'est la tout l'interet du typage.
si la structure du champ change ou si, dans un prochain framework, mydatarow renvoit un objet autre qu'un integer (un IntegerField par exemple) on est obligé réécrire tout le code
sauf si cette portion de code est dans un DataReader typé au meme titre qu'un Dataset typé... ce qu'on a fortement interet à faire.
il est interessant d'avoir le comportement "soit Int, soit Excetpion". Convert est une passoire à erreurs de typage... un decimal par exemple sera arrondi à l'entier inferieur. c'est forcément souhaitable comme comportement...
Faust
> il est interessant d'avoir le comportement "soit Int, soit Excetpion". Convert est une passoire à erreurs de typage... un decimal par exemple sera arrondi à l'entier inferieur. c'est forcément souhaitable comme comportement...
ben en milieu professionnel, je préfère entendre mes clients dire "votre programme fait une erreur de calcul" (sous entendu, ça peut être une mauvaise formule qui est utilisée) que "votre programme marche pas" ;)
-- Mephitiquement votre, Faust ICQ #161252577
> il est interessant d'avoir le comportement "soit Int, soit Excetpion".
Convert est une passoire à erreurs de typage... un decimal par exemple sera
arrondi à l'entier inferieur. c'est forcément souhaitable comme
comportement...
ben en milieu professionnel, je préfère entendre mes clients dire
"votre programme fait une erreur de calcul" (sous entendu, ça peut être
une mauvaise formule qui est utilisée) que "votre programme marche pas"
;)
> il est interessant d'avoir le comportement "soit Int, soit Excetpion". Convert est une passoire à erreurs de typage... un decimal par exemple sera arrondi à l'entier inferieur. c'est forcément souhaitable comme comportement...
ben en milieu professionnel, je préfère entendre mes clients dire "votre programme fait une erreur de calcul" (sous entendu, ça peut être une mauvaise formule qui est utilisée) que "votre programme marche pas" ;)
-- Mephitiquement votre, Faust ICQ #161252577
Ambassadeur Kosh
> ben en milieu professionnel, je préfère entendre mes clients dire "votre programme fait une erreur de calcul" (sous entendu, ça peut être une mauvaise formule qui est utilisée) que "votre programme marche pas" ;)
ça dépend. en compta, je connais des specialistes de ce genre d'approches, et ça a conduit 2 fois en 3 ans au million de francs suisse de redressement pour un meme client. sur une chaine de production, une machine s'est mis à bazarder 20% de la matiere premiere. pour Ariane 5 aussi, on a pu dire que c'etait une legere erreur de calcul.
de toute façon, avec un DataReader typé ou un DataSet typé, la question ne se pose pas...
> ben en milieu professionnel, je préfère entendre mes clients dire "votre
programme fait une erreur de calcul" (sous entendu, ça peut être une
mauvaise formule qui est utilisée) que "votre programme marche pas" ;)
ça dépend. en compta, je connais des specialistes de ce genre d'approches,
et ça a conduit 2 fois en 3 ans au million de francs suisse de redressement
pour un meme client. sur une chaine de production, une machine s'est mis à
bazarder 20% de la matiere premiere. pour Ariane 5 aussi, on a pu dire que
c'etait une legere erreur de calcul.
de toute façon, avec un DataReader typé ou un DataSet typé, la question ne
se pose pas...
> ben en milieu professionnel, je préfère entendre mes clients dire "votre programme fait une erreur de calcul" (sous entendu, ça peut être une mauvaise formule qui est utilisée) que "votre programme marche pas" ;)
ça dépend. en compta, je connais des specialistes de ce genre d'approches, et ça a conduit 2 fois en 3 ans au million de francs suisse de redressement pour un meme client. sur une chaine de production, une machine s'est mis à bazarder 20% de la matiere premiere. pour Ariane 5 aussi, on a pu dire que c'etait une legere erreur de calcul.
de toute façon, avec un DataReader typé ou un DataSet typé, la question ne se pose pas...
Faust
/_Ambassadeur Kosh_ avait prétendu/ :
ben en milieu professionnel, je préfère entendre mes clients dire "votre programme fait une erreur de calcul" (sous entendu, ça peut être une mauvaise formule qui est utilisée) que "votre programme marche pas" ;)
ça dépend. en compta, je connais des specialistes de ce genre d'approches, et ça a conduit 2 fois en 3 ans au million de francs suisse de redressement pour un meme client. sur une chaine de production, une machine s'est mis à bazarder 20% de la matiere premiere. pour Ariane 5 aussi, on a pu dire que c'etait une legere erreur de calcul.
certes, pour nous une exception est plus génante qu'une erreur de calcul
de toute façon, avec un DataReader typé ou un DataSet typé, la question ne se pose pas...
hum, plus ou moins... pour typer ton datareader ou dataset, faut encore une fois que tu connaisse ton type: tu transtype la lecture du champ... peu importe où ça se fait
-- Mephitiquement votre, Faust ICQ #161252577
/_Ambassadeur Kosh_ avait prétendu/ :
ben en milieu professionnel, je préfère entendre mes clients dire "votre
programme fait une erreur de calcul" (sous entendu, ça peut être une
mauvaise formule qui est utilisée) que "votre programme marche pas" ;)
ça dépend. en compta, je connais des specialistes de ce genre d'approches, et
ça a conduit 2 fois en 3 ans au million de francs suisse de redressement pour
un meme client. sur une chaine de production, une machine s'est mis à
bazarder 20% de la matiere premiere. pour Ariane 5 aussi, on a pu dire que
c'etait une legere erreur de calcul.
certes, pour nous une exception est plus génante qu'une erreur de
calcul
de toute façon, avec un DataReader typé ou un DataSet typé, la question ne se
pose pas...
hum, plus ou moins... pour typer ton datareader ou dataset, faut encore
une fois que tu connaisse ton type: tu transtype la lecture du champ...
peu importe où ça se fait
ben en milieu professionnel, je préfère entendre mes clients dire "votre programme fait une erreur de calcul" (sous entendu, ça peut être une mauvaise formule qui est utilisée) que "votre programme marche pas" ;)
ça dépend. en compta, je connais des specialistes de ce genre d'approches, et ça a conduit 2 fois en 3 ans au million de francs suisse de redressement pour un meme client. sur une chaine de production, une machine s'est mis à bazarder 20% de la matiere premiere. pour Ariane 5 aussi, on a pu dire que c'etait une legere erreur de calcul.
certes, pour nous une exception est plus génante qu'une erreur de calcul
de toute façon, avec un DataReader typé ou un DataSet typé, la question ne se pose pas...
hum, plus ou moins... pour typer ton datareader ou dataset, faut encore une fois que tu connaisse ton type: tu transtype la lecture du champ... peu importe où ça se fait
