Discussion :

[portu]

Bonjour,
J'ai un logiciel conçu à l'aide de Delphi 7 Pro qui utilise une base de données Access par ADO.
Jusque là, tout est OK !

Dans de nombreux cas, la base de données peut être très grosse (+-100 MO) et utilisation mutli-postes (en réseau donc).

Le logiciel est basé sur la comptabilité donc, il y a beaucoup de calculs de soldes. Ces calculs de soldes se font à partir d'une grosse table pouvant frôler les 130.000 records.

J'ai donc un peu tourné mon logiciel dans tout les sens afin de voir ce qui clochait et j'ai remarqué ceci:

J'exécute mon logiciel --> j'effectue des recherches sur des clients de la compta, donc une série de requêtes SQl s'exécutent (SELECT). Tout est parfaitement rapide.

Mais dès qu'une requête UPDATE ou INSERT est exécutée, tout marche au ralenti ! Surtout tout ce qui est des requêtes de types SELECT.

D'où pourrait-venir ce problème ?
- Gestion de mémoire ?
- Trop grosse DB pour le réseau (engendre bcp de trafic réseau) ?
- Logiciel non adapté pour une DB fichier, le client-serveur serait préférable ?
- Optimisation possible de la DB Access ?

Merci d'avance

Ps : J'espère avoir été plus clair que mon précédent post

[Frank]

bonjour,

les requêtes SELECT sont longues pendant les reqûetes action ou aprés ?
Etant donné qu'il s'agit d'une application multiutilisateurs, la base doit se vérouiller, je pense.

[portu]

bonjour,

les requêtes SELECT sont longues pendant les reqûetes action ou aprés ?
Etant donné qu'il s'agit d'une application multiutilisateurs, la base doit se vérouiller, je pense.

Bein au début, toutes mes requêtes de type SELECT sont "rapides" vu la taille de la base de données. Ensuite dès qu'une requête Action est passé, toutes les requêtes SELECT sont plus lentes à extrêmement lentes

Pour le verrouillage de la base, c'est normal. Je ne pense pas que ca en soit la cause.

[Frank]

Quelle taille fait la base après la requête action ?
Les connections/deconnections sont bien gérées au niveau des requêtes ?

[portu]

Quelle taille fait la base après la requête action ?

Pourquoi cette question ? bein après une requête "action", la taille change de très peu vu que cela n'affecte que très peu de records.
(J'ai peut être mal compris ta question).

Les connections/deconnections sont bien gérées au niveau des requêtes ?

Je ne sais pas si j'ai compris ta question

Au niveau des ADOQuery ? J'ai l'habitude des les désactiver avant de les activés.
Donc, lorsque j'utilise un ADOQuery , je ne le désactive pas après avoir pris le résultat.
Exemple :

Code :

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

1
2
3
4
 
Query1.Active := False;
Query1.Sql.Text := 'SELECT CHAMP1 FROM TABLE1 ;';
Query1.Active := True;

[Frank]

La question 1, c'atait pour voir si tes calculs nécessitaient de créer des tables temporaires qui pourraient alourdir ta base.

La 2, et bien tu y as répondu.

[portu]

La question 1, c'atait pour voir si tes calculs nécessitaient de créer des tables temporaires qui pourraient alourdir ta base.

La 2, et bien tu y as répondu.

Haaaa,
Non, je n'utilise aucune table temporaire par soucis d'augmentation de la taille de la DB.

[skywaukers]

bonjour,

sans aucune hésitation, vos tables sont trop grosses pour ce type de bdd en réseau (access en réseau ... ), à votre place je prendrais une vraie BDD (Firebird ou SQL Server si vous tenez à Microsoft).

@++
Dany

[portu]

bonjour,

sans aucune hésitation, vos tables sont trop grosses pour ce type de bdd en réseau (access en réseau ... ), à votre place je prendrais une vraie BDD (Firebird ou SQL Server si vous tenez à Microsoft).

@++
Dany

Naaaaaaaaaa
C'est ce que je craignais...

En fait, plusieurs choses forcer à choisir Acces.

Ce programme est un successeur d'une version DOS avec DB DBase.

- DBase étant aussi une DB fichier, et aucune lenteur ressentie sur un réseau.
- Un DB client/serveur est plus dure à gérer et à déployer lorsque le logiciel est commercialisé non ?
- Access est très facile à gérer et à déployer.

Voilà pourquoi mon choix c'est posé sur Access.

C'est que je comprends pas, c'est que Pourquoi l'ancien version du soft basée sur DBase était rapide vue qu'en plus , la structure à très peu été modifiée?

Merci

[Rayek]

Il faut penser a compacter la base access de temps en temps. Ca ne peut que lui faire du bien, car le compactage enlèvera les données parasites car access à la facheuse tendance à laisser des traces de toutes les manipulations qu'on peut faire avec.

J'ai déjà vu tourner en reseau des base access avec 5 à 6 fois plus de données et il n'y a aucun problème de lenteur.

[portu]

Il faut penser a compacter la base access de temps en temps. Ca ne peut que lui faire du bien, car le compactage enlèvera les données parasites car access à la facheuse tendance à laisser des traces de toutes les manipulations qu'on peut faire avec.

c'est bien entendu la première chose que j'ai vérifiée .

J'ai déjà vu tourner en reseau des base access avec 5 à 6 fois plus de données et il n'y a aucun problème de lenteur.

Oui, mais tout dépend maintenant dans quel contexte la base est utilisée.
Pour un gestionnaire de dossier, c'est clair que les requêtes ne seront jamais très lourdes comparé à une base dans un contexte "Montant" avec des requêtes SUM + Jointure sur de grosses tables, là , les performance peuvent changer.

Enfin, je pense

Maintenant , je me dis qu'avoir un Db fichier de grande taille engendre une saturation dans le réseau (Contrairement à DBase puisqu'un fichier = à une table). Est ce que si je recrée une seconde DB avec la plus grosse table dedans et que je lie cette table dans la premiere DB . Les performance réseau seront meilleur ?

[Rayek]

Pour la connexion a ta base de données, tu utilises une connexion oleDb ou bien odbc ?

[portu]

Pour la connexion a ta base de données, tu utilises une connexion oleDb ou bien odbc ?

OleDb par Microsoft Jet 4.0

[Rayek]

Essai en odbc (oui oui c'est bete de revenir en arrière mais bon).

Sinon essai en mettant des "procédures stockées" (remarques les ") direct dans la base et fait y appel via ton logiciel.

[okparanoid]

J'ai déjà vu tourner en reseau des base access avec 5 à 6 fois plus de données et il n'y a aucun problème de lenteur.

Le sujet m'interesse parce que je developpe actuellement pour une bd access et cela m'intrigue un peu.

Quand une base Access fait 500 Mo et qu'on y accede en reseau, a chaque premiere connection, physiquement ca genere un trafic reseau de 500 Mo et idem dans l'autre sens a chaque fois que je fais une mise a jour non ?

D'ailleurs dans ce cas, parce que je ne crois pas tres bien comprendre le fonctionnement des curseurs, s'il est a cluseserver, le trafic doit se regenerer a chaque fois que j'interroge la base et s'il est a useclient c'est la base de donnees en "cache" sur le client qui est interrogee ?

Merci pour vos precisions

[Rayek]

Quand une base Access fait 500 Mo et qu'on y accede en reseau, a chaque premiere connection, physiquement ca genere un trafic reseau de 500 Mo et idem dans l'autre sens a chaque fois que je fais une mise a jour non ?

Mon dieu, non, si, à chaque fois que l'on se connecte à une base de données et que cette derniere la chargeait cmpètement, cela serait ingérable.
Quand tu te connectes à une base de données, le trafic est minime (quelques octets de discution pour dire "coucou c'est moi qui suit la" et "ok c'est bon je t'ai vu")
Après la où cela peut prendre du temps, de la ressource et du trafic réseau, c'est pendant de grosses requetes ou de l'ouverture de table en direct (les TxxxTable rapatrie l'intégralité des données de la table sur le poste appellant)

D'ailleurs dans ce cas, parce que je ne crois pas tres bien comprendre le fonctionnement des curseurs, s'il est a cluseserver, le trafic doit se regenerer a chaque fois que j'interroge la base et s'il est a useclient c'est la base de donnees en "cache" sur le client qui est interrogee ?

Merci pour vos precisions

En gros oui. Dans le premier cas (useserver) les données seront toujours à jour au niveau de l'affichage alors qu'avec le deuxieme cas (useclient), pour avoir des données à jours il faut rafraichir les données (donc un rappel total de la requete/table à un instant T)

[okparanoid]

Merci pour ta reponse, mais il y a toujours un truc qui m'echappe, parce que justement, si le poste veut alerter de sa presence, faut bien qu'il s'adresse a quelqu'un non, à qui en l'occurence vu qu'on est pas en C/S ? Dans le cas de la base Access situee sur un emplacement reseau, comment il s'y prend pour pouvoir "l'ouvrir" sans devoir la recuperer integralement sur son poste et donc rapatrier les 500 Mo ? En gros est-ce qu'a distance il peut juste furete une partie du fichier mdb, celle qui lui interesse sur un disque qu'il ne controle pas ?

[Rayek]

Merci pour ta reponse, mais il y a toujours un truc qui m'echappe, parce que justement, si le poste veut alerter de sa presence, faut bien qu'il s'adresse a quelqu'un non, à qui en l'occurence vu qu'on est pas en C/S ?
Dans le cas de la base Access situee sur un emplacement reseau, comment il s'y prend pour pouvoir "l'ouvrir" sans devoir la recuperer integralement sur son poste et donc rapatrier les 500 Mo ? En gros est-ce qu'a distance il peut juste furete une partie du fichier mdb, celle qui lui interesse sur un disque qu'il ne controle pas ?

C'est le pilote (Jet engine ou ODBC) qui s'occupe de l' "ouverture" et du "furetage" dans la base de données. Après savoir comment il fonctionne c'est une autre histoire.
Tout ce que l'on remarque c'est qu'il ne rapatrie pas la base de données chez toi (ce qui serait stupide et très long).
Les données ne sont rapatriées sur le poste que sur demande de l'utilisateur (lors d'une requete ou d'ouverture d'une table et bien sur selon la capacité du composants)

[okparanoid]

Bonjour a tous,

Je me permets de revenir sur ce fil parce que cette histoire m'intrigue grandement...

Quelqu'un pourrait'il m'expliquer techniquement comment le pilote Jet Engine peut faire pour "fureter" la base (qui consiste en un simple fichier de par exemple 200 Mo !) sans avoir a l'ouvrir et donc la rapatrier integralement depuis une ressource reseau (le disque dur contenant la base) non geree directement depuis le poste qui tente d'y acceder. Cela reste pour moi un enigme !

Merci à celui qui pourra eclairer ma lanterne !

[Rayek]

Bonjour a tous,

Je me permets de revenir sur ce fil parce que cette histoire m'intrigue grandement...

Quelqu'un pourrait'il m'expliquer techniquement comment le pilote Jet Engine peut faire pour "fureter" la base (qui consiste en un simple fichier de par exemple 200 Mo !) sans avoir a l'ouvrir et donc la rapatrier integralement depuis une ressource reseau (le disque dur contenant la base) non geree directement depuis le poste qui tente d'y acceder. Cela reste pour moi un enigme !

Merci à celui qui pourra eclairer ma lanterne !

Je suppose que les drivers vont lires une partie des données dans une zone précise du fichier mdb afin de récupérer les informations de connexion et les tables présentes sans pour autant ramenér les reste de la base de données.

Je pense que tu trouveras plus facilement une réponse en allant directement sur le site de MSDN où il y aura surement l'explication que tu cherches.