> Le probl�me d'Access c'est que tout le travail est accompli par le poste
> client. La principale cause de lenteur d'access est qu'il pr�-dig�re toutes
Si l'on consid�re une requ�te comme:
SELECT c.nom
FROM client c
WHERE c.id NOT IN (SELECT cmd.client_id FROM commande cmd)
(retourner le noms des clients qui n'ont pas pass� de commande)
tu n'es pas entrain de me dire qu'Access va stupidement transf�rer par
r�seau toutes les commandes (ou cmd.client_id), puis faire le reste de la
requ�te ? Alors que dans ce cas on n'a peut-�tre qu'un ou deux
r�sultats et que c'est mieux si le serveur peut s'en occuper tout seul ?
Car si oui, cela pose de nombreux probl�mes quant � l'atomicit�, p.ex.
Ou bien parles-tu d'autre chose ?
> interpr�t�es par Access. La seule limitation de ce genre de requ�tes est
> qu'il faut enlever toutes les fonctions sp�cifiques d'access de la chaine
> sql.
En pratique, cela veut-il dire r��crire tous les scripts, et ne pouvoir
utiliser le designer de Microsoft Access ?
> Les autres causes de lenteur sont souvent li�es � la m�thode employ�e par le
> poste client pour communiquer avec access. Si ma m�moire est bonne ADO �tait
L� je ne suis pas: pour moi, Microsoft Access *est* le client.
--
http://www-internal.alphanet.ch/linux-leman/ avant de poser
une question.
