charger une grosse table à partir d'un réseau d'entreprise
6 réponses
oualaléreur
Bonjour
Je dispose d'une base de donn=E9es en deux parties. Une biblioth=E8que
des tables d'un c=F4t=E9 et le reste de l'autre. On veut utiliser le
tout sur un r=E9seau d'entreprise (sans rien copier en local. Les
fain=E9ants !) Le probl=E8me est le temps prohibitif =E0 l'ouverture du
formulaire principal. Il dispose en effet d'un sous-formulaire qui
requi=E8re le chargement de 2 tables dont une de 4064 enregistrements =E0
23 champs.
Y a-t-il une solution pour optimiser ce temps de chargement (de presque
une minute je crois !), et peut-on afficher le formulaire *puis*
effectuer le chargement de la table ?
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,
"oualaléreur" Je dispose d'une base de données en deux parties. Une bibliothèque des tables d'un côté et le reste de l'autre. On veut utiliser le tout sur un réseau d'entreprise (sans rien copier en local. Les fainéants !) Le problème est le temps prohibitif à l'ouverture du formulaire principal. Il dispose en effet d'un sous-formulaire qui requière le chargement de 2 tables dont une de 4064 enregistrements à 23 champs. Y a-t-il une solution pour optimiser ce temps de chargement (de presque une minute je crois !), et peut-on afficher le formulaire *puis* effectuer le chargement de la table ?
Ce que tu décris est tout simplement la pire des solutions ! Vouloir améliorer dans ces conditions....
Mais, il serait déjà simple de NE PAS charger les quelques milliers d'enregistrement en ajoutant une simple condition à la source.
"oualaléreur" Je dispose d'une base de données en deux parties. Une bibliothèque
des tables d'un côté et le reste de l'autre. On veut utiliser le
tout sur un réseau d'entreprise (sans rien copier en local. Les
fainéants !) Le problème est le temps prohibitif à l'ouverture du
formulaire principal. Il dispose en effet d'un sous-formulaire qui
requière le chargement de 2 tables dont une de 4064 enregistrements à
23 champs.
Y a-t-il une solution pour optimiser ce temps de chargement (de presque
une minute je crois !), et peut-on afficher le formulaire *puis*
effectuer le chargement de la table ?
Ce que tu décris est tout simplement la pire des solutions !
Vouloir améliorer dans ces conditions....
Mais, il serait déjà simple de NE PAS charger les quelques milliers
d'enregistrement en ajoutant une simple condition à la source.
"oualaléreur" Je dispose d'une base de données en deux parties. Une bibliothèque des tables d'un côté et le reste de l'autre. On veut utiliser le tout sur un réseau d'entreprise (sans rien copier en local. Les fainéants !) Le problème est le temps prohibitif à l'ouverture du formulaire principal. Il dispose en effet d'un sous-formulaire qui requière le chargement de 2 tables dont une de 4064 enregistrements à 23 champs. Y a-t-il une solution pour optimiser ce temps de chargement (de presque une minute je crois !), et peut-on afficher le formulaire *puis* effectuer le chargement de la table ?
Ce que tu décris est tout simplement la pire des solutions ! Vouloir améliorer dans ces conditions....
Mais, il serait déjà simple de NE PAS charger les quelques milliers d'enregistrement en ajoutant une simple condition à la source.
Ce que tu décris est tout simplement la pire des solutions ! Vouloir améliorer dans ces conditions....
Mais, il serait déjà simple de NE PAS charger les quelques milliers d'enregistrement en ajoutant une simple condition à la source.
Du style: Select .... from ... Where NoClient = 1
Après avoir consulté les archives, j'ai bien compris qu'il était indispensable d'opérer en local avec des tables liées. Aussi il y a d'exellents conseils ici : http://groups.google.fr/group/microsoft.public.fr.access/browse_thread/thre ad/d6141c3c13690ad3/7610d7fdcce35b96?q=r%C3%A9seau&rnum#7610d7fdcce3 5b96 et ici : http://groups.google.fr/group/microsoft.public.fr.access/browse_thread/thre ad/f242f9f07aa4566d/55a398a819b8488e?q=r%C3%A9seau&rnum'#55a398a819b8 488e
Mais j'aimerais quand même essayer ton astuce. Qu'entends-tu par "À la source" ?
Ce que tu décris est tout simplement la pire des solutions !
Vouloir améliorer dans ces conditions....
Mais, il serait déjà simple de NE PAS charger les quelques milliers
d'enregistrement en ajoutant une simple condition à la source.
Du style:
Select .... from ... Where NoClient = 1
Après avoir consulté les archives, j'ai bien compris qu'il était
indispensable d'opérer en local avec des tables liées.
Aussi il y a d'exellents conseils ici :
http://groups.google.fr/group/microsoft.public.fr.access/browse_thread/thre ad/d6141c3c13690ad3/7610d7fdcce35b96?q=r%C3%A9seau&rnum=19#7610d7fdcce3 5b96
et ici :
http://groups.google.fr/group/microsoft.public.fr.access/browse_thread/thre ad/f242f9f07aa4566d/55a398a819b8488e?q=r%C3%A9seau&rnum=27#55a398a819b8 488e
Mais j'aimerais quand même essayer ton astuce. Qu'entends-tu par "À
la source" ?
Ce que tu décris est tout simplement la pire des solutions ! Vouloir améliorer dans ces conditions....
Mais, il serait déjà simple de NE PAS charger les quelques milliers d'enregistrement en ajoutant une simple condition à la source.
Du style: Select .... from ... Where NoClient = 1
Après avoir consulté les archives, j'ai bien compris qu'il était indispensable d'opérer en local avec des tables liées. Aussi il y a d'exellents conseils ici : http://groups.google.fr/group/microsoft.public.fr.access/browse_thread/thre ad/d6141c3c13690ad3/7610d7fdcce35b96?q=r%C3%A9seau&rnum#7610d7fdcce3 5b96 et ici : http://groups.google.fr/group/microsoft.public.fr.access/browse_thread/thre ad/f242f9f07aa4566d/55a398a819b8488e?q=r%C3%A9seau&rnum'#55a398a819b8 488e
Mais j'aimerais quand même essayer ton astuce. Qu'entends-tu par "À la source" ?
david
salut, à la source sous-entend : ne charger que ce qui est nécessaire, bon conseil, mais le problème est que ACCESS n'est pas un serveur de base de données...
Les requêtes (type select * form maTable where...) sont exécutées localement => la table 'maTable' est donc transférée entièrement au client qui effectue lui-même le filtrage...
Cela ne va donc rien changer (ne temps de réponse)...
Dans ton cas, il est nécessaire de placer ces données 'bibliothèque' en local sur chaque poste. Pour ce faire, je te conseil d'utiliser la réplication de base. Comme ça si tu modifies te bibliothèque sur un poste, le système va répercuter de lui-même (tous les x temps) les modifications...
Sinon, si tu veux vraiement utiliser une bibliothèque centrale d'information, utilise une base client/serveur comme SQL serveur, ou autre... A+, david
salut,
à la source sous-entend : ne charger que ce qui est nécessaire,
bon conseil, mais
le problème est que ACCESS n'est pas un serveur de base de données...
Les requêtes (type select * form maTable where...) sont exécutées
localement
=> la table 'maTable' est donc transférée entièrement au client qui
effectue lui-même le filtrage...
Cela ne va donc rien changer (ne temps de réponse)...
Dans ton cas, il est nécessaire de placer ces données 'bibliothèque'
en local sur chaque poste.
Pour ce faire, je te conseil d'utiliser la réplication de base. Comme
ça si tu modifies te bibliothèque sur un poste, le système va
répercuter de lui-même (tous les x temps) les modifications...
Sinon, si tu veux vraiement utiliser une bibliothèque centrale
d'information, utilise une base client/serveur comme SQL serveur, ou
autre...
A+, david
salut, à la source sous-entend : ne charger que ce qui est nécessaire, bon conseil, mais le problème est que ACCESS n'est pas un serveur de base de données...
Les requêtes (type select * form maTable where...) sont exécutées localement => la table 'maTable' est donc transférée entièrement au client qui effectue lui-même le filtrage...
Cela ne va donc rien changer (ne temps de réponse)...
Dans ton cas, il est nécessaire de placer ces données 'bibliothèque' en local sur chaque poste. Pour ce faire, je te conseil d'utiliser la réplication de base. Comme ça si tu modifies te bibliothèque sur un poste, le système va répercuter de lui-même (tous les x temps) les modifications...
Sinon, si tu veux vraiement utiliser une bibliothèque centrale d'information, utilise une base client/serveur comme SQL serveur, ou autre... A+, david
3stone
Salut,
"david" à la source sous-entend : ne charger que ce qui est nécessaire, bon conseil, mais le problème est que ACCESS n'est pas un serveur de base de données...
Les requêtes (type select * form maTable where...) sont exécutées localement => la table 'maTable' est donc transférée entièrement au client qui effectue lui-même le filtrage...
Cela ne va donc rien changer (ne temps de réponse)...
Une fausse vrai vérité ! ou l'inverse ;-(
Car tout dépend de ce que contient le "Where..." Bien sûr, si tu y place une horreur du style "Where Clients Like "B*" tu obtient effectivement ce que tu prétends. Mais, remplace le "Like B*" par "Where NoClient3456" et tu verra que la réponse est presque instantanée... Tout simplement parce que seul la clé primaire (si pas encore présente) ou l'index sera transféré et ensuite la ligne demandée.
Tu peux vérifier avec une table de 2 ou 300.000 enregistrements et surveiller le réseau !!
En aucun cas toute la table ne sera tranférée (sauf dans ton *mauvais* exemple)
PS: Tu as même un prédécesseur (bien connu par les anciens ;-) qui prétendait carrément que c'était *toute* la base qui transitait...
"david"
à la source sous-entend : ne charger que ce qui est nécessaire,
bon conseil, mais
le problème est que ACCESS n'est pas un serveur de base de données...
Les requêtes (type select * form maTable where...) sont exécutées
localement
=> la table 'maTable' est donc transférée entièrement au client qui
effectue lui-même le filtrage...
Cela ne va donc rien changer (ne temps de réponse)...
Une fausse vrai vérité ! ou l'inverse ;-(
Car tout dépend de ce que contient le "Where..."
Bien sûr, si tu y place une horreur du style "Where Clients Like "B*"
tu obtient effectivement ce que tu prétends.
Mais, remplace le "Like B*" par "Where NoClient3456" et tu verra
que la réponse est presque instantanée...
Tout simplement parce que seul la clé primaire (si pas encore présente)
ou l'index sera transféré et ensuite la ligne demandée.
Tu peux vérifier avec une table de 2 ou 300.000 enregistrements
et surveiller le réseau !!
En aucun cas toute la table ne sera tranférée (sauf dans ton *mauvais* exemple)
PS: Tu as même un prédécesseur (bien connu par les anciens ;-)
qui prétendait carrément que c'était *toute* la base qui transitait...
"david" à la source sous-entend : ne charger que ce qui est nécessaire, bon conseil, mais le problème est que ACCESS n'est pas un serveur de base de données...
Les requêtes (type select * form maTable where...) sont exécutées localement => la table 'maTable' est donc transférée entièrement au client qui effectue lui-même le filtrage...
Cela ne va donc rien changer (ne temps de réponse)...
Une fausse vrai vérité ! ou l'inverse ;-(
Car tout dépend de ce que contient le "Where..." Bien sûr, si tu y place une horreur du style "Where Clients Like "B*" tu obtient effectivement ce que tu prétends. Mais, remplace le "Like B*" par "Where NoClient3456" et tu verra que la réponse est presque instantanée... Tout simplement parce que seul la clé primaire (si pas encore présente) ou l'index sera transféré et ensuite la ligne demandée.
Tu peux vérifier avec une table de 2 ou 300.000 enregistrements et surveiller le réseau !!
En aucun cas toute la table ne sera tranférée (sauf dans ton *mauvais* exemple)
PS: Tu as même un prédécesseur (bien connu par les anciens ;-) qui prétendait carrément que c'était *toute* la base qui transitait...
David a dit : Dans ton cas, il est nécessaire de placer ces données 'bibliothèque'
en local sur chaque poste. Pour ce faire, je te conseil d'utiliser la réplication de base. Comme ça si tu modifies te bibliothèque sur un poste, le système va répercuter de lui-même (tous les x temps) les modifications...
C'est pas très académique mais pourquoi pas. Seulement, il faut aussi traiter le problème de collision en cas de créations simultanées de plusieurs nouveaux champs par des utilisateurs différents. Je ne sais pas si c'est possible avec des tables répliquées.
David a aussi dit : Sinon, si tu veux vraiement utiliser une bibliothèque centrale d'information, utilise une base client/serveur comme SQL serveur, ou autre...
Même si à vrai dire j'en sais rien, je ne pense pas que ce soit possible dans l'état actuel d'avancement du projet. En fait je ne crée pas un BD mais la répare.
Piere a dit : Car tout dépend de ce que contient le "Where..." Bien sûr, si tu y place une horreur du style "Where Clients Like "B*" tu obtient effectivement ce que tu prétends.
C'est le cas. Ces *horreurs* pullulent dans la requête lancée à l'ouverture de mon formulaire. Et je ne vois franchement pas comment m'en passer étant donné les contraintes du projet. J'ai enfin saisi ce que tu avais voulu me dire dans ta première réponse. En fait, mon formulaire est un formulaire de recherche. Pour l'instant il lance la requête à l'ouverture et elle a été faite de facon à ne rien filtrer à ce moment-là. Cette solution n'est effectivement pas satisfaisante. Je pense pour l'instant à deux solutions alternatives : soit ouvrir le formulaire PUIS charger la table (qui apparaît alors dans le sousformulaire) pendant que l'utilisateur remplit les critères de sa recherche. soit ne lancer la requête que lors du lancement de la recherche. (y'a un bouton "search"), mais ca ne résoud pas le problème du transite des données, à moins que...
vous voyez autre chose ? l'une de ces solutions peut fonctionner ? Qu'est-ce que je n'ai pas compris ?....
a+ ben
David a dit :
Dans ton cas, il est nécessaire de placer ces données 'bibliothèque'
en local sur chaque poste.
Pour ce faire, je te conseil d'utiliser la réplication de base. Comme
ça si tu modifies te bibliothèque sur un poste, le système va
répercuter de lui-même (tous les x temps) les modifications...
C'est pas très académique mais pourquoi pas. Seulement, il faut aussi
traiter le problème de collision en cas de créations simultanées de
plusieurs nouveaux champs par des utilisateurs différents. Je ne sais
pas si c'est possible avec des tables répliquées.
David a aussi dit :
Sinon, si tu veux vraiement utiliser une bibliothèque centrale
d'information, utilise une base client/serveur comme SQL serveur, ou
autre...
Même si à vrai dire j'en sais rien, je ne pense pas que ce soit
possible dans l'état actuel d'avancement du projet. En fait je ne
crée pas un BD mais la répare.
Piere a dit :
Car tout dépend de ce que contient le "Where..."
Bien sûr, si tu y place une horreur du style "Where Clients Like "B*"
tu obtient effectivement ce que tu prétends.
C'est le cas. Ces *horreurs* pullulent dans la requête lancée à
l'ouverture de mon formulaire. Et je ne vois franchement pas comment
m'en passer étant donné les contraintes du projet.
J'ai enfin saisi ce que tu avais voulu me dire dans ta première
réponse. En fait, mon formulaire est un formulaire de recherche. Pour
l'instant il lance la requête à l'ouverture et elle a été faite de
facon à ne rien filtrer à ce moment-là. Cette solution n'est
effectivement pas satisfaisante.
Je pense pour l'instant à deux solutions alternatives :
soit ouvrir le formulaire PUIS charger la table (qui apparaît alors
dans le sousformulaire) pendant que l'utilisateur remplit les critères
de sa recherche.
soit ne lancer la requête que lors du lancement de la recherche. (y'a
un bouton "search"), mais ca ne résoud pas le problème du transite
des données, à moins que...
vous voyez autre chose ? l'une de ces solutions peut fonctionner ?
Qu'est-ce que je n'ai pas compris ?....
David a dit : Dans ton cas, il est nécessaire de placer ces données 'bibliothèque'
en local sur chaque poste. Pour ce faire, je te conseil d'utiliser la réplication de base. Comme ça si tu modifies te bibliothèque sur un poste, le système va répercuter de lui-même (tous les x temps) les modifications...
C'est pas très académique mais pourquoi pas. Seulement, il faut aussi traiter le problème de collision en cas de créations simultanées de plusieurs nouveaux champs par des utilisateurs différents. Je ne sais pas si c'est possible avec des tables répliquées.
David a aussi dit : Sinon, si tu veux vraiement utiliser une bibliothèque centrale d'information, utilise une base client/serveur comme SQL serveur, ou autre...
Même si à vrai dire j'en sais rien, je ne pense pas que ce soit possible dans l'état actuel d'avancement du projet. En fait je ne crée pas un BD mais la répare.
Piere a dit : Car tout dépend de ce que contient le "Where..." Bien sûr, si tu y place une horreur du style "Where Clients Like "B*" tu obtient effectivement ce que tu prétends.
C'est le cas. Ces *horreurs* pullulent dans la requête lancée à l'ouverture de mon formulaire. Et je ne vois franchement pas comment m'en passer étant donné les contraintes du projet. J'ai enfin saisi ce que tu avais voulu me dire dans ta première réponse. En fait, mon formulaire est un formulaire de recherche. Pour l'instant il lance la requête à l'ouverture et elle a été faite de facon à ne rien filtrer à ce moment-là. Cette solution n'est effectivement pas satisfaisante. Je pense pour l'instant à deux solutions alternatives : soit ouvrir le formulaire PUIS charger la table (qui apparaît alors dans le sousformulaire) pendant que l'utilisateur remplit les critères de sa recherche. soit ne lancer la requête que lors du lancement de la recherche. (y'a un bouton "search"), mais ca ne résoud pas le problème du transite des données, à moins que...
vous voyez autre chose ? l'une de ces solutions peut fonctionner ? Qu'est-ce que je n'ai pas compris ?....
a+ ben
3stone
Salut,
"oualaléreur" en local sur chaque poste. Pour ce faire, je te conseil d'utiliser la réplication de base. Comme ça si tu modifies te bibliothèque sur un poste, le système va répercuter de lui-même (tous les x temps) les modifications...
Joli comme phrase... qui ne tient pas la route !
Si la simple ouverture d'un formulaire fait ramer la base que fera la synchronisation "tous les x temps" ??
La réplication s'utilise lorsque les bases ne sont PAS en réseau et/ou si chaque base ne doit pas connaitre "instantanément" les ajouts/modifs dans les autres bases !
Mais cela ne remplace en aucun cas une base en réseau.
David a aussi dit : Sinon, si tu veux vraiement utiliser une bibliothèque centrale d'information, utilise une base client/serveur comme SQL serveur, ou autre...
Lorsque l'on connait mal Access, on a tendance à proposer SQL Server en se disant cela ira de toute facon mieux... Moi je dirais que celui qui ne sait pas faire une base Access "propre" ne sait pas faire un base SQL Server digne de ce nom !
D'ailleurs, rien ne t'empêche d'utiliser Access comme frontal, mais de remplacer son JET, par défaut, et de créer un "projet" ADP et utiliser MSDE
Même si à vrai dire j'en sais rien, je ne pense pas que ce soit possible dans l'état actuel d'avancement du projet. En fait je ne crée pas un BD mais la répare.
Créer une base de données Access sans suffisement connaître Access est déjà une gageure... quant à la "réparer"... ;-( Quoique l'on puisse comprendre sous "réparation".
Piere a dit : Car tout dépend de ce que contient le "Where..." Bien sûr, si tu y place une horreur du style "Where Clients Like "B*" tu obtient effectivement ce que tu prétends.
C'est le cas. Ces *horreurs* pullulent dans la requête lancée à l'ouverture de mon formulaire. Et je ne vois franchement pas comment m'en passer étant donné les contraintes du projet.
et possiblement, des clés primaire "texte", pas d'index...
J'ai enfin saisi ce que tu avais voulu me dire dans ta première réponse. En fait, mon formulaire est un formulaire de recherche. Pour l'instant il lance la requête à l'ouverture et elle a été faite de facon à ne rien filtrer à ce moment-là. Cette solution n'est effectivement pas satisfaisante.
Raison de plus de ne pas ramener toutes les données dans le cas d'un formulaire de chercher... car dans ce cas, tu ne fait plus que "filtrer" ce qui est déjà présent !
Je pense pour l'instant à deux solutions alternatives : soit ouvrir le formulaire PUIS charger la table (qui apparaît alors dans le sousformulaire) pendant que l'utilisateur remplit les critères de sa recherche.
On ne "charge" pas une table... tu n'es pas dans Excel ! On tente dans la mesure du possible de n'appeller que le minimum de *ligne* pour satisfaire la demande.
soit ne lancer la requête que lors du lancement de la recherche. (y'a un bouton "search"), mais ca ne résoud pas le problème du transite des données, à moins que...
Si l'on contruit quelque chose comme : where client like "B*" and Rue like "*chateau*" and .... même SQL Server sera diffcilement performant !
Ceci dit: on peut parfaitement ouvrir un formulaire (sans source) en présentant quelques zones de texte pour saisir les critères, en faisant surtout attention d'utiliser un critère très réducteur quant aux quantités de données concernées.
Utiliser des clés primaire numérique, des index sur les champs concernés... ne sont que les premières mesures à mettre *toujours* en oeuvre.
"oualaléreur"
en local sur chaque poste.
Pour ce faire, je te conseil d'utiliser la réplication de base. Comme
ça si tu modifies te bibliothèque sur un poste, le système va
répercuter de lui-même (tous les x temps) les modifications...
Joli comme phrase... qui ne tient pas la route !
Si la simple ouverture d'un formulaire fait ramer la base
que fera la synchronisation "tous les x temps" ??
La réplication s'utilise lorsque les bases ne sont PAS en réseau
et/ou si chaque base ne doit pas connaitre "instantanément"
les ajouts/modifs dans les autres bases !
Mais cela ne remplace en aucun cas une base en réseau.
David a aussi dit :
Sinon, si tu veux vraiement utiliser une bibliothèque centrale
d'information, utilise une base client/serveur comme SQL serveur, ou
autre...
Lorsque l'on connait mal Access, on a tendance à proposer
SQL Server en se disant cela ira de toute facon mieux...
Moi je dirais que celui qui ne sait pas faire une base
Access "propre" ne sait pas faire un base SQL Server
digne de ce nom !
D'ailleurs, rien ne t'empêche d'utiliser Access comme frontal,
mais de remplacer son JET, par défaut, et de créer un "projet"
ADP et utiliser MSDE
Même si à vrai dire j'en sais rien, je ne pense pas que ce soit
possible dans l'état actuel d'avancement du projet. En fait je ne
crée pas un BD mais la répare.
Créer une base de données Access sans suffisement connaître
Access est déjà une gageure... quant à la "réparer"... ;-(
Quoique l'on puisse comprendre sous "réparation".
Piere a dit :
Car tout dépend de ce que contient le "Where..."
Bien sûr, si tu y place une horreur du style "Where Clients Like "B*"
tu obtient effectivement ce que tu prétends.
C'est le cas. Ces *horreurs* pullulent dans la requête lancée à
l'ouverture de mon formulaire. Et je ne vois franchement pas comment
m'en passer étant donné les contraintes du projet.
et possiblement, des clés primaire "texte", pas d'index...
J'ai enfin saisi ce que tu avais voulu me dire dans ta première
réponse. En fait, mon formulaire est un formulaire de recherche. Pour
l'instant il lance la requête à l'ouverture et elle a été faite de
facon à ne rien filtrer à ce moment-là. Cette solution n'est
effectivement pas satisfaisante.
Raison de plus de ne pas ramener toutes les données dans le cas
d'un formulaire de chercher... car dans ce cas, tu ne fait plus
que "filtrer" ce qui est déjà présent !
Je pense pour l'instant à deux solutions alternatives :
soit ouvrir le formulaire PUIS charger la table (qui apparaît alors
dans le sousformulaire) pendant que l'utilisateur remplit les critères
de sa recherche.
On ne "charge" pas une table... tu n'es pas dans Excel !
On tente dans la mesure du possible de n'appeller que le
minimum de *ligne* pour satisfaire la demande.
soit ne lancer la requête que lors du lancement de la recherche. (y'a
un bouton "search"), mais ca ne résoud pas le problème du transite
des données, à moins que...
Si l'on contruit quelque chose comme :
where client like "B*" and Rue like "*chateau*" and ....
même SQL Server sera diffcilement performant !
Ceci dit: on peut parfaitement ouvrir un formulaire (sans source)
en présentant quelques zones de texte pour saisir les critères,
en faisant surtout attention d'utiliser un critère très réducteur quant
aux quantités de données concernées.
Utiliser des clés primaire numérique, des index sur les champs concernés...
ne sont que les premières mesures à mettre *toujours* en oeuvre.
"oualaléreur" en local sur chaque poste. Pour ce faire, je te conseil d'utiliser la réplication de base. Comme ça si tu modifies te bibliothèque sur un poste, le système va répercuter de lui-même (tous les x temps) les modifications...
Joli comme phrase... qui ne tient pas la route !
Si la simple ouverture d'un formulaire fait ramer la base que fera la synchronisation "tous les x temps" ??
La réplication s'utilise lorsque les bases ne sont PAS en réseau et/ou si chaque base ne doit pas connaitre "instantanément" les ajouts/modifs dans les autres bases !
Mais cela ne remplace en aucun cas une base en réseau.
David a aussi dit : Sinon, si tu veux vraiement utiliser une bibliothèque centrale d'information, utilise une base client/serveur comme SQL serveur, ou autre...
Lorsque l'on connait mal Access, on a tendance à proposer SQL Server en se disant cela ira de toute facon mieux... Moi je dirais que celui qui ne sait pas faire une base Access "propre" ne sait pas faire un base SQL Server digne de ce nom !
D'ailleurs, rien ne t'empêche d'utiliser Access comme frontal, mais de remplacer son JET, par défaut, et de créer un "projet" ADP et utiliser MSDE
Même si à vrai dire j'en sais rien, je ne pense pas que ce soit possible dans l'état actuel d'avancement du projet. En fait je ne crée pas un BD mais la répare.
Créer une base de données Access sans suffisement connaître Access est déjà une gageure... quant à la "réparer"... ;-( Quoique l'on puisse comprendre sous "réparation".
Piere a dit : Car tout dépend de ce que contient le "Where..." Bien sûr, si tu y place une horreur du style "Where Clients Like "B*" tu obtient effectivement ce que tu prétends.
C'est le cas. Ces *horreurs* pullulent dans la requête lancée à l'ouverture de mon formulaire. Et je ne vois franchement pas comment m'en passer étant donné les contraintes du projet.
et possiblement, des clés primaire "texte", pas d'index...
J'ai enfin saisi ce que tu avais voulu me dire dans ta première réponse. En fait, mon formulaire est un formulaire de recherche. Pour l'instant il lance la requête à l'ouverture et elle a été faite de facon à ne rien filtrer à ce moment-là. Cette solution n'est effectivement pas satisfaisante.
Raison de plus de ne pas ramener toutes les données dans le cas d'un formulaire de chercher... car dans ce cas, tu ne fait plus que "filtrer" ce qui est déjà présent !
Je pense pour l'instant à deux solutions alternatives : soit ouvrir le formulaire PUIS charger la table (qui apparaît alors dans le sousformulaire) pendant que l'utilisateur remplit les critères de sa recherche.
On ne "charge" pas une table... tu n'es pas dans Excel ! On tente dans la mesure du possible de n'appeller que le minimum de *ligne* pour satisfaire la demande.
soit ne lancer la requête que lors du lancement de la recherche. (y'a un bouton "search"), mais ca ne résoud pas le problème du transite des données, à moins que...
Si l'on contruit quelque chose comme : where client like "B*" and Rue like "*chateau*" and .... même SQL Server sera diffcilement performant !
Ceci dit: on peut parfaitement ouvrir un formulaire (sans source) en présentant quelques zones de texte pour saisir les critères, en faisant surtout attention d'utiliser un critère très réducteur quant aux quantités de données concernées.
Utiliser des clés primaire numérique, des index sur les champs concernés... ne sont que les premières mesures à mettre *toujours* en oeuvre.
