Discussion :

[_developpeur_]

Bonjour,

on me demande d'auditer une base Access ainsi que le code qui permet de faire vivre ses données via des forms.

N'ayant jamais fait d audit, je ne sais pas trop ce que je dois regarder. Quelqu'un aurait il un lien expliquant avec des lignes directrices comment réaliser un audit ?

Par avance merci pour votre aide.

[Sodangbe]

Salut!!

Alors ca veut dire que tu es un expert d'access? Moi j'ai fais un stage dans un grand cabinet d'audit(un des big four),et ils appellent ce genre d'audit "un audit informatique ".Allez va y dans google et tape "guide d'audit informatique" t'auras une source de renseignement terribe.Mais faudrais savoir que c'est un domaine très abstrait et ca devrait exigé de toi que tu sois très callé en access lors de l'évaluation des risques.

[Tofalu]

Bonjour, quelques pistes :

Conception
Structure des tables,
Nom des objets,
Indexation,
Clé primaire,
Relations


Performances
Boucle VBA,
Manipulation des recordsets,
Destructions des objets en mémoire,
Automation,
DAO / ADO (privilégier DAO)
Structure des requêtes (éviter les produits cartésiens, sous requêtes, UNION tant que possible)
Déclaration des variables

Autre

Travailler un maximum avec des classes,
Indentation du code VBA,
Ergonomie,
Vérifier les impressions
Taille du fichier,
sauvegarde,

etc.

Difficle d'être exaustif. Tu ne peux pas auditer une base si tu ne connais pas assez Access.

Si tu en viens à te demander, quoi regarder, je pense que l'audit sera faux

[_developpeur_]

Merci pour vos réponses.

Je vais le faire en quatres parties en m inspirant de ce que tu m a dit Tofalu:
Tables (relations, volumétrie...)
Objets visuels (Forms...)
Code VBA
Requete SQL.


Si vous avez d'autres pistes n'hésitez pas.
Merci

[Lou Pitchoun]

Salut,

J'ajouterais un point non négligeable : la sécurité tant au niveau de l'accès utilisateur que la sécurité des données.

[_developpeur_]

Tiens j'ai une question très précise, pensez que pour une table, 70 000 enregistrements, c'est excessif ?

Merci

[Lou Pitchoun]

Tiens j'ai une question très précise, pensez que pour une table, 70 000 enregistrements, c'est excessif ?

Merci

Non, j'ai vu quelque part qu'il peut y avoir plus d' 1 millions d'enregistrements.

[_developpeur_]

C'est aussi ce que je pensais, pourtant on me dis que ça rame en réseaux avec 3 utilisateurs connectés, je veux bien voir.
Je n'ai pas encore testé en réseaux mais je vais le faire pour voir ce que ça donne vraiment niveau perf.

Je laisse le post ouvert si d autres bonnes idées vous viennent.
Merci

[Sodangbe]

1 000 000? C'est enorme!!!!!!!!!!!!!!!! Et c'est vrai?

[Tofalu]

Le nombre de ligne importe peu.

Je viens de créer une table de 2 millions de ligne en 3 secondes ...

Ce qui compte c'est le nombre de ligne et de champs ainsi que les requêtes qui seront réalisées.

Ici, je n'avais qu'un champ

Pour ceux qui s'interroge, je viens de voir une table de 67 millions de lignes

Kikof, tu sors

[Lou Pitchoun]

Le nombre de ligne importe peu.

Je viens de créer une table de 2 millions de ligne en 3 secondes ...

Ce qui compte c'est le nombre de ligne et de champs ainsi que les requêtes qui seront réalisées.

Ici, je n'avais qu'un champ

Et moi, 67 108 864 enregistrements. et encore j'ai arrêté parce que le pc commençais à fumer...

[Sodangbe]

Ouah!!!envoie moi le code que je vois !!! A ton avis une table de 35 champs pourrait avoir combien d'enregistrement au max

[Tofalu]

C'est tout simple, tu crées une table avec un seul champ.

Et tu exécutes

For i = 1 to 25
Currentdb.execute "INSERT INTO MATABLE SELECT * FROM MATABLE"
Next i

La seule limite est de ne pas dépasser 2Go au total.

Les contraintes ne sont pas vraiment au niveau du stockage mais au niveau des requêtes.

[Sodangbe]

Merci pour les infos et pour le code

Now je suis un peu plus fixé sur quelques limites d'access .

[_developpeur_]

Bonjour,

En analysant le code de cette appli je me suis rendu compte que les recordset crées n'étaient jamais libérés.

Aussi, à chaque fois qu'un accès table est réalisé, un nouveau

Code :

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

set db = currentDB

est écrit.

La question est pensé vous que cela peut influencer les perfs d'une appli de manière conséquente ?

Merci

[Tofalu]

En analysant le code de cette appli je me suis rendu compte que les recordset crées n'étaient jamais libérés.

Tu en es sûr, quelles sont leur portée ?

Les recordsets sont automatiquement libérés lors de la destruction de la variable en fin de procédure ou de fonction.

Il est plutot recommandé de les libérer explicitement pour plusieurs raisons :

C'est une bonne habitude
ça ne prend pas de temps
ça évite aussi qu'un recordset dont la portée serait mal définie (genre global) reste instancié et bloque la base.


En ce qui concerne CurrentDb, si tu avais lu mon tutoriel sur DAO, tu te serais rendu compte qu'à chaque appel, il créer une nouvelle instance de l'objet. Dans de nombreux cas ce n'est pas dérangeant. Il vaut mieux instancier les objets à la volée plutot que de les stocker en mémoire pour rien.

Là où c'est plus embetant c'est dans ce cas :

Code :

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

1
2
3
For i=1 to 1000
   Msgbox CurrentDb.name
Next i

1000 objets database vont être instancié.

Il vaut mieux faire :

Code :

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

1
2
3
4
5
 
Set db=currentDb
For i=1 to 1000
   Msgbox Db.name
Next i

Mais en termes de perfs, ça reste de toute façon assez ridicule.

Ce n'est pas sur ces points de détails que ton audit doit être basé dans le cas d'un audit suite à un problème de perf.

[_developpeur_]

Tu en es sûr, quelles sont leur portée ?

Oui, dans chaque fonction ou procédure, dès lors qu'une requete sur la base est nécessaire. Une nouvelle instance d'un objet est crée.

set db = currentdb

En fin de proc ou fonction, cet objet n'est pas détruit avec un

Set db = nothing

Idem pour les recordsets.

Ce qui fait si nous avons 3 proc/fonctions dans l'appli, 300 instances d'objets sont crées et jamais libérés. Sauf à la fermeture de l'appli (je suppose)


Par contre, ce que je voulais confirmer c'est que je ne gagnerai rien en perfs en corrigeant tout ça.

Merci

[Tofalu]

Ce qui fait si nous avons 3 proc/fonctions dans l'appli, 300 instances d'objets sont crées et jamais libérés. Sauf à la fermeture de l'appli (je suppose)

Tu n'as pas compris mon message, ni lu la doc. Dommage

Quand tu fais :

Code :

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

1
2
3
4
5
sub test
dim orst as dao.recordset
set orst=....
 
end sub

orst est détruit à la fin de la procédure.

Là où c'est gourmand en ressources c'est quand tu as :

Code :

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

1
2
3
4
5
6
Public orst as dao.recordset
sub test
dim orst as dao.recordset
set orst=....
 
end sub

Dans ce cas l'objet n'est pas détruit

Par contre, ce que je voulais confirmer c'est que je ne gagnerai rien en perfs en corrigeant tout ça.

Tu ne gagnera pas en perf mais tu auras un code plus propre

[_developpeur_]

d'accord à présent je comprends que même si tu ne fait pas de

set rs = nothing en fin de procédure, l'objet est quand même détruit en mémoire.

donc aucun gain de perf si on corrige ce détail. Juste un code plus propre je suis d'accord avec toi.

[mout1234]

Bonjour,

...pensez que pour une table, 70 000 enregistrements, c'est excessif ?

...pourtant on me dis que ça rame en réseaux avec 3 utilisateurs connectés...

Juste une remarque, le nombre d'enregistrements stockés en absolu n'est pas le facteur déterminant. ce qui compte c'est le volume d'informations qui doivent véhiculer. Contrairement à une solution s'appuyant sur un serveur de données tel que SQL Server, sous Access le traitement des données (requêtes) est effectué en local...