Séparer les DL en 2 champs distincts Mois et Année ?

[bronsky]

Message précédent :
J'ai bien compris... c la conversion dans l'autre sens qui n'est pas possible.
C'est pas l'écriture qui pose problème, c'est la lecture.

Tu rentre un album, tu choisis 2è trim 94, le programme transforme ça en 04/1994. Bon. Encore une fois, ya rien de miraculeux là-dedans.
Problème : tu reviens le lendemain tu demande au logiciel le DL de cet album, il consulte la base et lit "04/1994". A partir de là, comment il sait, le logiciel, s'il doit afficher "2 trim 1994" ou "avril 1994" ??? Il peut pas la savoir !
Il peut pas parce que ta conversion est UNILATERALE !

C'est moi qui m'exprime mal ou quoi ?! Ca me paraît pas dur à comprendre...

[xtof]

J'ai bien compris... c la conversion dans l'autre sens qui n'est pas possible.
C'est pas l'écriture qui pose problème, c'est la lecture.

Tu rentre un album, tu choisis 2è trim 94, le programme transforme ça en 04/1994. Bon. Encore une fois, ya rien de miraculeux là-dedans.
Problème : tu reviens le lendemain tu demande au logiciel le DL de cet album, il consulte la base et lit "04/1994". A partir de là, comment il sait, le logiciel, s'il doit afficher "2 trim 1994" ou "avril 1994" ??? Il peut pas la savoir !
Il peut pas parce que ta conversion est UNILATERALE !

C'est moi qui m'exprime mal ou quoi ?! Ca me paraît pas dur à comprendre...

Desolé j'avais pas compris ce que tu n'avais pas compris
Pour moi c'était clair que dans la base tu conserves les 3 champs "Mois", "Année" et "Mois+Annee/reformaté" et que ce dernier n'est tout simplement pas visible pour l'utilisateur.

[bronsky]

Bon ben on en revient à ce que je disait, c super chiant à mettre en place, pour un truc qui est loin d'être une priorité. Bref, le chef a autre chose à foutre à mon humble avis. (cf. le post-it sur la nouvelle version, qui parle de trucs nettement plus utiles)

Pour avoir fait un peu d'access et m'être arraché les cheveux à cause de formats de dates je sais à quel point tu dois me détester ....

Je pense que tu devrait encore faire du access pendant quelques mois, histoire de bien t'en dégouter, parce que si tu t'étais vraiment pris la tête dessus tu n'aurais pas fait cette proposition

[deuzef]

Je vais apporter ma pierre à l'édifice en espérant ne pas le faire écrouler

Juste pour vous citer mon expérience sur le sujet des dates.

Je travaille en régie chez un grand compte, Peugeot pour ne pas le citer, ou ce pb de dates a été très largement soulevé. Je travaille sur des "composants logiciels" qui font appel à des masses des données sous bases oracles directement en liaison avec les chaînes de prod de toutes les usines du groupes.
Bref après moult discutions et réflexions sur le sujet vu les tonnes de formats possibles dans les dates il a été décidé d'enregistrer les dates en base sous un format de chaines de caractères avec diverses moulinettes pour convertir dans un autre format souhaité.

La reconnaissance du format de la date se faisant principalement sur la longueur de la chaine enregistrée.
Evidemment les ihm's sont bridés pour limiter les possibilités d'insertion dans les bases.

C'est une solution comme une autre.

[bronsky]

avec diverses moulinettes pour convertir dans un autre format souhaité.

C'est la création des moulinettes en question qui s'avère justement la plus laborieuse... je ne dis pas que c'est pas une bonne solution, mais juste qu'elle a un coût. Dans le contexte de la base BDGest, ce coût n'est pas justifié.
Par contre dans le contexte de ton boulot, avec une base vraiment complexe et étant donnée que le problème est apparemment récurrent, là d'accord ça devient intéressant...

[deuzef]

C'est la création des moulinettes en question qui s'avère justement la plus laborieuse

pas vraiment les moulinettes que j'utilise sont 3 fonctions à paramètres qui s'entre-appel pour un total de 30 lignes max et tu fais tous les formats utilisés chez Peugeot.

30 lignes ce n'est pas si complexe

[BDGest]

C'est la création des moulinettes en question qui s'avère justement la plus laborieuse

pas vraiment les moulinettes que j'utilise sont 3 fonctions à paramètres qui s'entre-appel pour un total de 30 lignes max et tu fais tous les formats utilisés chez Peugeot.

30 lignes ce n'est pas si complexe

Je peux te filler 30 lignes de code C et tu vas voir si on peut pas faire du complexe en 30 lignes

[deuzef]

Je peux te filler 30 lignes de code C et tu vas voir si on peut pas faire du complexe en 30 lignes

je sais que l'on peut faire tout et aussi n'importe quoi en C (regarde mon profil) mais là pas de bol cette fois ci je fais du java

tu as besoin de 30 lignes toi en C pour faire complexe ? 1 seule suffit quelques fois

[xtof]

Bref, le chef a autre chose à foutre à mon humble avis. (cf. le post-it sur la nouvelle version, qui parle de trucs nettement plus utiles)

AMHA savoir si une DL 01/xxx est une véritable valeur ou une valeur fictive inserée là par défaut présente un intérêt pour tout collectioneur et chasseur d'eo. Et il y en a !

Je n'en fais pas partie (des chasseurs d'eo) mais je fais par contre partie des gens qui préfèrent qu'une information ne soit pas affichée du tout plutôt qu'avec une valeur qui puisse induire en erreur.
Et je fais aussi partie des gens qui pensent que si on peut améliorer un système il faut le faire, même si c'est pas facile....

Finalement je prend acte qu'apparemment ma suggestion n'a pas declenché une vague de soutien et j'en déduis que pour la plupart des utilisateurs de BDGest une telle modif n'est pas nécessaire.

[bronsky]

Y avait longtemps... bon allons-y...

AMHA savoir si une DL 01/xxx est une véritable valeur ou une valeur fictive inserée là par défaut présente un intérêt pour tout collectioneur et chasseur d'eo. Et il y en a !

Je sais, j'en fait partie.

Je n'en fais pas partie (des chasseurs d'eo) mais je fais par contre partie des gens qui préfèrent qu'une information ne soit pas affichée du tout plutôt qu'avec une valeur qui puisse induire en erreur.

Rien ne t'oblige à remplir ce champ, il peut rester vide !
Et si tu veux savoir si un xx/xxxx correspond à un mois ou un trimestre, c'est pas dur tu vas voir dans ta bédéthèque, tu prend l'album en question ou un autre dans la série (généralement ça change pas au sein d'une série) et tu regarde si c'est exprimé en trimestre ou en mois.

Et je fais aussi partie des gens qui pensent que si on peut améliorer un système il faut le faire, même si c'est pas facile....

Et moi je fais partie des gens qui pensent qu'avant de se lancer dans une modif, on doit réfléchir au rapport [temps de dvlpt]/[utilité]. Sinon on cours à la catastrophe. Le chef, qui est autrement plus expérimenté que moi, sera je pense d'accord avec ça...

[Gaffophone]

Finalement je prend acte qu'apparemment ma suggestion n'a pas declenché une vague de soutien et j'en déduis que pour la plupart des utilisateurs de BDGest une telle modif n'est pas nécessaire.

Je trouve ta suggestion très bonne et je pense que c'est au chef de voir si c'est faisable pour lui sans trop se prendre la tête

Et je ne pense pas que ce soit à nous de dire si le chef a "autre chose à foutre ou pas" ! :siffle: Il n'est pas interdit de suggérer des idées, loin de là, non ?

[bronsky]

sans trop se prendre la tête

La longueur de ce post laisse déjà présager du contraire ...

Et je ne pense pas que ce soit à nous de dire si le chef a "autre chose à foutre ou pas" ! :siffle:

Je fais juste référence aux modifs décrite dans le post-it dédié, et je me dit que ça doit prendre pas mal de temps déjà...


Mais allez-y suggérez suggérez !!
(moi tant qu'on m'empêche pas de contredire :siffle: )

[Yog-volo]

Et si tu veux savoir si un xx/xxxx correspond à un mois ou un trimestre, c'est pas dur tu vas voir dans ta bédéthèque, tu prend l'album en question ou un autre dans la série (généralement ça change pas au sein d'une série) et tu regarde si c'est exprimé en trimestre ou en mois.

Ben c'est plutôt avant qu'elle soit dans ma bibliothèque que j'ai besoin de l'info exacte. J'ai une liste des EO que je recherche avec toutes les infos dont j'ai besoin pour les identifier à coup sûr ( DL, A.I, titres au catalogue, etc...). Des infos + précises m'éviteraient des dépenses inutiles.

[bronsky]

Et si tu veux savoir si un xx/xxxx correspond à un mois ou un trimestre, c'est pas dur tu vas voir dans ta bédéthèque, tu prend l'album en question ou un autre dans la série (généralement ça change pas au sein d'une série) et tu regarde si c'est exprimé en trimestre ou en mois.

Ben c'est plutôt avant qu'elle soit dans ma bibliothèque que j'ai besoin de l'info exacte. J'ai une liste des EO que je recherche avec toutes les infos dont j'ai besoin pour les identifier à coup sûr ( DL, A.I, titres au catalogue, etc...). Des infos + précises m'éviteraient des dépenses inutiles.

Pour l'instant ce qui est surtout gênant à ce niveau-là, c'est que la BEL est truffée d'album qui ont un DL 01/xxxx parce que celui qui les a créé n'a pas voulu préciser le mois... Faut corriger ça au cas par cas, et ça va sûrement être long.

Parce que sinon, sauf erreur de la BEL, encore une fois je vois pas le problème : tu va dans la BEL, admettons que c marqué "04/1997" (simple exemple). Bon, tu prend ça en note, tu t'en va courrir les brocantes et là tu tombe dessus. Seulement c pas marqué "04/1997" mais "2è trimestre 1997". Ne me dis pas que tu vas te dire "ah ben merde c'est pas l'EO, vu qu'elle est pas d'avril 97" ? Tu auras plutôt l'intelligence de te dire "Bon ben apparemment cette série est exprimée en trimestre et la BEL voulait dire "2è trimestre 97", donc nickel c'est bien l'EO, j'achète" .

Bon enfin bref, moi perso c'est vraiment pas ça qui me pose le plus de problème dans la détermination des EO...