[AC-2010] Perfomances tables liées en Odbc Oracle

[thanae]

Bonjour à tous,

Ma question étant difficile a expliquer du fait de la complexité de mon application, je vais d'abord présenter le contexte pour ensuite en venir à mon problème.

Je développe depuis qqs années une application fait en Access qui a pris au fil du temps des proportions assez importantes.
Quand je l'ai reprise il y a qqs années elle était petite encore (vers 2000) faite par un utlisateur avertit. Je l'ai passée en vers.2003 en modifiant complètement la structure de ces tables en vue d'également pouvoir plutard les migrer vers Oracle vu que les tables allaient rapidement grossir (en moyenne de 1.000 enreg./an pour les tables principales).

Entretemps j'ai développer de plus en plus de fonctionnalités (interaction avec Outlook pour la génération de mail personnalisés, mailmerges de document avec Word, Export de tableau vers Excel et gestion de documents par fso).

Lorsqu'on a réussi a avoir un schema dans Oracle et migrer toutes les tables, j'ai constater un énorme ralentissement de l'application du faite que les tables était en odbc et non plus en JetLink. Donc j'ai du tout réanalyser et retravailler en utilisant les tables que pour les forms d'encodage et des vues sous Oracle liées pour les listes et autres, avec un minimum de queries Access.

Mais, comme pour tout, les utilisateur voulant toujours plus de fonctionnalités , le front-end devenait trop volumineux et compliquer, j'ai donc décider de le séparer en plusieurs parties:
- Module de démarrage(le 1er front-end): form d'ouverture pour détection des infos utilisateur et chargement des classes de variables globals et fonctions publiques à toute l'appli. Celui-ci ouvre le
- Module Main, qui contient l'écran principal contenant les boutons et listes de sélections. Celui-ci peut donc appeler des forms ou repports dans les autres modules complémentaires que j'ai scinder par domaines d'activité.
- Module de Repportings
- Module de Graphics
- Module pour un sous-secteur d'activités (mais hyper complexe )
- Module d'utilitaires divers.
Tous les modules sont en mde et référencés au démarage de l'appli front-end qui lui est en mdb. Ceci permet de ne pas devoir tout recompiler si seul un changement a été fait dans un seule module.

Maintenant mon problème est que je suis obligée d'avoir toutes les tables, ainsi que le vues, liées dans le front-end en plus de les avoir dans les différents modules du à que je les ouvre également en VBA via recordset et que CurrentDb prends toujours dans le front-end même si c'est appeler d'un autre module.
Tout cela fait que le démarrage de l'appli devient de plus en plus lent et que les filtres pour les listes sont à chaque chargement aussi très lent.

J'ai trouvé en cherchant sur le net qu'Oracle préconisait pour les version précédantes de supprimer les connexions via l'Engine MsJet et de faire des connexion en DirectOdbc via le code. Cette solution est encore pire, je l'ai expérimenter qd nous avons migrer sur Oracle, je pensais aussi que ce serait mieux, mais c'est une vrai catastrophe pour les forms d'encodage et même pour les reporting, c'est pour cela que j'ai du retravailler complètement l'appli.

Depuis nous avons su que dans qqs mois nous allons migrer le parc avec Windows 7(x64) et Office 2010 (x32). Ce qui m'a fait réagir et donc chercher pour savoir si cette nouvelle version pouvait nous apporter une amélioration.
Certain disent que l'Engine MsJet fonctionne différemment car utiliserait une autre technologie.
J'ai donc migrer toute l'application sur Access 2010 sur une machine de test et refait tout les liens odbc.
Résultat = AUCUN!

Alors, ma question est : Est-ce quelqu'un aurait à me suggérer autre chose ou bien aurait une idées plus avancées sur les possibilités ou adaptation que l'on pourrait faire avec cette nouvelle version?

Je remercie d'avance ceux-ci qui auront eu le courage de lire tout mon post car je reconnais que c'est long a expliquer et peut-être pas évident à le comprendre.

Thanae

[loufab]

Bonjour,

Ce qui est certain c'est que Oracle est plus lent que Jet et/ou Sql Server.

Regarde le tuto sur l'optimisation sur ma page perso.

http://loufab.developpez.com/tutorie.../optimisation/

Les indexes peuvent améliorer le problème, en excés cela peut l'accentuer.

A éviter :
Les recordset globaux, mieux vaut stocker un id qu'un recordset.
Les vues, recordset, requetes ouvertes sans where restrictif. Idem pour les listes et formulaires, jamais de table dans la source, toujours une requete.

Regarde le tuto il y a d'autres conseils.

Cordialement,

[thanae]

Bonjour,

Merci bvp loufab pour ta réponse et tes conseils.
J'avais déjà été sur ta page et suivi ton tuto sur l'optimisation,cela m'avais bcp servi et je l'ai même appliqué lorsque j'avais du tout refaire en passant sous Oracle.

En faite, c'est plutot lorsqu'on ouvre l'application que c'est très lent (+/-1min). J'avais lu que c'est parce que Access charge toutes les tables et vues liées en odbc en mémoire au démarage. Donc le front-end lui, contenant tout forcément est très lourd, ainsi que chaque fois que je fait appel à un form ou report vers un autre module.
Après dès que c'est ouvert, cela vas très vite, car comme tu le conseils, je n'ouvre pas tous les records et champs, que le nécessaire et j'appelle toujours via la clé unique qui est la même dans toutes les table afin d'optimiser et pas alourdir et permet des liaisons simplifiées, seule 2 tables sont à double clé. J'ai également mis que certains champs indexés en Oracle pour que les vues sont rapides, mais ne sont pas repris dans Access afin de ne pas alourdir.

D'où donc ma question, en Access 2010, ne peut-on pas ouvrir les tables et vues en autre chose qu'odbc traditionnel, qqun m'avait parlé que Microsoft intégrait la technologie java dans ses nouveaux produits 2010, est-ce vrai ou intoxe?

Merci

Thanae

[thanae]

Bonjour tout le monde,

Après de recherches assez poussées, j'ai enfin trouvé une partie de solution, que je partage avec vous pour ceux à qui ca pourrait intéresser.

Cette solution me permet de ne plus devoir lier aucune de mes tables ou vue Oracle pour toute la partie appeler via Vba en Recordstet :
- dans ma partie principale "Backstage" où se trouve uniquement des fonctions et procédures globales, ainsi que le form d'ouverture, je déclare une nouvelle DB dans le workspace de l'application:

Public dbOra as DAO.Database

- dans le form de démarage du "Backstage"

Set dbOra = Application.DBEngine(0).OpenDatabase("", False, False, ODBC;DRIVER={Oracle};UID=XXXX;DBQ=MyDb;SERVER=MyServer;PWD=XXXX)

Ceci permet d'avoir une db ouverte dans le workspace de l'application contenant tout les liens des table et vues du schema Oracle sans que l'on doivent les nommés un par une.
- dans les autres ".mde/.accde" les forms et repports appelés dans la fonction d'appel des forms et repports locales:

Public Function MainOpenForm(FormName As String, _
Optional View As AcFormView = acNormal, _
Optional FilterName As String, _
Optional WhereCondition As String, _
Optional DataMode As AcFormOpenDataMode = acFormPropertySettings, _
Optional WindowMode As AcWindowMode = acWindowNormal, _
Optional OpenArgs As String)

Set dbOra = Application.DBEngine(0).Databases(1)

DoCmd.OpenForm FormName, View, FilterName, WhereCondition, DataMode, WindowMode, OpenArgs

End Function
' idem pour les Repports
'...

Après il suffit de remplacer tout les CurrentDb en dbOra:

Dim rst as DAO.Recordset
Set rst = dbOra.OpenRecordset(StrSql ou TableName, Type, Options, LockEdit)

Attention le StrSql devra être le Sql Oracle et non plus du Sql Access!

J'ai constaté une nette amélioration de la performance de l'application , plus de mise en cache des tables par Access et donc les queries se font directement sur le serveur.

Maintenant vous vous dites, pourquoi DAO et non ADO? Et bien, j'ai jamais trop apprécier la complexité des déclarations d'ADO et je ne voyait pas une réelle différence performance entre les deux.
Pour la version 2010, ils ont fort améliorer DAO, sauf que les connections ODBCDirect n'est plus pris en charge, mais avec cette solution, je trouve que c'est même plus facile et au final fait +/- la même chose.

Cette solution est donc très bien pour le SqlDirect dans le code VBA, mais il me reste pour la partie datasource/rowsource des objets (Forms, listbox, combobox, sous-forms, etc..).

J'ai vu que l'on peut déclarer dans un query:
- le SourceConnectStr, pour indiquer un ODBC DSN, donc du Sql en Pass-through, mais cela recréé pour chaque query une nouvelle connexion vers le serveur;
- la SourceDatabase, par défaut c'est (Current), ou un chemin de fichier. J'ai essayer de mettre le nom de mon dbOra, mais ne veux pas le reconnaitre et le prend pour un nom de ficher.

Donc ma question maintenant est, comment peut-on l'indiquer (dbOra contenant déjà toutes les tables d'Oracle) à tous mes queries (enregistrés ou pas)?

Je vous remercie d'avance de vos conseils ou idées
Thanae