Discussion :

[anglaigus]

Bonjour,

Je rencontre pour la première fois le très célèbre message "Ressources système insuffisantes".

J'utilise le mode création pour construire mes tables et requêtes. Le projet Access que je construis ressemble à ce qui suit:

- Une table nommée Achats contenant les dépenses de clients fréquentant un même ensemble de magasins. Chaque ligne identifie le client, le nom du magasin, la date des achats du client, la dépense par type X de produit (de A à N) et une quantité appelée seuil X (de A à N) au delà duquel le client obtient un rabais pour gros volume d'achats (chaque magasin définit ces seuils).

Client_ID	Magasin	Date_achat	Seuil_A	Depense_A	Seuil_B	Depense_B	Seuil_C	Depense_C	...	jusqu'à N

Objectif: Chaque fois qu'un des magasins enregistre le passage d'un client, je veux déterminer quand, la dernière fois, il a déjà acheté le produit X, ce qu'il a dépensé pour ce produit X ainsi que le seuil X associé. Je ne m'intéresse pas au nom du magasin où ce produit X a été acheté la dernière fois.

- La requête 1 (Req1) reprend les champs de la table Achats et vise à déterminer la date précédente (ou la dernière fois) où le client a déjà acheté le produit X (de A à N) dans un quelconque magasin.

Client_ID

Date_achat

Seuil_A

Depense_A

Date_achat_precedent_A

Seuil_B

Depense_B

Date_achat_precedent_B

Seuil_C

Depense_C

Date_achat_precedent_C

...

jusqu'à N

Les champs Date_achat_precedent_X (de A à N) sont calculés comme suit:
Date_achat_precedent_X: (SELECT max (HA.Date_achat) FROM Achats AS HA WHERE HA.Client_ID=Achats.Client_ID AND HA.X IS NOT NULL AND Achats.X IS NOT NULL AND HA.Date_achat<Achats.Date_achat)

R1 fonctionne très bien avec une table Achats comprenant 1000 lignes et est très rapide. Il me reste donc à déterminer les dépenses par type de produit et les seuils associés correspondant à Date_achat_precedent_X.

- Requête 2 (Req2),

Client_ID

Date_achat

Date_achat_precedent_A

Seuil_precedent_A

Depense_precedente_A

Date_achat_precedent_B

Seuil_precedent_B

Depense_precedente_B

Date_achat_precedent_C

Seuil_precedent_C

Depense_precedente_C

...

jusqu'à N

Pour les champs Seuil_precedent_X: (SELECT R1.Seuil_X FROM Req1 AS R1 WHERE R1.Date_achat=Req1.Date_achat_precedent_X)

Pour les champs Depense_precedente_X: (SELECT R1.Depense_X FROM Req1 AS R1 WHERE R1.Date_achat=Req1.Date_achat_precedent_X)

Résultats:

En exécutant la requête 2 et en moins d'une seconde, Access répond : "Ressources système insuffisantes". J'enlève alors des champs dans cette requête pour ne garder que les produits A à X (X<N) jusqu'à ce qu'elle s'exécute sans erreur.

Avec Access 2010 32 bits, la requête 2 s'exécute correctement pour tous les produits de A à I.
Avec Access 2010 64 bits, la requête 2 s'exécute correctement pour les produits de A à B seulement.

Je m'attendais à l'inverse!

Les ressources mémoire consommées ne dépassent pas 60 Mo dans les deux versions (Gestionnaire de tâches). Cela dit, vu les caractéristiques de ma machine (voir à la fin) je ne comprends pas le message d'erreur. Redémarrer l'ordinateur n'y a rien changé.

J'ai aussi essayé de remplacer mes sous-requêtes SELECT par des DMAX et DLookUp mais alors l'exécution des requêtes n'aboutit pas à moins de réduire considérablement le nombre de produits X analysés.
J'ai essayé d'exécuter Access avec un seul coeur sans aucune différence. Je n'ai rien fait pour limiter les ressources mémoire à Access. Je n'ai pas vu de dépassement selon les caractéristiques de Access publiées par Microsoft.

Qu'ai-je fait de mal? Je suis ouvert à toute autre façon d'écrire mes requêtes.

Merci de me sortir de ce mauvais pas dans lequel je suis empêtré depuis plusieurs jours.


Le hotfix 2760394 ne s'applique pas à mon système (message Windows)
Taille de mon projet Access : 22 Mo
Système :
Windows 8.1 Enterprise 64 bits à jour
Microsoft Access 2010 32 bits ou 64 bits
Intel Core i7-4790 3.6 GHz
16 Go RAM
Espace disque disponible : 800 Go

[marot_r]

Bonjour.

Je ne sais pas d'où cela vient mais Access marche assez mal en colonne, il préfère les données les unes en dessous des autres.

Est-ce pour des raisons de présentations que tu y vas avec tes N colonnes qui ne sont que la répétition des même type de données.

Donc comparer avec l'enregistrement précédent ne devrait pas être trop demandeur même si pour faire cela Excel est meilleur car en Access il n'y a pas de notion d'enregistrement précédent, il faut trouver celui qui est "juste" plus petit que le courant parmis TOUS les enregistrements disponibles, à répéter pour chaque enregistrement.

Une solution serait d'avoir un champ numéro de vente/produit du client que tu incrémentes au fur et à mesure et donc au lieu d'aller "à la pêche" dans tous tes enregistrements tu n'as plus qu'à trouver celui dont le numéro est client/produit/Numero-1. Ce qui devrait sérieusement améliorer tes performances.

Cette numérotation peut se faire à la saisie ou juste avant de calculer tes stats. Et personnellement je le ferai en VBA en ayant trié mes données par client/produit/DateVente.

On peut le faire en SQL mais je pense que ce sera moins performant à cause du comptage des précédents.

A+

[anglaigus]

Bonjour,

Ce que j'ai présenté ici s'inscrit dans un projet plus complexe. Il y a notamment des formulaires qui affichent toutes les dépenses de tous les produits lorsque l'utilisateur choisit le Client_ID. Le formulaire est vite créé lorsque la table/requête source est présentée comme je l'ai fait. Il y a une autre raison: avant de commencer le projet, j'ai eu comme instruction de présenter des tables et requêtes facile à lire à l'affichage sans passer par les formulaires et d'éviter le VBA. L'argument est de pouvoir facilement passer mon travail à une autre personne si je ne suis pas là.

En vous lisant, je me rends compte que cette façon de présenter les données est nuisible pour les performances. Mais je veux être sûr d'avoir bien compris. Je pourrais donc réécrire la table Achats en 6 colonnes seulement:


Client_ID Magasin Date_achat Produit Seuil Depense

puis formuler une requête pour collecter toutes les dépenses et seuils des produits A à N, la date de l'achat précédent de ces produits ainsi que les seuils et dépenses précédents, dès lors que l'utilisateur choisit un client_ID et une date d'achat. Avec cette méthode je peux m'attendre à une réduction de la consommation des ressources?

Merci.

[marot_r]

Bonjour.

Je pense que oui, du moins c'est ce que j'essaierai.

Et surtout la numerotation de tes donnees pas client/produit/date devrait aider puisqu'il n'y aurai qu'un seul enregistrement correspondant.

Ceci la presentation en colonne n'en serait pas forcement facilitee.

Tu pourrais envisager d'avoir une table de resultat que tu completerai avec des requetes mais sans VBA (ou macro) ca va etre asssez penible car il n'y a pas de boucle en SQL donc tu ne peux pas executer tes requetes automatiquement et ll faut faire une requite par series de colonne.

Si c'est envisageable, je te conseille de regarder du cote des tableaux croise dynamique d'Excel en partant de ta derniere structure de table qui me paraissent plus adaptes a ton besoin.

Et tu pourrais envisager d'utiliser un rapport et un sous rapport multicolonne ... mais si les formulaires sont intredits, il est probable que les rapports le soient aussi.
De plus les rapports sont limites par la largeur des feuilles de papier donc si tu as beaucoup de colonne cela n'ira sans doute pas.

A+