J'ai une application Access auqeul va se relie environ 5pers. Elle est en
type data et formulaire dans des fichier MDB séparer(Data sur le serveur et
formulaire sur les postes).
Mais voila, quand 3 ou 4 personnes se branche, c'est tres lent !
J'aimerais avoir des indices pour améliorer cette situation.
J'ai lu dans un post de 3stone qu'il fallait eviter d'avoir des formulaire
rélié directement a une table. Je la relie comment alors ? Je fais un
requette qui contient tout les champs de cette table et relie mon formuliare
a celle-ci ??
Est-ce qu'il y aurait vraiment un gain de performance si j'installe les
table (data) sur Sql Server 2005 Express et que je lie mes table la à la
place ? De cette facon, vais-je avoir des chose a changer dans mes requettes,
code VBA.etc..
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
3stone
Salut,
"Danny" | J'ai une application Access auqeul va se relie environ 5pers. Elle est en | type data et formulaire dans des fichier MDB séparer(Data sur le serveur et | formulaire sur les postes). | Mais voila, quand 3 ou 4 personnes se branche, c'est tres lent !
A condition que le réseau n'est pas l'entonnoir... 3, 4 personnes devraient pouvoir travailler parfaitement.
Mais, il ne suffit pas scinder une base pour qu'elle soit bien construite. Des tables le moins "large" possible, de bonnes clés primaires, des index sur les champs que tu trient ou qui servent au recherches (très important). Ne pas utilise des filtres, sauf sit toutes les données doivent être présentes. Ne pas relier une floppée de tables dans une requête que l'on renseignerait comme source d'un formulaire... En fait, c'est dès l'analyse qu'il faut veiller à minimiser le volume des données à transférer.
| J'aimerais avoir des indices pour améliorer cette situation.
Après coup, il n'y a que les index que l'on peut ajouter facilement, si nécessaire...
| J'ai lu dans un post de 3stone qu'il fallait eviter d'avoir des formulaire | rélié directement a une table. Je la relie comment alors ? Je fais un | requette qui contient tout les champs de cette table et relie mon formuliare | a celle-ci ??
Dangereux de sortir quelques mots hors du contexte... Si je me souviens bien, il était question d'un formulaire lent à s'ouvrir. Ce qui peut arriver lorsque la source d'un formulaire consiste en une requête ou table avec de centaine de milliers de records.
La solution est alors d'ouvrir ce formulaire avec une condition du style : "Select .... Where NoClient 3456" Le numéro client sera évidemment clé primaire !
| Est-ce qu'il y aurait vraiment un gain de performance si j'installe les | table (data) sur Sql Server 2005 Express et que je lie mes table la à la | place ? De cette facon, vais-je avoir des chose a changer dans mes requettes, | code VBA.etc..
Non ! Si tu utilise SqlServer avec des tables attachées, ce sera le moteur JET qui fera le boulot, et lui est serveur de fichiers (et non serveur/client)
Il faudrait alors revoir toute ton appli, les formulaires, utiliser des procédures stockées (qui s'exécutent server side) à la place des requêtes Access...
Il y a tu boulot pour avoir quelque chose de performant... je pense qu'il est plus simple de revoir ton appli actuelle et revisiter les points faibles (et donc lent) pour en corriger les défauts.
"Danny"
| J'ai une application Access auqeul va se relie environ 5pers. Elle est en
| type data et formulaire dans des fichier MDB séparer(Data sur le serveur et
| formulaire sur les postes).
| Mais voila, quand 3 ou 4 personnes se branche, c'est tres lent !
A condition que le réseau n'est pas l'entonnoir... 3, 4 personnes devraient
pouvoir travailler parfaitement.
Mais, il ne suffit pas scinder une base pour qu'elle soit bien construite.
Des tables le moins "large" possible, de bonnes clés primaires, des index
sur les champs que tu trient ou qui servent au recherches (très important).
Ne pas utilise des filtres, sauf sit toutes les données doivent être présentes.
Ne pas relier une floppée de tables dans une requête que l'on renseignerait
comme source d'un formulaire...
En fait, c'est dès l'analyse qu'il faut veiller à minimiser le volume
des données à transférer.
| J'aimerais avoir des indices pour améliorer cette situation.
Après coup, il n'y a que les index que l'on peut ajouter facilement,
si nécessaire...
| J'ai lu dans un post de 3stone qu'il fallait eviter d'avoir des formulaire
| rélié directement a une table. Je la relie comment alors ? Je fais un
| requette qui contient tout les champs de cette table et relie mon formuliare
| a celle-ci ??
Dangereux de sortir quelques mots hors du contexte...
Si je me souviens bien, il était question d'un formulaire lent à s'ouvrir.
Ce qui peut arriver lorsque la source d'un formulaire consiste en
une requête ou table avec de centaine de milliers de records.
La solution est alors d'ouvrir ce formulaire avec une condition
du style : "Select .... Where NoClient 3456"
Le numéro client sera évidemment clé primaire !
| Est-ce qu'il y aurait vraiment un gain de performance si j'installe les
| table (data) sur Sql Server 2005 Express et que je lie mes table la à la
| place ? De cette facon, vais-je avoir des chose a changer dans mes requettes,
| code VBA.etc..
Non !
Si tu utilise SqlServer avec des tables attachées, ce sera le moteur JET
qui fera le boulot, et lui est serveur de fichiers (et non serveur/client)
Il faudrait alors revoir toute ton appli, les formulaires, utiliser des
procédures stockées (qui s'exécutent server side) à la place des
requêtes Access...
Il y a tu boulot pour avoir quelque chose de performant...
je pense qu'il est plus simple de revoir ton appli actuelle et revisiter
les points faibles (et donc lent) pour en corriger les défauts.
"Danny" | J'ai une application Access auqeul va se relie environ 5pers. Elle est en | type data et formulaire dans des fichier MDB séparer(Data sur le serveur et | formulaire sur les postes). | Mais voila, quand 3 ou 4 personnes se branche, c'est tres lent !
A condition que le réseau n'est pas l'entonnoir... 3, 4 personnes devraient pouvoir travailler parfaitement.
Mais, il ne suffit pas scinder une base pour qu'elle soit bien construite. Des tables le moins "large" possible, de bonnes clés primaires, des index sur les champs que tu trient ou qui servent au recherches (très important). Ne pas utilise des filtres, sauf sit toutes les données doivent être présentes. Ne pas relier une floppée de tables dans une requête que l'on renseignerait comme source d'un formulaire... En fait, c'est dès l'analyse qu'il faut veiller à minimiser le volume des données à transférer.
| J'aimerais avoir des indices pour améliorer cette situation.
Après coup, il n'y a que les index que l'on peut ajouter facilement, si nécessaire...
| J'ai lu dans un post de 3stone qu'il fallait eviter d'avoir des formulaire | rélié directement a une table. Je la relie comment alors ? Je fais un | requette qui contient tout les champs de cette table et relie mon formuliare | a celle-ci ??
Dangereux de sortir quelques mots hors du contexte... Si je me souviens bien, il était question d'un formulaire lent à s'ouvrir. Ce qui peut arriver lorsque la source d'un formulaire consiste en une requête ou table avec de centaine de milliers de records.
La solution est alors d'ouvrir ce formulaire avec une condition du style : "Select .... Where NoClient 3456" Le numéro client sera évidemment clé primaire !
| Est-ce qu'il y aurait vraiment un gain de performance si j'installe les | table (data) sur Sql Server 2005 Express et que je lie mes table la à la | place ? De cette facon, vais-je avoir des chose a changer dans mes requettes, | code VBA.etc..
Non ! Si tu utilise SqlServer avec des tables attachées, ce sera le moteur JET qui fera le boulot, et lui est serveur de fichiers (et non serveur/client)
Il faudrait alors revoir toute ton appli, les formulaires, utiliser des procédures stockées (qui s'exécutent server side) à la place des requêtes Access...
Il y a tu boulot pour avoir quelque chose de performant... je pense qu'il est plus simple de revoir ton appli actuelle et revisiter les points faibles (et donc lent) pour en corriger les défauts.
Pour ma part, j'ai basculé plusieurs développement access sous MSDE 2000 (version light de SQL-serveur) gratuit, le résultat est spectaculaire, même avec 30 à 40 personne connectées. La mise en place est assez difficile, avec aussi quelques retouches au niveau des requêtes, mais le résultat en vaut la chandelle.
Voir sous developpez.com
Salut,
"Danny" | J'ai une application Access auqeul va se relie environ 5pers. Elle est en | type data et formulaire dans des fichier MDB séparer(Data sur le serveur et | formulaire sur les postes). | Mais voila, quand 3 ou 4 personnes se branche, c'est tres lent !
A condition que le réseau n'est pas l'entonnoir... 3, 4 personnes devraient pouvoir travailler parfaitement.
Mais, il ne suffit pas scinder une base pour qu'elle soit bien construite. Des tables le moins "large" possible, de bonnes clés primaires, des index sur les champs que tu trient ou qui servent au recherches (très important). Ne pas utilise des filtres, sauf sit toutes les données doivent être présentes. Ne pas relier une floppée de tables dans une requête que l'on renseignerait comme source d'un formulaire... En fait, c'est dès l'analyse qu'il faut veiller à minimiser le volume des données à transférer.
| J'aimerais avoir des indices pour améliorer cette situation.
Après coup, il n'y a que les index que l'on peut ajouter facilement, si nécessaire...
| J'ai lu dans un post de 3stone qu'il fallait eviter d'avoir des formulaire | rélié directement a une table. Je la relie comment alors ? Je fais un | requette qui contient tout les champs de cette table et relie mon formuliare | a celle-ci ??
Dangereux de sortir quelques mots hors du contexte... Si je me souviens bien, il était question d'un formulaire lent à s'ouvrir. Ce qui peut arriver lorsque la source d'un formulaire consiste en une requête ou table avec de centaine de milliers de records.
La solution est alors d'ouvrir ce formulaire avec une condition du style : "Select .... Where NoClient 3456" Le numéro client sera évidemment clé primaire !
| Est-ce qu'il y aurait vraiment un gain de performance si j'installe les | table (data) sur Sql Server 2005 Express et que je lie mes table la à la | place ? De cette facon, vais-je avoir des chose a changer dans mes requettes, | code VBA.etc..
Non ! Si tu utilise SqlServer avec des tables attachées, ce sera le moteur JET qui fera le boulot, et lui est serveur de fichiers (et non serveur/client)
Il faudrait alors revoir toute ton appli, les formulaires, utiliser des procédures stockées (qui s'exécutent server side) à la place des requêtes Access...
Il y a tu boulot pour avoir quelque chose de performant... je pense qu'il est plus simple de revoir ton appli actuelle et revisiter les points faibles (et donc lent) pour en corriger les défauts.
Pour ma part, j'ai basculé plusieurs développement access sous MSDE 2000
(version light de SQL-serveur) gratuit, le résultat est spectaculaire, même
avec 30 à 40 personne connectées.
La mise en place est assez difficile, avec aussi quelques retouches au
niveau des requêtes, mais le résultat en vaut la chandelle.
Voir sous developpez.com
Salut,
"Danny"
| J'ai une application Access auqeul va se relie environ 5pers. Elle est en
| type data et formulaire dans des fichier MDB séparer(Data sur le serveur et
| formulaire sur les postes).
| Mais voila, quand 3 ou 4 personnes se branche, c'est tres lent !
A condition que le réseau n'est pas l'entonnoir... 3, 4 personnes devraient
pouvoir travailler parfaitement.
Mais, il ne suffit pas scinder une base pour qu'elle soit bien construite.
Des tables le moins "large" possible, de bonnes clés primaires, des index
sur les champs que tu trient ou qui servent au recherches (très important).
Ne pas utilise des filtres, sauf sit toutes les données doivent être présentes.
Ne pas relier une floppée de tables dans une requête que l'on renseignerait
comme source d'un formulaire...
En fait, c'est dès l'analyse qu'il faut veiller à minimiser le volume
des données à transférer.
| J'aimerais avoir des indices pour améliorer cette situation.
Après coup, il n'y a que les index que l'on peut ajouter facilement,
si nécessaire...
| J'ai lu dans un post de 3stone qu'il fallait eviter d'avoir des formulaire
| rélié directement a une table. Je la relie comment alors ? Je fais un
| requette qui contient tout les champs de cette table et relie mon formuliare
| a celle-ci ??
Dangereux de sortir quelques mots hors du contexte...
Si je me souviens bien, il était question d'un formulaire lent à s'ouvrir.
Ce qui peut arriver lorsque la source d'un formulaire consiste en
une requête ou table avec de centaine de milliers de records.
La solution est alors d'ouvrir ce formulaire avec une condition
du style : "Select .... Where NoClient 3456"
Le numéro client sera évidemment clé primaire !
| Est-ce qu'il y aurait vraiment un gain de performance si j'installe les
| table (data) sur Sql Server 2005 Express et que je lie mes table la à la
| place ? De cette facon, vais-je avoir des chose a changer dans mes requettes,
| code VBA.etc..
Non !
Si tu utilise SqlServer avec des tables attachées, ce sera le moteur JET
qui fera le boulot, et lui est serveur de fichiers (et non serveur/client)
Il faudrait alors revoir toute ton appli, les formulaires, utiliser des
procédures stockées (qui s'exécutent server side) à la place des
requêtes Access...
Il y a tu boulot pour avoir quelque chose de performant...
je pense qu'il est plus simple de revoir ton appli actuelle et revisiter
les points faibles (et donc lent) pour en corriger les défauts.
Pour ma part, j'ai basculé plusieurs développement access sous MSDE 2000 (version light de SQL-serveur) gratuit, le résultat est spectaculaire, même avec 30 à 40 personne connectées. La mise en place est assez difficile, avec aussi quelques retouches au niveau des requêtes, mais le résultat en vaut la chandelle.
Voir sous developpez.com
Salut,
"Danny" | J'ai une application Access auqeul va se relie environ 5pers. Elle est en | type data et formulaire dans des fichier MDB séparer(Data sur le serveur et | formulaire sur les postes). | Mais voila, quand 3 ou 4 personnes se branche, c'est tres lent !
A condition que le réseau n'est pas l'entonnoir... 3, 4 personnes devraient pouvoir travailler parfaitement.
Mais, il ne suffit pas scinder une base pour qu'elle soit bien construite. Des tables le moins "large" possible, de bonnes clés primaires, des index sur les champs que tu trient ou qui servent au recherches (très important). Ne pas utilise des filtres, sauf sit toutes les données doivent être présentes. Ne pas relier une floppée de tables dans une requête que l'on renseignerait comme source d'un formulaire... En fait, c'est dès l'analyse qu'il faut veiller à minimiser le volume des données à transférer.
| J'aimerais avoir des indices pour améliorer cette situation.
Après coup, il n'y a que les index que l'on peut ajouter facilement, si nécessaire...
| J'ai lu dans un post de 3stone qu'il fallait eviter d'avoir des formulaire | rélié directement a une table. Je la relie comment alors ? Je fais un | requette qui contient tout les champs de cette table et relie mon formuliare | a celle-ci ??
Dangereux de sortir quelques mots hors du contexte... Si je me souviens bien, il était question d'un formulaire lent à s'ouvrir. Ce qui peut arriver lorsque la source d'un formulaire consiste en une requête ou table avec de centaine de milliers de records.
La solution est alors d'ouvrir ce formulaire avec une condition du style : "Select .... Where NoClient 3456" Le numéro client sera évidemment clé primaire !
| Est-ce qu'il y aurait vraiment un gain de performance si j'installe les | table (data) sur Sql Server 2005 Express et que je lie mes table la à la | place ? De cette facon, vais-je avoir des chose a changer dans mes requettes, | code VBA.etc..
Non ! Si tu utilise SqlServer avec des tables attachées, ce sera le moteur JET qui fera le boulot, et lui est serveur de fichiers (et non serveur/client)
Il faudrait alors revoir toute ton appli, les formulaires, utiliser des procédures stockées (qui s'exécutent server side) à la place des requêtes Access...
Il y a tu boulot pour avoir quelque chose de performant... je pense qu'il est plus simple de revoir ton appli actuelle et revisiter les points faibles (et donc lent) pour en corriger les défauts.
"Patrice" | Pour ma part, j'ai basculé plusieurs développement access sous MSDE 2000 | (version light de SQL-serveur) gratuit, le résultat est spectaculaire, même | avec 30 à 40 personne connectées.
30 à 40 personnes "connectées" oui... Mais MS dit bien "optimisé" pour 5 utilisateurs *simultanés*
"Etranglé" serait plus correct, sinon (presque) personne n'acheterait SqlServer ;-)
| La mise en place est assez difficile, avec aussi quelques retouches au | niveau des requêtes, mais le résultat en vaut la chandelle.
Hmmm... celui qui fait des erreurs grossières dans la méthodologie de mise en oeuvre sur Access, ne créera pas un fusée par le simple fait d'utiliser MSDE.
L'avantage indéniable de MSDE est surtout de créer et préparer une application en client/serveur sans avoir besoin après coup de tout revoir. Puisque MSDE est 100% "compatible SqlServer, avec des outils de dévellopement en moins.
De toute façon, celui qui veux se tâter, s'essaye à Northwind.adp qu'il trouve sur son CD... après avoir préinstallé msde.
"Patrice"
| Pour ma part, j'ai basculé plusieurs développement access sous MSDE 2000
| (version light de SQL-serveur) gratuit, le résultat est spectaculaire, même
| avec 30 à 40 personne connectées.
30 à 40 personnes "connectées" oui...
Mais MS dit bien "optimisé" pour 5 utilisateurs *simultanés*
"Etranglé" serait plus correct, sinon (presque) personne n'acheterait SqlServer ;-)
| La mise en place est assez difficile, avec aussi quelques retouches au
| niveau des requêtes, mais le résultat en vaut la chandelle.
Hmmm... celui qui fait des erreurs grossières dans la méthodologie
de mise en oeuvre sur Access, ne créera pas un fusée par le simple
fait d'utiliser MSDE.
L'avantage indéniable de MSDE est surtout de créer et préparer
une application en client/serveur sans avoir besoin après coup
de tout revoir. Puisque MSDE est 100% "compatible SqlServer,
avec des outils de dévellopement en moins.
De toute façon, celui qui veux se tâter, s'essaye à Northwind.adp
qu'il trouve sur son CD... après avoir préinstallé msde.
"Patrice" | Pour ma part, j'ai basculé plusieurs développement access sous MSDE 2000 | (version light de SQL-serveur) gratuit, le résultat est spectaculaire, même | avec 30 à 40 personne connectées.
30 à 40 personnes "connectées" oui... Mais MS dit bien "optimisé" pour 5 utilisateurs *simultanés*
"Etranglé" serait plus correct, sinon (presque) personne n'acheterait SqlServer ;-)
| La mise en place est assez difficile, avec aussi quelques retouches au | niveau des requêtes, mais le résultat en vaut la chandelle.
Hmmm... celui qui fait des erreurs grossières dans la méthodologie de mise en oeuvre sur Access, ne créera pas un fusée par le simple fait d'utiliser MSDE.
L'avantage indéniable de MSDE est surtout de créer et préparer une application en client/serveur sans avoir besoin après coup de tout revoir. Puisque MSDE est 100% "compatible SqlServer, avec des outils de dévellopement en moins.
De toute façon, celui qui veux se tâter, s'essaye à Northwind.adp qu'il trouve sur son CD... après avoir préinstallé msde.
Et 3Stone, j'avais fait a peut pret tous ce que tu me recommandais, Index, etc... Les table sont bien montées, avec des tables de liaison many-to-many... Il doit y avoir sur le reseau au moins 30 personnes, alors le reseaux doit sans doute ne pas aider. On as opter pour une solution Terminal Server.
MErci !!
Salut,
"Patrice" | Pour ma part, j'ai basculé plusieurs développement access sous MSDE 2000 | (version light de SQL-serveur) gratuit, le résultat est spectaculaire, même | avec 30 à 40 personne connectées.
30 à 40 personnes "connectées" oui... Mais MS dit bien "optimisé" pour 5 utilisateurs *simultanés*
"Etranglé" serait plus correct, sinon (presque) personne n'acheterait SqlServer ;-)
| La mise en place est assez difficile, avec aussi quelques retouches au | niveau des requêtes, mais le résultat en vaut la chandelle.
Hmmm... celui qui fait des erreurs grossières dans la méthodologie de mise en oeuvre sur Access, ne créera pas un fusée par le simple fait d'utiliser MSDE.
L'avantage indéniable de MSDE est surtout de créer et préparer une application en client/serveur sans avoir besoin après coup de tout revoir. Puisque MSDE est 100% "compatible SqlServer, avec des outils de dévellopement en moins.
De toute façon, celui qui veux se tâter, s'essaye à Northwind.adp qu'il trouve sur son CD... après avoir préinstallé msde.
Et 3Stone, j'avais fait a peut pret tous ce que tu me recommandais, Index,
etc...
Les table sont bien montées, avec des tables de liaison many-to-many...
Il doit y avoir sur le reseau au moins 30 personnes, alors le reseaux doit
sans doute ne pas aider.
On as opter pour une solution Terminal Server.
MErci !!
Salut,
"Patrice"
| Pour ma part, j'ai basculé plusieurs développement access sous MSDE 2000
| (version light de SQL-serveur) gratuit, le résultat est spectaculaire, même
| avec 30 à 40 personne connectées.
30 à 40 personnes "connectées" oui...
Mais MS dit bien "optimisé" pour 5 utilisateurs *simultanés*
"Etranglé" serait plus correct, sinon (presque) personne n'acheterait SqlServer ;-)
| La mise en place est assez difficile, avec aussi quelques retouches au
| niveau des requêtes, mais le résultat en vaut la chandelle.
Hmmm... celui qui fait des erreurs grossières dans la méthodologie
de mise en oeuvre sur Access, ne créera pas un fusée par le simple
fait d'utiliser MSDE.
L'avantage indéniable de MSDE est surtout de créer et préparer
une application en client/serveur sans avoir besoin après coup
de tout revoir. Puisque MSDE est 100% "compatible SqlServer,
avec des outils de dévellopement en moins.
De toute façon, celui qui veux se tâter, s'essaye à Northwind.adp
qu'il trouve sur son CD... après avoir préinstallé msde.
Et 3Stone, j'avais fait a peut pret tous ce que tu me recommandais, Index, etc... Les table sont bien montées, avec des tables de liaison many-to-many... Il doit y avoir sur le reseau au moins 30 personnes, alors le reseaux doit sans doute ne pas aider. On as opter pour une solution Terminal Server.
MErci !!
Salut,
"Patrice" | Pour ma part, j'ai basculé plusieurs développement access sous MSDE 2000 | (version light de SQL-serveur) gratuit, le résultat est spectaculaire, même | avec 30 à 40 personne connectées.
30 à 40 personnes "connectées" oui... Mais MS dit bien "optimisé" pour 5 utilisateurs *simultanés*
"Etranglé" serait plus correct, sinon (presque) personne n'acheterait SqlServer ;-)
| La mise en place est assez difficile, avec aussi quelques retouches au | niveau des requêtes, mais le résultat en vaut la chandelle.
Hmmm... celui qui fait des erreurs grossières dans la méthodologie de mise en oeuvre sur Access, ne créera pas un fusée par le simple fait d'utiliser MSDE.
L'avantage indéniable de MSDE est surtout de créer et préparer une application en client/serveur sans avoir besoin après coup de tout revoir. Puisque MSDE est 100% "compatible SqlServer, avec des outils de dévellopement en moins.
De toute façon, celui qui veux se tâter, s'essaye à Northwind.adp qu'il trouve sur son CD... après avoir préinstallé msde.
