rvblog
Messages postés
792
Date d'inscription
vendredi 4 mars 2005
Statut
Membre
Dernière intervention
12 juin 2012
7
29 mars 2006 à 15:10
D'abord,
lis bien ce que j'ai écris, l'argument critères est composé de 2 expressions et est entouré de guillemets :
"annéemois >= 200509" And "RCN=9", non
"annéemois >= 200509 And RCN=9", oui
ensuite, je crois comprendre que le stockage d'annéemois fonctionne, mais à plus ou moins long terme, ça va "partir en cacahuète". Ici, s'il fonctionne, c'est parce qu'il est de type numérique. Mais on n'a jamais vu personne stocker ce genre de données, c'est très barbare. Tu as le choix :
- 2 champs de type numérique dans la table, un pour année, et un pour mois
- 1 champ de type Date dans la table, mais il te faut une date à stocker (et une vraie date, pas une chaine contenant la représentation littérale d'une date, à cause des problème de format).(la date, c'est vraiment ce qu'il y a de mieux, je ne te dis pas pourquoi, parce que je vais te dire plein d'autres choses, mais il faut me croire)
Si tu n'as pas de date à stocker, alors choisis la 1ère solution, et ça te fera un critère tel que suit :
"annee > = 2005 And mois>=09 And RCN=9"
ah oui, j'oubliait, on ne mets pas d'accent dans les noms d'identificateurs (de tables, de champs, de contrôles, de formulaire,...), Access le tolère, mais très peu d'autres langages, et encore moins d'autres base de données, et comme j'ai cru comprendre que tu réalises une maquette, vaut mieux suivre ce conseil!
D'ailleurs, c'est un très bon choix de ta part que de choisir Access pour réaliser une maquette. J'en profites pour te dire que, dans mon domaine professionnel, je rencontre beaucoup de projets qui sont passés par une phase de maquettage (souvent d'ailleurs pour aider à spécifier le besoin, et plus particulièrement dans le domaine scientifique).
Malheureusement, le maquettage est parfois long, et il grignote pas mal les budgets alloués (qui ne sont pas, comme beaucoup le croient, extensibles à volonté).
Alors un jour, un décideur se penche sur l'avancement du projet, et décide (c'est son métier, et il est très fort dans ce domaine) de mesurer combien a coûté le maquettage, et combien va coûter la réalisation de l'application définitive (démarche très méthodique de sa part, il est vraiment bon!).
Le problème est, que quand, dans la maquette, on n'a pas pris le soin de développer méthodiquement (certains diraient proprement), le portage (la récupération) de ce qu'on a maquetté va coûter exessivement cher, car la cible vers laquelle on porte n'est pas aussi tolérante que la source qui nous a permis de maquetter, et il y a beaucoup de corrections à faire, parfois même fonctionnelles.
Alors le décideur (encore lui!), malin comme un outil d'aide à la décision, va :
- 1./ décider qu'il n'y aura pas de portage.
- 2./ décider qu'on va utiliser la maquette finalisée comme une application finale.
- 3./ décider que le budget restant va être divisé en 2 (voire moins encore) pour la finalisation, parce qu'il y a forcément moins de boulot (il n'y a pas de portage!).
- 4./ décider que les fonctions supplémentaires prévues pour l'application finale, il va falloir les implémenter dans la maquette finalisée (et souvent, la maquette ne sait pas le faire).
Alors, l'outil livré (en retard sûrement), ne correspond pas exactement à ce que veulent les utilisateurs, a pleins de problèmes de fonctionnement, est très limité au niveau évolutif (quoi changer l'icone pour avoir un nouvel état, 2 semaines ?!?),
et on dira que c'est de la faute des développeurs, et les développeurs n'auront pas d'autre choix que de dire : "C'est encore un bug de Microsoft, on attend le patch", et Microsoft de dire "le produit est trop vieux, il n'y a plus de support!", alors les utilisateurs descendent dans la rue et protestent contre le CPE et la loi contre le téléchargement !! non, j'déconne.
je t'ai sûrement saoûlé, mais j'adore que les projets aboutissent (même si ce n'est pas les miens, à part ceux de la concurrence bien sûr :))
rvblogn<SUP>
</SUP><SUP>Je veux ton bien... et je l'aurais
</SUP>