Très grande lenteur / blocage ouverture multi-formulaire avec données d'une base ORACLE

[hakkai44]

Bonjour,

J'ai un problème un peu particulier, j'espère que je le post au bon endroit.

J'ai une application Access qui à son ouverture demande de sélectionner un client, et quand je le valide m'ouvre un "mega-formulaire" qui récapitule toutes les actions du clients (il m'ouvre le formulaire principal dans lequel se trouve une vingtaine de sous-formulaire attachés au client).
Jusqu'à présent, la base de données "attaquée" par l'application était aussi une base Access, au travers de tables liées. Depuis quelques semaines, j'ai migré les tables de cette base Access sur une base Oracle 8i.
Dans la majorité des cas, l'ouverture du fomulaire client est OK (un peu plus lent - 10-15 secondes - mais rien de rédibitoire).
Par contre, j'ai plusieurs fois par jour, un plantage (ou plutôt un "freeze" - prise des ressources à 100% de la machine) d'Access qui refuse de m'ouvrir le formulaire, et que je ne peux plus fermer sauf en faisant "Fin de tâche" dans le gestionnaire des tâches, ce qui extrêmement pénible pour les utilisateurs.

Est ce que quelqu'un pourrait me donner des pistes sur cet "emballement" d'Access? Existe t'il un moyen d'éviter cela? Et si ce n'est pas possible, est ce qu'il existe (en VBA ou autre) un moyen de dire à Access d'arrêter sa requête pour qu'il arrête de freezer, sans être obligé de faire Ctrl+Atl+Supp

Par avance merci de vos conseils

Hakkai44

[marot_r]

Est-ce que tes cas qui gélent sont très différents de ceux qui ne gélent pas ?

Que dit la BD Oracle quand Access est gelé ? Verrouillages des tables ? Conflit d'accès ? Nombre d'utilisateurs simultanés ? Utilisation des ressources par sessions ?

Que dit le trafic sur le réseau ? Tu n'as pas un back-up ou un gros traitement en cours qui 'pomperait' toute tes ressources réseau ?

Si tu as des problèmes de performance, un truc très efficace est de migrer tes requêtes d'access vers Oracle. J'avais un cas où mon formulaire prenait 40s à ouvrir après migration réecriture dans Oracle de la requête je suis passé à 3s. Évidement cela complique la maintenance mais généralement le jeu en vaut la chandelle.

Autre idée : ne pas charger les données des sous-formulaires si ils ne sont pas visibles (ex : dans des tab différents). Pour cela il faut supprimer la source de données du sous-form et la mettre par code au moment où on demande l'affichage. Cela induit un petit délais mais évite de ralentir tout le formulaire.

A+

[hakkai44]

Bonjour, et merci pour cette réponse.

Il n'y a pas de différence entre les cas qui gèlent et les autres. Un cas qui gèle, après plantage du programme et redémarrage, va s'ouvrir normalement.

Je suis pas aller voir dans la base ORACLE pour voir ce qui se passe quand cela gèle (je suis encore assez novice en ORACLE). Quelles sont les lignes de commande SQL me permettant de voir les opérations que vous m'avez cités?

Compte tenu du caractère aléatoire (quelque soit le moment de la journée), je ne pense pas qu'il y ait de gros traitement en cours sur le réseau. Il semblerait plutôt que cela soit lié au nombre de dossiers ouvert avec l'application (plus on ouvre de dossiers différents depuis l'ouverture de l'application, plus le risque de plantage est important).

La re-écriture dans ORACLE des requêtes me parait très lourd, d'autant plus que ce programme est un programme régional qui fonctionne soit avec un source Access, soit une source Oracle selon les départements.

Pour la dernière solution, je vais y travailler, voir si cela reste suffisamment fluide pour l'utilisateur.

Encore merci pour ces réponses!

[marot_r]

Désolé je débute moi-même en Oracle et je sais seulement que Oracle peut donner ce genre d'info mais pas comment :-(.

Il y a un formum Oracle sur ce site, tu pourrais leur soumettre ta question à propos de ces outils.

Tu pourrais aussi voir comment tes requêtes access sont montées. Access a tendance à remonter toutes les données sur le poste client pour ensuite faire les caculs. Si tu as beaucoup de données cela peut induire beaucoup de trafic sur le réseau et dégrader les performances. En repensant ton SQL (ex : ne prende que les champs dont tu as besoin tu peux réduire la temps d'éxécution) mais comme tu dis que pour certains c'est correct, le SQL n'est probablement pas en cause.

A+

[hakkai44]

Bonjour,

Et oui, c'est le souci quand on est sur un problème entre deux technos (Access et ORACLE), on ne sait jamais sur quel forum écrire

Mes requêtes sont déjà réduites au minimum, et j'ai mis en place quelques tables "cache" dans le programme Access pour réduire le temps de chargement (j'étais ainsi passé de 45 à 15 secondes pour le cas général).
Par ailleurs, tous les dossiers se sont au moins ouverts un fois normalement, c'est généralement au bout de 4 ou 5 ouverture de dossiers clients sans avoir refermé l'application qu'elle plante. C'est pour cela que c'est assez incompréhensible. Si comme si les requêtes se chargeaient en mémoire au fur à mesure de leurs chargement sans se décharger, et qu'au bout d'un moment elles saturaient la mémoire et que le programme freeze.

Je vais essayer la solution du chargement de la source des sous-formulaire avec un module VBA.

[marot_r]

As-tu regardé au niveau du fichier d'échange de windows (swap file) ? Si ta mémoire 'gonfle' Windows va chercher de l'espace sur disque et cela prend beaucoup de temps CPU.

A+