Table liée sous Access via connexion RNIS : au secours !!!

Bonjour,

Bon voilà j'ai une application access 2000 qui contient des tables attachées sur une autre base de données Access MDB. Seulement entre l'appli et la BD la connexion reseau est en RNIS 64KB, et là au secours ...

Les temps de réponse sont désastreux.
Exemple : j'ai une table attachée qui contient 3 champs, et 80 enregistrements. Si je crée un combox avec en requete source un simple select sur cette table, j'attend plus de 5 mins pour en avoir le contenu. Pire ! , lors de ce simple select il transite 3mo de données !!! (valeur observée via le moniteur d'accès à distance). 3 mo pour 80 enregistrements c'est beaucoup , non ? (surtout que les champs contiennent peu de caractères)

J'ai essayé de lier les tables Access via ODBC avec le pilote odbc access, et j'ai une erreur du style "impossible d'utiliser odbc pour importer de, exporter vers, ou attacher une table microsoft jet à votre base de données." (Dans ce cas à quoi ça sert d'avoir des pilotes odbc pour base access si on ne peut pas s'en servir ???)

Nous avons fait des essais via liaison VPN 512K, c'est pas génial ... en revanche sur un reseau 10Meg y'a pas de souci, normal quoi.

Bon si quelqu'un a une idée.... merci, je désespère :)

Bonjour,

J'ai eu le même problème. Mais j'ai créé une procédure qui, lors du démarrage de l'application, copie tous les données des tables distantes dans des tables temporaires en locale. Le démarrage sera lent, mais après, la consultation est très rapide.

Il faut créer une petite fenêtre indiquant à l'utilisateur de patienter ainsi que la description du traitement en cours pour qu'il ne gueule pas.

Si on veut faire des modifications, on fera une mise à jour sur les données en local et distant. La mise à jour n'est pas très lente car la requête ne modifie qu'une ou quelques lignes de données.

Le problème est que si la base distante est partagée avec d'autres personnes, les données en locales ne seront pas rafraîchies qu'en réinitialisant les tables locales.

A+






-------------------------------
Réponse au message :
-------------------------------

Bonjour,

Bon voilà j'ai une application access 2000 qui contient des tables attachées sur une autre base de données Access MDB. Seulement entre l'appli et la BD la connexion reseau est en RNIS 64KB, et là au secours ...

Les temps de réponse sont désastreux.
Exemple : j'ai une table attachée qui contient 3 champs, et 80 enregistrements. Si je crée un combox avec en requete source un simple select sur cette table, j'attend plus de 5 mins pour en avoir le contenu. Pire ! , lors de ce simple select il transite 3mo de données !!! (valeur observée via le moniteur d'accès à distance). 3 mo pour 80 enregistrements c'est beaucoup , non ? (surtout que les champs contiennent peu de caractères)

J'ai essayé de lier les tables Access via ODBC avec le pilote odbc access, et j'ai une erreur du style "impossible d'utiliser odbc pour importer de, exporter vers, ou attacher une table microsoft jet à votre base de données." (Dans ce cas à quoi ça sert d'avoir des pilotes odbc pour base access si on ne peut pas s'en servir ???)

Nous avons fait des essais via liaison VPN 512K, c'est pas génial ... en revanche sur un reseau 10Meg y'a pas de souci, normal quoi.

Bon si quelqu'un a une idée.... merci, je désespère :)

Ok merci pour ton conseil, c'est une solution qui est envisagée, mais dans l'absolu la base est partagéé par 5 postes, donc c'est un peu chiant. En plus, mon appli possède quand même 60 tables distantes, dont certaines avec pas mal d'enregistrements donc c'est pas le top.

Ce que je comprends pas surtout c'est ce transfert de 3meg pour 60 records à la c-n !



-------------------------------
Réponse au message :
-------------------------------

Bonjour,

J'ai eu le même problème. Mais j'ai créé une procédure qui, lors du démarrage de l'application, copie tous les données des tables distantes dans des tables temporaires en locale. Le démarrage sera lent, mais après, la consultation est très rapide.

Il faut créer une petite fenêtre indiquant à l'utilisateur de patienter ainsi que la description du traitement en cours pour qu'il ne gueule pas.

Si on veut faire des modifications, on fera une mise à jour sur les données en local et distant. La mise à jour n'est pas très lente car la requête ne modifie qu'une ou quelques lignes de données.

Le problème est que si la base distante est partagée avec d'autres personnes, les données en locales ne seront pas rafraîchies qu'en réinitialisant les tables locales.

A+

La provenance des 3 Mo je pense que tu as lancé une requête avec critère à partir d'une table distante contenant pas mal de données. Quand tu lance ta requête, Access va chercher d'abord toutes les données de la table, la totalité. Une fois que les données arrive en local, c'est là qu'il commence à executer le filtre des données. C'est pour ça que c'est un peu lent.

L'idéal est de travailler avec SQL Server, tu appeles une procédure stockée sur le serveur, le serveur ne te renvoie que les données que tu as demandé dans la requête de la procédure. Avec Access, je ne sais pas si on peut demander à executer une requête qui se trouve sur la base distante ou pas, style procédure stockée. Je ne peux pas te répondre.

A+


-------------------------------
Réponse au message :
-------------------------------

Ok merci pour ton conseil, c'est une solution qui est envisagée, mais dans l'absolu la base est partagéé par 5 postes, donc c'est un peu chiant. En plus, mon appli possède quand même 60 tables distantes, dont certaines avec pas mal d'enregistrements donc c'est pas le top.

Ce que je comprends pas surtout c'est ce transfert de 3meg pour 60 records à la c-n !



-------------------------------
Réponse au message :
-------------------------------

Bonjour,

J'ai eu le même problème. Mais j'ai créé une procédure qui, lors du démarrage de l'application, copie tous les données des tables distantes dans des tables temporaires en locale. Le démarrage sera lent, mais après, la consultation est très rapide.

Il faut créer une petite fenêtre indiquant à l'utilisateur de patienter ainsi que la description du traitement en cours pour qu'il ne gueule pas.

Si on veut faire des modifications, on fera une mise à jour sur les données en local et distant. La mise à jour n'est pas très lente car la requête ne modifie qu'une ou quelques lignes de données.

Le problème est que si la base distante est partagée avec d'autres personnes, les données en locales ne seront pas rafraîchies qu'en réinitialisant les tables locales.

A+