Discussion :

[Invité]

Si la gestion des statistiques sur périodes mobiles vous pose quelques problèmes, j'espère que ce tutoriel vous permettra de trouver des pistes de réflexion.
http://jdgayot.developpez.com/tutori.../statsmobiles/

Si vous avez des commentaires, ou critiques... n'hésitez pas.

[Invité]

Salut

Que du bon, à lire absolument pour tout ceux qui ont à comparer des chiffres sur des périodes, et même les autres pour apprendre plein de trucs

Philippe

[LE VIEUX]

bonsoir,
2 exellents tutos le même jour, presque à la même heure, vous faites fort les cadors, continuez, ça m'interesse, et je pense que cela en interessera beaucoup d'autres, questions récurentes sur le sujet sur notre forum.
re bon WE à tous.

[loufab]

Y a pas à dire, C'est du lourd, du costaud !

Exemple pratique pour les pro j'aime ce genre de tuto ou l'on met en place une solution.

BRAVO !

[User]

Oui,

C'est vraiment impressionnant !

Et çà peut solutionner de nombreux problèmes différents de stats...

[random]

une simple requête analyse croisée sans une ligne de programmation (si ce n'est peut être des constantes pour mois, trimestre et année) ne permettrait elle pas d'arriver au même résultat avec une économie de moyens, et de tables intermédiaires ?

[Pierre Fauconnier]

Salut.

Pourrais-tu nous montrer la requête croisée sur base des données du tuto?

J'ai des doutes que l'on puisse y arriver sans programmation, dans l'optique, bien entendu, d'une automatisation complète du processus ( à destination de l'utilisateur qui ne doit rien créer par lui-même et qui est "pris par la main" pour établir ses stats mobiles)

[Invité]

Bonjour

En plus de ce que vient de dire Pierre, cet excellent tuto de Gayot est fait de manière à crée un état qui peut fonctionner avec un mde. Il est donc hyper complet et peut s'adapter à de grands cas de figures.

Philippe

[random]

à la relecture je comprends toute la subtilité et la puissance du tutoriel, je retire ce qui était une question sans intérêt

avec toutes mes excuses

[Tofalu]

à la relecture je comprends toute la subtilité et la puissance du tutoriel, je retire ce qui était une question sans intérêt

avec toutes mes excuses

Question sans intérêt, oui et non ?

Il faut reconnaitre que "dans la vie courante " les requêtes d'analyses croisées sont sous utilisées au profit d'un recours systématique à VBA. Est ce un bien ou un mal, difficile d'y répondre.

Le VBA est moins maintenable mais plus performant et plus souple, difficile de choisir

[Pierre Fauconnier]

Ici, le problème n'est pas que l'on sous-utilise les requêtes croisées ou que l'on préfère du VBA, mais bien que, sans VBA, il n'est pas possible d'arriver au résultat proposé, avec ou sans requête d'analyse croisée.

En fait, dès que l'on souhaite faciliter la tâche de l'utilisateur final, on est confronté à la quasi-obligation de recourir au VBA.

[random]

malheureusement je me sers d'access comme d'une calculette et je n'ai pas le souci d'utilisateur à assister , c'est sans doute pourquoi j'évite de recourir à la programmation, et j'ai réagi un un peu trop vite avec mes oeillères

en ce qui concerne l'extraction des données une requête analyse croisée paramétrée peut parfaitement faire l'affaire sans création de table intermédiaire (si besoin est je livrerais le sql)

en ce qui concerne le reporting j'avoue que la programmation me parait difficile à contourner

En fait, dès que l'on souhaite faciliter la tâche de l'utilisateur final, on est confronté à la quasi-obligation de recourir au VBA.

si on veut livrer des applications commerciales clefs en main oui

dans le cadre de développement interne à un service, on peut parfaitement éviter l'essentiel de la programmation, et se contenter de sql, avec une macro pour enchainer les traitements des requêtes

surtout si on délègue le reporting à excel

si l'application est jettable et ne sert que pour une étude on privilégiera la rapidité de développement, maintenant c'est mon expérience et ce n'est que mon expérience

[Pierre Fauconnier]

Bien entendu, Random... Tout est une question de point de vue.

Mais si je livre un truc Access en disant au gens:
"Pour le reportiong, vous devez passer par Excel et des TCD", ils vont me regarder d'un drôle d'air.

C'est exactement comme lorsque sur le forum, on a une réponse du genre "Pourquoi veux-tu automatiser ton filtre? Il suffit d'utiliser le filtre sur formulaire"...

Ben oui, mais
1) ça ne fait pas très pro
2) Faut encore que l'utilisateur, interne ou externe, sache comment faire

Et plus encore avec Access qu'avec Excel, les développeurs, professionnels ou non, ont en face d'eux des utilisateurs qui veulent juste que "ça marche" et qui ne vont pas se farcir une formation Access pour savoir comment filtrer des données, et cela même en interne, et parfois même, et souvent, au sein des services informatiques qui ne veulent pas entendre parler d'Access et qui n'y connaissent rien en Access. Ils sont tout éberlués lorsque, avec quelques lignes de code, on leur pond un truc qui tourne, alors qu'ils en étaient toujours à essayer de planifier l'avant-projet de leur solution pour dans les six prochains mois

Maintenant, l'utilisateur qui veut suivre ses comptes privés de mois en mois, qui connaît un peu Access et qui est d'accord soit de bidouiller un peu, soit de se contenter d'un résultat ergonomiquement laborieux à obtenir, pourra bien entendu se débrouiller avec des requêtes, croisées ou non, qui s'enchainent, mais on n'est plus alors dans le cadre du développement professionnel, or DVP s'adresse d'abord à des utilisateurs Access (côté développeurs) qui s'inscrivent dans cette optique.

[random]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
PARAMETERS [dar] DateTime, [nbmois] Byte;
TRANSFORM Sum([Quantité]*[prix unitaire]*(1-[remise])) AS mt
SELECT Produits.Catégorie, Produits.[Nom du produit], Sum([Quantité]*[prix unitaire]*(1-[remise])) AS total, Sum([Quantité]*[prix unitaire]*(1-[remise])/[nbmois]) AS moyenne
FROM Produits LEFT JOIN (Commandes RIGHT JOIN [Détails commande] ON Commandes.[Réf commande] = [Détails commande].[Réf commande]) ON Produits.ID = [Détails commande].[Réf produit]
WHERE (((Commandes.[Date de commande])<=DateSerial(Year([dar]),Month([dar])+1,0) And (Commandes.[Date de commande])>=DateSerial(Year([dar]),Month([dar])-[nbmois]+1,1)))
GROUP BY Produits.Catégorie, Produits.[Nom du produit]
ORDER BY Produits.Catégorie, Produits.[Nom du produit], (Year([date de commande])*100)+Month([date de commande])
PIVOT (Year([date de commande])*100)+Month([date de commande]);

temps de développement 21 minutes incluant le téléchargement de northwind et sa redécouverte (c'est ma conception du pro et ce type de réponse tourne des années dans des organisations pro )

avec [dar] date d'arrêté et [nbmois] le nombre de mois analysés
les messages d'invite pourront évidemment être peaufinés pour que ce soit pro

[Pierre Fauconnier]

Belle performance...

Tu remplaces la méthode d'une partie du tuto par la tienne, et chacun a maintenant deux méthodes à sa disposition, l'une en SQL, l'autre avec plus de code VBA, pour ce qui est de l'analyse des données.

Mais ta réponse s'apparente à une réponse technique sur un problème précis en forum, alors que le tuto aborde un problème de A à Z, en prenant en compte la saisie des contraintes de manière pro, jusqu'à la présentation des données finales de manière pro, ce qui conviendra mieux à un directeur financier qu'un résultat de requête brut, même si ta requête fonctionne très bien.

Il y a donc deux approches différentes, la tienne, très pro côté sql, et celle de Gayot, qui privilégie l'ergonomie et la finalisation profesionnelle.

Chacun choisira, en fonction de ses affinités, notamment avec SQL.

Je compléterai mon intervention en disant que si c'est pour sortir les stats en brut de brut, et que c'est ce résultat qui compte, alors, je prends un TCD Excel basé sur une requête MSQuery et je fais cela en 30 secondes, et si côté mise en forme, ce ne sera pas le top non plus, l'utilisateur averti d'un TCD fera à peu près ce qu'il veut comme manipulation de données, sans connaître SQL ou Access, et bien plus facilement qu'avec ta requête, mais le directeur financier à qui je donnerai le classeur sera probablement dans une belle panade ...

[magbouya]

Mon problème réside dans l'étape 4 concernant la mise à jour de la table "Tbl_Temp_Recap".

Mise à jour colonne par colonne, de la table "Tbl_Temp_Recap".

Les données réactualisées mois par mois proviendront de la table "Tbl_Temp_MoisCa".
S'il n'y a pas eu de ventes sur un produit pendant un mois donné, la valeur restera à 0.

Je n'ai pas de valeur nulle quand il n'y a pas de Total_LSetLP pendant une année donnée. Par exmple, soit une commune ayant un Insee_com 75033, et une période choisie 2007 - 2013 :

Ma table "Tbl_Temp_MoisCa" affiche le résultat suivant :

Insee_com Annee Total_LSetLP
75033 2007 45
75033 2010 323
75033 2011 788
75033 2012 53

Tandis que ma table "Tbl_Temp_Recap" affiche :

Insee_com 2007 2008 2009 2010 2011 2012 2013
75033 45 45 45 323 788 53 53

Comme l'indique cet exemple, pour cette commune je n'ai pas de valeurs pour les années 2008, 2009 ET 2013 dans la table "Tbl_Temp_MoisCa". Mais dans la table "Tbl_Temp_Recap" ces années réprenent la valeur de mon Total_LSetLP de l'année qui l'a précédée.

Ma question, si quelqu'un a compris mon problème, comment faire pour afficher zéro et non reprendre la valeur de l'année précédente ?

Sinon, est-ce possible de faire un état aussi dynamique en utilisant comme source de données une requête analyse croisée (comme celle proposée par Random) ?

Merci,

MagBouya.

[Invité]

Bonjour et bienvenue sur Dvp
Je viens de voir ton message.
Ne connaissant pas les structures de tes tables et requêtes il m'est difficile de te répondre comme cela.
Il y a quelque chose qui empêche la boucle de se faire correctement.

Ta table Tbl_Temp_Recap comporte t'elle bien, une fois créée, toutes tes années avec en première ligne la valeur 0 par défaut. Pour cela met un point d'arrêt après la création de la table.

[magbouya]

Salut,

En ajoutant juste une condition WHERE dans une requête de la fonction Miseajour(), tout marche bien, plus de problème.

Avec ce tutoriel, plus besoin de fixer une période préalablement pour exploiter dynamiquement les requêtes analyse croisée comme source de données des états.

Merci,

MagBouya