Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Applications Microsoft Office Access Access avec des tables sql

Access avec des tables sql

7 réponses
Avatar
Seigre.alexandre
Bonjour,

Voila je voulais savoir si cela aller jouer en rapidité d'execution si je
stocke mes tables dans SQL serveur et que j'utilise l'interface des
formulaires access

Car en fait actuellement j'ai une BDD access en réseau qui est trés longue
en tps d'execution

Cela changera t il qq chose??

Et surtout comment dois je m'y prendre?

Merci d'avance
Signaler un problème avec ce contenu

7 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Avatar
NewsUser
Bjr,

Les problemes de lenteur sont surtout du à la facon dont les developpeurs
ont concus le programme. Pas de relation d'approbation, pas d'index ou mal
positionné, champs pas ou mal dimensionnés ...
Mais le pire c'est les requetes : requetes de requetes, liaisons réalisées
dans la requete plutot qu' au niveau des relations, etc ...
Si l'appli est sur un serveur la premiere des choses à faire est de
rapatrier en local sur chaque PC la base qui contient la structure et de ne
laisser sur le serveur que celle qui contient les données.

Sql serveur est un meilleur serveur de BD avec des fonctions qui n'existent
pas sous Access, mais plutot que de t'embarquer dans un conversion de base
pas toujours trés simple et un l'achat d'un gros serveur commence par
optimiser l'existant.
Pallier à des erreures de dev par une machine puissante est une solution
attractive mais c'est pas ca qui rendra l'appli plus efficace

@+

""
a écrit dans le message de news:

Bonjour,

Voila je voulais savoir si cela aller jouer en rapidité d'execution si je
stocke mes tables dans SQL serveur et que j'utilise l'interface des
formulaires access

Car en fait actuellement j'ai une BDD access en réseau qui est trés longue
en tps d'execution

Cela changera t il qq chose??

Et surtout comment dois je m'y prendre?

Merci d'avance



Avatar
The_Team
Je confirme.

Avant de se lancer dans des applications "mixtes", il faudrait voir déjà à
améliorer l'existant.

Les lenteurs en réseau peuvent toujours trouver une solution, il faudrait
avoir plus d'éléments pour apporter
des directions...

--
Lucky_Team

http://www.access-developpement.com


"NewsUser" a écrit dans le message de news:

Bjr,

Les problemes de lenteur sont surtout du à la facon dont les developpeurs
ont concus le programme. Pas de relation d'approbation, pas d'index ou mal
positionné, champs pas ou mal dimensionnés ...
Mais le pire c'est les requetes : requetes de requetes, liaisons réalisées
dans la requete plutot qu' au niveau des relations, etc ...
Si l'appli est sur un serveur la premiere des choses à faire est de
rapatrier en local sur chaque PC la base qui contient la structure et de
ne laisser sur le serveur que celle qui contient les données.

Sql serveur est un meilleur serveur de BD avec des fonctions qui
n'existent pas sous Access, mais plutot que de t'embarquer dans un
conversion de base pas toujours trés simple et un l'achat d'un gros
serveur commence par optimiser l'existant.
Pallier à des erreures de dev par une machine puissante est une solution
attractive mais c'est pas ca qui rendra l'appli plus efficace

@+

""
a écrit dans le message
de news:
Bonjour,

Voila je voulais savoir si cela aller jouer en rapidité d'execution si je
stocke mes tables dans SQL serveur et que j'utilise l'interface des
formulaires access

Car en fait actuellement j'ai une BDD access en réseau qui est trés
longue
en tps d'execution

Cela changera t il qq chose??

Et surtout comment dois je m'y prendre?

Merci d'avance







Avatar
Bruno_gau
C'est certain qu'il faut faire de l'optimisation en ajoutant des indexes, en
optimisant les requêtes, les formulaires. C'est la première solution, mais
ça ne règle pas tous les problèmes, dans mon cas j'ai du utiliser un serveur
SQL parce que j'avais trop de données et trop d'utilisateurs. J'avais besoin
aussi d'une application assez rapide. J'ai eu très peu de problèmes et des
gains de performance assez significatif. Mais j'ai travaillé fort pour
optimiser mon application avant de passé a un serveur SQL.


Je confirme.

Avant de se lancer dans des applications "mixtes", il faudrait voir déjà à
améliorer l'existant.

Les lenteurs en réseau peuvent toujours trouver une solution, il faudrait
avoir plus d'éléments pour apporter
des directions...

--
Lucky_Team

http://www.access-developpement.com


"NewsUser" a écrit dans le message de news:

Bjr,

Les problemes de lenteur sont surtout du à la facon dont les developpeurs
ont concus le programme. Pas de relation d'approbation, pas d'index ou mal
positionné, champs pas ou mal dimensionnés ...
Mais le pire c'est les requetes : requetes de requetes, liaisons réalisées
dans la requete plutot qu' au niveau des relations, etc ...
Si l'appli est sur un serveur la premiere des choses à faire est de
rapatrier en local sur chaque PC la base qui contient la structure et de
ne laisser sur le serveur que celle qui contient les données.

Sql serveur est un meilleur serveur de BD avec des fonctions qui
n'existent pas sous Access, mais plutot que de t'embarquer dans un
conversion de base pas toujours trés simple et un l'achat d'un gros
serveur commence par optimiser l'existant.
Pallier à des erreures de dev par une machine puissante est une solution
attractive mais c'est pas ca qui rendra l'appli plus efficace

@+

""
a écrit dans le message
de news:
Bonjour,

Voila je voulais savoir si cela aller jouer en rapidité d'execution si je
stocke mes tables dans SQL serveur et que j'utilise l'interface des
formulaires access

Car en fait actuellement j'ai une BDD access en réseau qui est trés
longue
en tps d'execution

Cela changera t il qq chose??

Et surtout comment dois je m'y prendre?

Merci d'avance












Avatar
Bruno_gau
Je veux ajouter que si la version Access 2002 est disponible, il est possible
compilé la partie application en .mde, ce qui donne certains gains de
performance dans cetains cas.


C'est certain qu'il faut faire de l'optimisation en ajoutant des indexes, en
optimisant les requêtes, les formulaires. C'est la première solution, mais
ça ne règle pas tous les problèmes, dans mon cas j'ai du utiliser un serveur
SQL parce que j'avais trop de données et trop d'utilisateurs. J'avais besoin
aussi d'une application assez rapide. J'ai eu très peu de problèmes et des
gains de performance assez significatif. Mais j'ai travaillé fort pour
optimiser mon application avant de passé a un serveur SQL.


Je confirme.

Avant de se lancer dans des applications "mixtes", il faudrait voir déjà à
améliorer l'existant.

Les lenteurs en réseau peuvent toujours trouver une solution, il faudrait
avoir plus d'éléments pour apporter
des directions...

--
Lucky_Team

http://www.access-developpement.com


"NewsUser" a écrit dans le message de news:

Bjr,

Les problemes de lenteur sont surtout du à la facon dont les developpeurs
ont concus le programme. Pas de relation d'approbation, pas d'index ou mal
positionné, champs pas ou mal dimensionnés ...
Mais le pire c'est les requetes : requetes de requetes, liaisons réalisées
dans la requete plutot qu' au niveau des relations, etc ...
Si l'appli est sur un serveur la premiere des choses à faire est de
rapatrier en local sur chaque PC la base qui contient la structure et de
ne laisser sur le serveur que celle qui contient les données.

Sql serveur est un meilleur serveur de BD avec des fonctions qui
n'existent pas sous Access, mais plutot que de t'embarquer dans un
conversion de base pas toujours trés simple et un l'achat d'un gros
serveur commence par optimiser l'existant.
Pallier à des erreures de dev par une machine puissante est une solution
attractive mais c'est pas ca qui rendra l'appli plus efficace

@+

""
a écrit dans le message
de news:
Bonjour,

Voila je voulais savoir si cela aller jouer en rapidité d'execution si je
stocke mes tables dans SQL serveur et que j'utilise l'interface des
formulaires access

Car en fait actuellement j'ai une BDD access en réseau qui est trés
longue
en tps d'execution

Cela changera t il qq chose??

Et surtout comment dois je m'y prendre?

Merci d'avance














Avatar
3stone
Salut,

"Bruno_gau"
| Je veux ajouter que si la version Access 2002 est disponible, il est possible
| compilé la partie application en .mde, ce qui donne certains gains de
| performance dans cetains cas.


Pourquoi 2002 ?
Les autres versions ne le permettraient pas, selon toi ?

Quant aux performances; le temps de compilation d'une requête ne représente
rien par rapport à une requête ou une ouverture de formulaire qui se traine...


--
A+
Pierre (3stone) Access MVP
Perso: http://www.3stone.be/
Conseils MPFA: http://www.mpfa.info/
Avatar
Bruno_gau
Sur mon poste, par défaut les bases de données ce crée en format Access 2000.
Si je vais à la fonction pour compiler la base de données en MDE, le bouton
n'est pas disponible. Si je convertie ma BD en format Access 2002, le bouton
de compilation est disponible. C'est simplement pour ça que je dis que la
compilation est disponible en 2002, mais franchement je ne connais pas les
versions antérieurs.

Pour ce qui est de l'effet de la compilation, cela ne donne aucun gain dans
le cas des requêtes. Cela permet simplement une exécution légèrement plus
rapide du code de l'application puisqu'il n'est plus interprété, mais
compilé. Comme le code, les formulaires, les rapports, les macros et les
modules ne sont plus modifiables dans une version compilé, il y a une petit
gains de performance puisque l'application n'est pas obligé de valider le
code à chaque fois puisqu'il ne change pas.


Salut,

"Bruno_gau"
| Je veux ajouter que si la version Access 2002 est disponible, il est possible
| compilé la partie application en .mde, ce qui donne certains gains de
| performance dans cetains cas.


Pourquoi 2002 ?
Les autres versions ne le permettraient pas, selon toi ?

Quant aux performances; le temps de compilation d'une requête ne représente
rien par rapport à une requête ou une ouverture de formulaire qui se traine...


--
A+
Pierre (3stone) Access MVP
Perso: http://www.3stone.be/
Conseils MPFA: http://www.mpfa.info/





Avatar
3stone
Salut,

"Bruno_gau"
| Sur mon poste, par défaut les bases de données ce crée en format Access 2000.
| Si je vais à la fonction pour compiler la base de données en MDE, le bouton
| n'est pas disponible. Si je convertie ma BD en format Access 2002, le bouton
| de compilation est disponible. C'est simplement pour ça que je dis que la
| compilation est disponible en 2002, mais franchement je ne connais pas les
| versions antérieurs.

Chaque version d'Access ne peut créer la MDE que dans "sa" version.


| Pour ce qui est de l'effet de la compilation, cela ne donne aucun gain dans
| le cas des requêtes. Cela permet simplement une exécution légèrement plus
| rapide du code de l'application puisqu'il n'est plus interprété, mais
| compilé. Comme le code, les formulaires, les rapports, les macros et les
| modules ne sont plus modifiables dans une version compilé, il y a une petit
| gains de performance puisque l'application n'est pas obligé de valider le
| code à chaque fois puisqu'il ne change pas.


Qui raconte de telles choses ??

MDE ou MDB, le code n'est pas plus compilé dans l'une que dans l'autre !
Avant l'exécution du code, Access le compile *s'il ne l'est pas encore*
mais, une fois que la base à tourné, elle n'est plus recompilée !!!
Sauf si tu remodifie le code, bien sûr.

Pour t'en rendre compte, modifie une simple sub et exécute. Retourne voir
ta sub et tu verras qu'elle est compilée et elle le reste !
C'est d'ailleurs pourquoi, en cas de problème dans le code compilé, il est
nécessaire de faire un "/décompile" pour virer tout, sauf le texte canonique.

Le "petit" gain de performance qu'il peut y avoir est dû à la taille plus
faible d'une application MDE.

PS: Compilé est un mot largement excessif, car c'est ce qui à fait croire
(et continue faire croire) que l'on peut créer un .exe !!!


--
A+
Pierre (3stone) Access MVP
Perso: http://www.3stone.be/
Conseils MPFA: http://www.mpfa.info/