Bonjour Marie-Jo, Le 31.05.2010 13:03, Marie jo Ooo a écrit : > Bonjour Jean Baptiste > > Le 29/05/2010 22:12, Jean-Baptiste Faure a écrit : >> Le 19.05.2010 09:14, Marie jo Ooo a écrit : >> >>> Bonjour, >>> >>> Je remonte sur QA car bug il y a >>> >>> Le 11/05/2010 06:35, Jean-Baptiste Faure a écrit : >>> >>>> Le 10.05.2010 09:03, Lionel a écrit : >>>> >>>> >>>>> Je sais comment contourner le problème, là n'est pas ma question. >>>>> Le problème >>>>> est que si il y a à la fois du texte et du nombre dans une >>>>> colonne, seules les >>>>> valeurs textes sont gardées !!! Demander à une secrétaire de >>>>> systématiquement >>>>> convertir ces champs est une hérésie !!! >>>>> Tout fonctionnait correctement dans la version précédente. >>>>> Si ce n'est pas le bon forum pour faire remonter les bugs, merci >>>>> de me le dire... >>>>> >>>>> >>>>> >>>> Bonjour, >>>> >>>> Je ne suis pas sûr que ce soit un bug mais plutôt un effet de bord >>>> d'un >>>> changement de comportement de Calc. Celui-ci : >>>> http://fr.openoffice.org/Marketing/nouv3.2.html#calc_strings >>>> >>>> Est-ce qu'il y a une raison pratique à avoir un mélange de types de >>>> données dans une colonne ? ou bien est-ce seulement une séquelle de >>>> l'import de sources variées ? >>>> >>>> >>> J'ai le même souci que je voulais remonter sur qa concernant des >>> dates ! >>> Les données disparaissent purement et simplement si la colonne ne >>> contient pas en effet des données de même valeur. >>> Et comme le dit Lionel, le sujet n'est pas de résoudre la >>> problématique mais de modifier ce nouveau comportement depuis la 3.2 >>> Oui, il y a plein de bonnes raisons à mélanger les données dans une >>> colonne ! >>> C'est à la machine de s'adapter à l'homme, pas l'inverse. >>> Je joins le fichier avec les dates que j'avais préparé (il s'agit d'un >>> vrai fichier d'une administration que j'ai épuré) >>> J'avais cherché les problèmes de formatage, de retour à la ligne mais >>> rien n'a fait. Et ce fil sur @user m'a confortée dans le fait >>> indéniable que >>> ce comportement est un bug... >>> >>> A ta disposition pour de plus amples explications. >>> >> Bonsoir Marie-Jo, >> >> Je veux bien de plus amples explications car je ne sais pas ce qu'il >> faut voir (ou voir qu'on ne voit pas ;-) ) dans ton fichier. >> > > Je viens de refaire des tests plus précis. Le problème vient de Base > Dans le fichier que j'ai envoyé, si tu l'ouvres dans Calc, tu > constates des données stockées dans un tableau > Lors de la connection pour un mailing (donc par base), les colonnes > contenant > DATE + texte OU Nombre + texte > sont ignorées. Seules les données textes sont visibles. > En revanche, si une colonne contient bien que des dates (ou des > cellules vides) cela marche. > C'est à mon sens un dysfonctionnement assez grave puisqu'il devient > presque impossible de réaliser > des publipostages.... > > Ai je été plus claire ? :-)
Oui, je crois :-) Quand j'utilise ton fichier comme BD avec OOo-Base, la colonne "Dt Envoi1" apparait quasiment vide alors qu'elle est pleine de dates si on ouvre le fichier avec Calc. Cependant je ne suis pas sûr que ce soit un bon argument pour les développeurs car cela révèle surtout qu'il y a des erreurs de saisie ou des ambigüités dans le fichier ods. Par exemple une date écrite 08/20/2010 : est-ce une erreur sur le mois (20 ?) ou un format non-standard pour 20/08/2010 ? Pour 05//03/2010 il y a moins de doute. Personnellement ce comportement de OOo-Base me parait plutôt une bonne chose dans le cas présent car il force à corriger les données. Qu'est-ce que toi tu aurais souhaité qu'il fasse ? Est-ce que tu as un exemple de fichier ods avec des données valides mal interprétées par OOo-Base ? Bonne journée JBF -- Seuls des formats ouverts peuvent assurer la pérennité de vos documents. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
