Bonjour
un gros bruit désolé, mais peut être que je passe à côté de qq chose
qui me ferait gagner du temps depuis plusieurs années.
Je travaille énormément dans mon mes métiers avec des resultats donnés
sous format Excel par les clients.
Mais expliquer à un client qu'un bête format de zone ne modifie que la
présentation du chiffre pas sa vraie valeur intrinsèque relève d'une de
mes nombreuses illusions perdues.
Par exemple, un chiffre transmis sous l'apparence 84,33% est en réalité
0.8433333333333, ou un chiffre sous l'apparence 4,2 est en fait
4.222247.
On connait tous ça bien sûr. Et donc je retravaille avant traîtement la
colonne avec un arrondi(f2*100;2) formule que je recopie partout, puis
Copier et collage Spéciale Valeur pour enlever la formule, puis
suppression de la colonne d'origine.
Ensuite c'est intégré par des programmes utilitaires d'interface avec
Excel. Ces programmes sont génériques, raison pour laquelle je ne fais
pas les conversions dans ces programmes. (ça je le fais pour des integ
spécifiques)
Tout ça, c'est sans arrêt, c'est mon lot quotidien.
Encore heureux (ça arrive) qu'il ne me donne pas dans la mème colonne
des chiffres formatés et des chiffres avec le % saisi après !
Donc ma question est très très simple :
Y'a-t-il une manip dans excel qui convertirait les formats en données
réelles pour toute la feuille ?
et d'avoir "CE QUE VOUS VOYEZ EST CE QUE VOUS ALLEZ INTEGRER !"
Merci de vos réponses.
NB : en relisant mon message, je me dis que mon besoin est tellement
élémentaire que je ne comprends pas que cela n'existe pas. Je viens de
revisiter les options du collage spécial... sans succès.
--
Eric Roumégou
Webmaster des wtablettes
http://cerbermail.com/?qE7t4Qvilo
(cliquez sur le lien ci-dessus pour me contacter en privé)
J'ignore si cela peut convenir ou si la procédure vous parait trop longue mais :
Création d'un fichier CSV. Copier coller de la feuille Excel dans le csv.
Sauvegarde etc.
Les informations enregistrées sont celles formatées, et toutes les virgules flottantes disparaissent, exploitation du csv ou on le re-enregistre en .xls.
oui ce que tu dis est vrai. Bravo ! C'est vrai que la manip est un peu lourde mais faudrait essayer de pilôter cela en OLE en WD.
-- Eric Roumégou Webmaster des wtablettes http://cerbermail.com/?qE7t4Qvilo (cliquez sur le lien ci-dessus pour me contacter en privé)
Le 21/05/2008, Bruno Wrk a supposé :
J'ignore si cela peut convenir ou si la procédure vous parait trop longue
mais :
Création d'un fichier CSV.
Copier coller de la feuille Excel dans le csv.
Sauvegarde etc.
Les informations enregistrées sont celles formatées, et toutes les virgules
flottantes disparaissent, exploitation du csv ou on le re-enregistre en .xls.
oui ce que tu dis est vrai. Bravo !
C'est vrai que la manip est un peu lourde mais faudrait essayer de
pilôter cela en OLE en WD.
--
Eric Roumégou
Webmaster des wtablettes
http://cerbermail.com/?qE7t4Qvilo
(cliquez sur le lien ci-dessus pour me contacter en privé)
J'ignore si cela peut convenir ou si la procédure vous parait trop longue mais :
Création d'un fichier CSV. Copier coller de la feuille Excel dans le csv.
Sauvegarde etc.
Les informations enregistrées sont celles formatées, et toutes les virgules flottantes disparaissent, exploitation du csv ou on le re-enregistre en .xls.
oui ce que tu dis est vrai. Bravo ! C'est vrai que la manip est un peu lourde mais faudrait essayer de pilôter cela en OLE en WD.
-- Eric Roumégou Webmaster des wtablettes http://cerbermail.com/?qE7t4Qvilo (cliquez sur le lien ci-dessus pour me contacter en privé)
Roumegou Eric
Après mûre réflexion, Firetox a écrit :
je veux intégrer ce qu'a formaté le client.
pour lui 83.33% c'est 83.33 et pas 0.83333333
oui mais ca pose un probleme mathematique. 83,33% en math c'est 0,8333 si ton client dit non alors demande lui de faire une calcul avec il devrait te reponde maValeur * 83,33 /100 et c'et la qu'il ne voit pas 83,33/100 = 0,8333 dons la valeur intrinsecte de 83,33% est bien 0,8333
n'ais-je pas dit que cela faisait partie de mes illusions perdues ? :'(
maintenant faut se poser la question que va devenir la valeur si elle doit servir a faire des calcul il faut stocker 0,8333 car sinon il faudra que tu sache qu'il faut diviser par 100 alors qu'avec cette valeur ce n'est pas necessaire
La valeur je ne sais pas à quoi elle va servir; cela peut être différent à chaque fois. Elle rentre dans des zones formatées de ma base résultat (15,5) ensuite je la traiterai avec ces deux décimales donc 83,33 sera stocké certainement 83.33000 dans ma base. Bien sûr c'est en fn du traitement et je n'oublierais pas que c'est un %. Pour la restitution du chiffre, j'ai défini aussi pour chaque zone le nbre de décimales ds une table paramètre. Si bien que mes requetes font déjà le round() adéquat.
bref soit tu passe tout en texte et a ce moment la tu as bien 83,33 mais ne sera pas utilisable en tant que pourcentage sans avoir quelque part la notion que dans un calcul avec cette valeur il faudra / 100
sinon il faut exepliquer au client ce qu'est 83,33 % ce n'ai pas 83,33 mais bien 0,8333
oui on peux leur expliquer ;o) Mais je vous jure que pour le commun des utilisateurs Excel, ce qu'il voit à l'écran est LE chiffre. Et s'il l'a présenté comme cela , c'est qu'il veux qu'on le traite comme cela.
Bon dev @+
-- Eric Roumégou Webmaster des wtablettes http://cerbermail.com/?qE7t4Qvilo (cliquez sur le lien ci-dessus pour me contacter en privé)
Après mûre réflexion, Firetox a écrit :
je veux intégrer ce qu'a formaté le client.
pour lui 83.33% c'est 83.33 et pas 0.83333333
oui mais ca pose un probleme mathematique. 83,33% en math c'est 0,8333 si ton
client dit non alors demande lui de faire une calcul avec il devrait te
reponde maValeur * 83,33 /100 et c'et la qu'il ne voit pas 83,33/100 = 0,8333
dons la valeur intrinsecte de 83,33% est bien 0,8333
n'ais-je pas dit que cela faisait partie de mes illusions perdues ? :'(
maintenant faut se poser la question que va devenir la valeur
si elle doit servir a faire des calcul il faut stocker 0,8333 car sinon il
faudra que tu sache qu'il faut diviser par 100 alors qu'avec cette valeur ce
n'est pas necessaire
La valeur je ne sais pas à quoi elle va servir; cela peut être
différent à chaque fois. Elle rentre dans des zones formatées de ma
base résultat (15,5) ensuite je la traiterai avec ces deux décimales
donc 83,33 sera stocké certainement 83.33000 dans ma base. Bien sûr
c'est en fn du traitement et je n'oublierais pas que c'est un %.
Pour la restitution du chiffre, j'ai défini aussi pour chaque zone le
nbre de décimales ds une table paramètre. Si bien que mes requetes font
déjà le round() adéquat.
bref soit tu passe tout en texte et a ce moment la tu as bien 83,33 mais ne
sera pas utilisable en tant que pourcentage sans avoir quelque part la notion
que dans un calcul avec cette valeur il faudra / 100
sinon il faut exepliquer au client ce qu'est 83,33 % ce n'ai pas 83,33 mais
bien 0,8333
oui on peux leur expliquer ;o)
Mais je vous jure que pour le commun des utilisateurs Excel, ce qu'il
voit à l'écran est LE chiffre.
Et s'il l'a présenté comme cela , c'est qu'il veux qu'on le traite
comme cela.
Bon dev
@+
--
Eric Roumégou
Webmaster des wtablettes
http://cerbermail.com/?qE7t4Qvilo
(cliquez sur le lien ci-dessus pour me contacter en privé)
oui mais ca pose un probleme mathematique. 83,33% en math c'est 0,8333 si ton client dit non alors demande lui de faire une calcul avec il devrait te reponde maValeur * 83,33 /100 et c'et la qu'il ne voit pas 83,33/100 = 0,8333 dons la valeur intrinsecte de 83,33% est bien 0,8333
n'ais-je pas dit que cela faisait partie de mes illusions perdues ? :'(
maintenant faut se poser la question que va devenir la valeur si elle doit servir a faire des calcul il faut stocker 0,8333 car sinon il faudra que tu sache qu'il faut diviser par 100 alors qu'avec cette valeur ce n'est pas necessaire
La valeur je ne sais pas à quoi elle va servir; cela peut être différent à chaque fois. Elle rentre dans des zones formatées de ma base résultat (15,5) ensuite je la traiterai avec ces deux décimales donc 83,33 sera stocké certainement 83.33000 dans ma base. Bien sûr c'est en fn du traitement et je n'oublierais pas que c'est un %. Pour la restitution du chiffre, j'ai défini aussi pour chaque zone le nbre de décimales ds une table paramètre. Si bien que mes requetes font déjà le round() adéquat.
bref soit tu passe tout en texte et a ce moment la tu as bien 83,33 mais ne sera pas utilisable en tant que pourcentage sans avoir quelque part la notion que dans un calcul avec cette valeur il faudra / 100
sinon il faut exepliquer au client ce qu'est 83,33 % ce n'ai pas 83,33 mais bien 0,8333
oui on peux leur expliquer ;o) Mais je vous jure que pour le commun des utilisateurs Excel, ce qu'il voit à l'écran est LE chiffre. Et s'il l'a présenté comme cela , c'est qu'il veux qu'on le traite comme cela.
Bon dev @+
-- Eric Roumégou Webmaster des wtablettes http://cerbermail.com/?qE7t4Qvilo (cliquez sur le lien ci-dessus pour me contacter en privé)
Daniel
Roumegou Eric a écrit :
Après mûre réflexion, Firetox a écrit :
je veux intégrer ce qu'a formaté le client.
pour lui 83.33% c'est 83.33 et pas 0.83333333
oui mais ca pose un probleme mathematique. 83,33% en math c'est 0,8333 si ton client dit non alors demande lui de faire une calcul avec il devrait te reponde maValeur * 83,33 /100 et c'et la qu'il ne voit pas 83,33/100 = 0,8333 dons la valeur intrinsecte de 83,33% est bien 0,8333
n'ais-je pas dit que cela faisait partie de mes illusions perdues ? :'(
maintenant faut se poser la question que va devenir la valeur si elle doit servir a faire des calcul il faut stocker 0,8333 car sinon il faudra que tu sache qu'il faut diviser par 100 alors qu'avec cette valeur ce n'est pas necessaire
La valeur je ne sais pas à quoi elle va servir; cela peut être différent à chaque fois. Elle rentre dans des zones formatées de ma base résultat (15,5) ensuite je la traiterai avec ces deux décimales donc 83,33 sera stocké certainement 83.33000 dans ma base. Bien sûr c'est en fn du traitement et je n'oublierais pas que c'est un %. Pour la restitution du chiffre, j'ai défini aussi pour chaque zone le nbre de décimales ds une table paramètre. Si bien que mes requetes font déjà le round() adéquat.
bref soit tu passe tout en texte et a ce moment la tu as bien 83,33 mais ne sera pas utilisable en tant que pourcentage sans avoir quelque part la notion que dans un calcul avec cette valeur il faudra / 100
sinon il faut exepliquer au client ce qu'est 83,33 % ce n'ai pas 83,33 mais bien 0,8333
oui on peux leur expliquer ;o) Mais je vous jure que pour le commun des utilisateurs Excel, ce qu'il voit à l'écran est LE chiffre. Et s'il l'a présenté comme cela , c'est qu'il veux qu'on le traite comme cela.
Bon dev @+
Une base de données est faite pour stocker des données. Dans ton cas tu dois stocker 0,833333333 et ensuite appliquer un masque %. Mieux ce pourcentage est peut peut être un simple calcul d'une colonne avec une autre colonne, dans ce cas on ne prend pas le %, mais on le recalcule au moment souhaité (dans la base ou à l'affichage).
Concernant l'utilisateur final sa remarque est judicieuse, et est du même type Msieur je veux mes valeurs négatives en rouge. Imagine si on stockait les heures/dates en fonction du format souhaité par l'utilisateur final, il faudrait faire du code spécifique à tous les niveaux.
Dans ton cas je ferais au moment de l'import un dictionnaire qui permet en fonction du nom de la colonne de définir un masque. Ce masque servirait pour la présentation des données.
@+ -- suivre ce lien pour répondre: http://cerbermail.com/?2KrV3YZXnn Daniel ;-)
Roumegou Eric a écrit :
Après mûre réflexion, Firetox a écrit :
je veux intégrer ce qu'a formaté le client.
pour lui 83.33% c'est 83.33 et pas 0.83333333
oui mais ca pose un probleme mathematique. 83,33% en math c'est 0,8333
si ton client dit non alors demande lui de faire une calcul avec il
devrait te reponde maValeur * 83,33 /100 et c'et la qu'il ne voit pas
83,33/100 = 0,8333 dons la valeur intrinsecte de 83,33% est bien 0,8333
n'ais-je pas dit que cela faisait partie de mes illusions perdues ? :'(
maintenant faut se poser la question que va devenir la valeur
si elle doit servir a faire des calcul il faut stocker 0,8333 car
sinon il faudra que tu sache qu'il faut diviser par 100 alors qu'avec
cette valeur ce n'est pas necessaire
La valeur je ne sais pas à quoi elle va servir; cela peut être différent
à chaque fois. Elle rentre dans des zones formatées de ma base résultat
(15,5) ensuite je la traiterai avec ces deux décimales donc 83,33 sera
stocké certainement 83.33000 dans ma base. Bien sûr c'est en fn du
traitement et je n'oublierais pas que c'est un %.
Pour la restitution du chiffre, j'ai défini aussi pour chaque zone le
nbre de décimales ds une table paramètre. Si bien que mes requetes font
déjà le round() adéquat.
bref soit tu passe tout en texte et a ce moment la tu as bien 83,33
mais ne sera pas utilisable en tant que pourcentage sans avoir quelque
part la notion que dans un calcul avec cette valeur il faudra / 100
sinon il faut exepliquer au client ce qu'est 83,33 % ce n'ai pas 83,33
mais bien 0,8333
oui on peux leur expliquer ;o)
Mais je vous jure que pour le commun des utilisateurs Excel, ce qu'il
voit à l'écran est LE chiffre.
Et s'il l'a présenté comme cela , c'est qu'il veux qu'on le traite comme
cela.
Bon dev
@+
Une base de données est faite pour stocker des données.
Dans ton cas tu dois stocker 0,833333333 et ensuite appliquer un masque
%. Mieux ce pourcentage est peut peut être un simple calcul d'une
colonne avec une autre colonne, dans ce cas on ne prend pas le %, mais
on le recalcule au moment souhaité (dans la base ou à l'affichage).
Concernant l'utilisateur final sa remarque est judicieuse, et est du
même type Msieur je veux mes valeurs négatives en rouge.
Imagine si on stockait les heures/dates en fonction du format souhaité
par l'utilisateur final, il faudrait faire du code spécifique à tous les
niveaux.
Dans ton cas je ferais au moment de l'import un dictionnaire qui permet
en fonction du nom de la colonne de définir un masque. Ce masque
servirait pour la présentation des données.
@+
--
suivre ce lien pour répondre:
http://cerbermail.com/?2KrV3YZXnn
Daniel
;-)
oui mais ca pose un probleme mathematique. 83,33% en math c'est 0,8333 si ton client dit non alors demande lui de faire une calcul avec il devrait te reponde maValeur * 83,33 /100 et c'et la qu'il ne voit pas 83,33/100 = 0,8333 dons la valeur intrinsecte de 83,33% est bien 0,8333
n'ais-je pas dit que cela faisait partie de mes illusions perdues ? :'(
maintenant faut se poser la question que va devenir la valeur si elle doit servir a faire des calcul il faut stocker 0,8333 car sinon il faudra que tu sache qu'il faut diviser par 100 alors qu'avec cette valeur ce n'est pas necessaire
La valeur je ne sais pas à quoi elle va servir; cela peut être différent à chaque fois. Elle rentre dans des zones formatées de ma base résultat (15,5) ensuite je la traiterai avec ces deux décimales donc 83,33 sera stocké certainement 83.33000 dans ma base. Bien sûr c'est en fn du traitement et je n'oublierais pas que c'est un %. Pour la restitution du chiffre, j'ai défini aussi pour chaque zone le nbre de décimales ds une table paramètre. Si bien que mes requetes font déjà le round() adéquat.
bref soit tu passe tout en texte et a ce moment la tu as bien 83,33 mais ne sera pas utilisable en tant que pourcentage sans avoir quelque part la notion que dans un calcul avec cette valeur il faudra / 100
sinon il faut exepliquer au client ce qu'est 83,33 % ce n'ai pas 83,33 mais bien 0,8333
oui on peux leur expliquer ;o) Mais je vous jure que pour le commun des utilisateurs Excel, ce qu'il voit à l'écran est LE chiffre. Et s'il l'a présenté comme cela , c'est qu'il veux qu'on le traite comme cela.
Bon dev @+
Une base de données est faite pour stocker des données. Dans ton cas tu dois stocker 0,833333333 et ensuite appliquer un masque %. Mieux ce pourcentage est peut peut être un simple calcul d'une colonne avec une autre colonne, dans ce cas on ne prend pas le %, mais on le recalcule au moment souhaité (dans la base ou à l'affichage).
Concernant l'utilisateur final sa remarque est judicieuse, et est du même type Msieur je veux mes valeurs négatives en rouge. Imagine si on stockait les heures/dates en fonction du format souhaité par l'utilisateur final, il faudrait faire du code spécifique à tous les niveaux.
Dans ton cas je ferais au moment de l'import un dictionnaire qui permet en fonction du nom de la colonne de définir un masque. Ce masque servirait pour la présentation des données.
@+ -- suivre ce lien pour répondre: http://cerbermail.com/?2KrV3YZXnn Daniel ;-)
Roumegou Eric
Daniel avait soumis l'idée :
Roumegou Eric a écrit :
Après mûre réflexion, Firetox a écrit :
je veux intégrer ce qu'a formaté le client.
pour lui 83.33% c'est 83.33 et pas 0.83333333
oui mais ca pose un probleme mathematique. 83,33% en math c'est 0,8333 si ton client dit non alors demande lui de faire une calcul avec il devrait te reponde maValeur * 83,33 /100 et c'et la qu'il ne voit pas 83,33/100 = 0,8333 dons la valeur intrinsecte de 83,33% est bien 0,8333
n'ais-je pas dit que cela faisait partie de mes illusions perdues ? :'(
maintenant faut se poser la question que va devenir la valeur si elle doit servir a faire des calcul il faut stocker 0,8333 car sinon il faudra que tu sache qu'il faut diviser par 100 alors qu'avec cette valeur ce n'est pas necessaire
La valeur je ne sais pas à quoi elle va servir; cela peut être différent à chaque fois. Elle rentre dans des zones formatées de ma base résultat (15,5) ensuite je la traiterai avec ces deux décimales donc 83,33 sera stocké certainement 83.33000 dans ma base. Bien sûr c'est en fn du traitement et je n'oublierais pas que c'est un %. Pour la restitution du chiffre, j'ai défini aussi pour chaque zone le nbre de décimales ds une table paramètre. Si bien que mes requetes font déjà le round() adéquat.
bref soit tu passe tout en texte et a ce moment la tu as bien 83,33 mais ne sera pas utilisable en tant que pourcentage sans avoir quelque part la notion que dans un calcul avec cette valeur il faudra / 100
sinon il faut exepliquer au client ce qu'est 83,33 % ce n'ai pas 83,33 mais bien 0,8333
oui on peux leur expliquer ;o) Mais je vous jure que pour le commun des utilisateurs Excel, ce qu'il voit à l'écran est LE chiffre. Et s'il l'a présenté comme cela , c'est qu'il veux qu'on le traite comme cela.
Bon dev @+
Une base de données est faite pour stocker des données.
Merci mais ma question n'était pas de savoir "qu'est ce qu'une base de donnée ?" 20 ans que je suis là dedans, je crois m'être fait une petite idée là dessus.
Dans ton cas tu dois stocker 0,833333333 et ensuite appliquer un masque %.
Non dans mon cas je dois stocker 83.33000 et travailler avec 83.33 Encore une fois ma question se limitait à Excel. Pour gérer les données de mes opérations en base, j'ai une réponse adaptée à mon métier et je ne vais pas créer une base spécifique et un programme spécifique à chaque fois que je reçois un fichier Excel.
Mieux ce pourcentage est peut peut être un simple calcul d'une colonne avec une autre colonne, dans ce cas on ne prend pas le %, mais on le recalcule au moment souhaité (dans la base ou à l'affichage).
Concernant l'utilisateur final sa remarque est judicieuse, et est du même type Msieur je veux mes valeurs négatives en rouge. Imagine si on stockait les heures/dates en fonction du format souhaité par l'utilisateur final, il faudrait faire du code spécifique à tous les niveaux.
Dans ton cas je ferais au moment de l'import un dictionnaire qui permet en fonction du nom de la colonne de définir un masque. Ce masque servirait pour la présentation des données.
@+
-- Eric Roumégou Webmaster des wtablettes http://cerbermail.com/?qE7t4Qvilo (cliquez sur le lien ci-dessus pour me contacter en privé)
Daniel avait soumis l'idée :
Roumegou Eric a écrit :
Après mûre réflexion, Firetox a écrit :
je veux intégrer ce qu'a formaté le client.
pour lui 83.33% c'est 83.33 et pas 0.83333333
oui mais ca pose un probleme mathematique. 83,33% en math c'est 0,8333 si
ton client dit non alors demande lui de faire une calcul avec il devrait
te reponde maValeur * 83,33 /100 et c'et la qu'il ne voit pas 83,33/100 =
0,8333 dons la valeur intrinsecte de 83,33% est bien 0,8333
n'ais-je pas dit que cela faisait partie de mes illusions perdues ? :'(
maintenant faut se poser la question que va devenir la valeur
si elle doit servir a faire des calcul il faut stocker 0,8333 car sinon il
faudra que tu sache qu'il faut diviser par 100 alors qu'avec cette valeur
ce n'est pas necessaire
La valeur je ne sais pas à quoi elle va servir; cela peut être différent à
chaque fois. Elle rentre dans des zones formatées de ma base résultat
(15,5) ensuite je la traiterai avec ces deux décimales donc 83,33 sera
stocké certainement 83.33000 dans ma base. Bien sûr c'est en fn du
traitement et je n'oublierais pas que c'est un %.
Pour la restitution du chiffre, j'ai défini aussi pour chaque zone le nbre
de décimales ds une table paramètre. Si bien que mes requetes font déjà le
round() adéquat.
bref soit tu passe tout en texte et a ce moment la tu as bien 83,33 mais
ne sera pas utilisable en tant que pourcentage sans avoir quelque part la
notion que dans un calcul avec cette valeur il faudra / 100
sinon il faut exepliquer au client ce qu'est 83,33 % ce n'ai pas 83,33
mais bien 0,8333
oui on peux leur expliquer ;o)
Mais je vous jure que pour le commun des utilisateurs Excel, ce qu'il voit
à l'écran est LE chiffre.
Et s'il l'a présenté comme cela , c'est qu'il veux qu'on le traite comme
cela.
Bon dev
@+
Une base de données est faite pour stocker des données.
Merci mais ma question n'était pas de savoir "qu'est ce qu'une base de
donnée ?"
20 ans que je suis là dedans, je crois m'être fait une petite idée là
dessus.
Dans ton cas tu dois stocker 0,833333333 et ensuite appliquer un masque %.
Non dans mon cas je dois stocker 83.33000 et travailler avec 83.33
Encore une fois ma question se limitait à Excel.
Pour gérer les données de mes opérations en base, j'ai une réponse
adaptée à mon métier et je ne vais pas créer une base spécifique et un
programme spécifique à chaque fois que je reçois un fichier Excel.
Mieux ce pourcentage est peut peut être un simple calcul d'une colonne avec
une autre colonne, dans ce cas on ne prend pas le %, mais on le recalcule au
moment souhaité (dans la base ou à l'affichage).
Concernant l'utilisateur final sa remarque est judicieuse, et est du même
type Msieur je veux mes valeurs négatives en rouge.
Imagine si on stockait les heures/dates en fonction du format souhaité par
l'utilisateur final, il faudrait faire du code spécifique à tous les niveaux.
Dans ton cas je ferais au moment de l'import un dictionnaire qui permet en
fonction du nom de la colonne de définir un masque. Ce masque servirait pour
la présentation des données.
@+
--
Eric Roumégou
Webmaster des wtablettes
http://cerbermail.com/?qE7t4Qvilo
(cliquez sur le lien ci-dessus pour me contacter en privé)
oui mais ca pose un probleme mathematique. 83,33% en math c'est 0,8333 si ton client dit non alors demande lui de faire une calcul avec il devrait te reponde maValeur * 83,33 /100 et c'et la qu'il ne voit pas 83,33/100 = 0,8333 dons la valeur intrinsecte de 83,33% est bien 0,8333
n'ais-je pas dit que cela faisait partie de mes illusions perdues ? :'(
maintenant faut se poser la question que va devenir la valeur si elle doit servir a faire des calcul il faut stocker 0,8333 car sinon il faudra que tu sache qu'il faut diviser par 100 alors qu'avec cette valeur ce n'est pas necessaire
La valeur je ne sais pas à quoi elle va servir; cela peut être différent à chaque fois. Elle rentre dans des zones formatées de ma base résultat (15,5) ensuite je la traiterai avec ces deux décimales donc 83,33 sera stocké certainement 83.33000 dans ma base. Bien sûr c'est en fn du traitement et je n'oublierais pas que c'est un %. Pour la restitution du chiffre, j'ai défini aussi pour chaque zone le nbre de décimales ds une table paramètre. Si bien que mes requetes font déjà le round() adéquat.
bref soit tu passe tout en texte et a ce moment la tu as bien 83,33 mais ne sera pas utilisable en tant que pourcentage sans avoir quelque part la notion que dans un calcul avec cette valeur il faudra / 100
sinon il faut exepliquer au client ce qu'est 83,33 % ce n'ai pas 83,33 mais bien 0,8333
oui on peux leur expliquer ;o) Mais je vous jure que pour le commun des utilisateurs Excel, ce qu'il voit à l'écran est LE chiffre. Et s'il l'a présenté comme cela , c'est qu'il veux qu'on le traite comme cela.
Bon dev @+
Une base de données est faite pour stocker des données.
Merci mais ma question n'était pas de savoir "qu'est ce qu'une base de donnée ?" 20 ans que je suis là dedans, je crois m'être fait une petite idée là dessus.
Dans ton cas tu dois stocker 0,833333333 et ensuite appliquer un masque %.
Non dans mon cas je dois stocker 83.33000 et travailler avec 83.33 Encore une fois ma question se limitait à Excel. Pour gérer les données de mes opérations en base, j'ai une réponse adaptée à mon métier et je ne vais pas créer une base spécifique et un programme spécifique à chaque fois que je reçois un fichier Excel.
Mieux ce pourcentage est peut peut être un simple calcul d'une colonne avec une autre colonne, dans ce cas on ne prend pas le %, mais on le recalcule au moment souhaité (dans la base ou à l'affichage).
Concernant l'utilisateur final sa remarque est judicieuse, et est du même type Msieur je veux mes valeurs négatives en rouge. Imagine si on stockait les heures/dates en fonction du format souhaité par l'utilisateur final, il faudrait faire du code spécifique à tous les niveaux.
Dans ton cas je ferais au moment de l'import un dictionnaire qui permet en fonction du nom de la colonne de définir un masque. Ce masque servirait pour la présentation des données.
@+
-- Eric Roumégou Webmaster des wtablettes http://cerbermail.com/?qE7t4Qvilo (cliquez sur le lien ci-dessus pour me contacter en privé)
