Question précise

Bonjour,

Access travaille toujours sur du local (pour un frontal Access et un Backend
Access).
Donc si tu effectue une requete le transit sur le reseau sera du nombre
total d'enregistrement (5000 dans ton cas).
Puis en local Access traitera la requete et affichera les 100 enr
nécessaire.
C'est pour cela aussi qu'avoir SQL Serveur en Back end est interessant car
dans ce cas la requete est traité par le serveur, puis retourne seulement
les enreg nécessaire.

Gael.

"Guy" <anonymous@discussions.microsoft.com> a écrit dans le message de
news:0a8801c39e07$d2ba99f0$a301280a@phx.gbl...
Bonjour à tous,

J'ai un DB Access 97 sur un serveur. Une appli client
fait appelle à cette DB via des requêtes.

Question:
Sachant qu'Access ne fonctionne ni comme SQL Server ni
comme Oracle, si une table contient 5000 records et que je
lance une requête (SELECT) via l'application ne demandant
que 100 records en retour, qu'est-ce qui transite sur le
réseau ? Les 5000 records pour être traités en local ou
seulement le 100 records demandés ?

Je n'ai jamais eu de réponses bien précises à ce sujet ou
alors qui se contredisent. Pouvez-vous m'éclairer très
précisément ?

Merci à tous.

Guy

Bonjour,

Autre version:

Lorsque la source comporte une clause WHERE et que cette clause s'applique à des champs indexés, Access lit la totalité de l'index
puis ne transfère (via le réseau) que les lignes sélectionnées.

La doc n'est pas très claire sur ce point, la rédaction de l'article laisse à désirer (Access 2000 Programmation, page 877, Débit et
saturation du réseau), mais je me souviens avoir fait des tests sur des tables très grosses, et cela semblait marcher de cette
manière.....Serait-il temps d'en refaire ?????????

D'un autre côté, habituellement, Gaël sait de quoi il parle.......

J-Pierre

Bonjour Guy!

Juste pour complementer un peu la reponse de Gael.... :-)

Si Jet peut utiliser un index sur la (ou les) table(s) concernees, alors
5000 valeurs d'index (au maximum) vont transiter sur le fil, et les champs
necessaires des 100 enregistrements. C'est la qu'on s'appercoit que c'est
utile d'avoir des bons index.

Je dis 5000 au maximum, car Rushmore permet d'eliminer de grosses portions
de la table qui ne correspondent pas au critere.

Si par contre la requete est faite de telle maniere qu'elle force Jet a
faire un "table scan", alors les 5000 champs sur lesquels se fait la
selection vont passer sur le fil. C'est le cas quand on utilise des calculs
ou des fonctions dans la clause WHERE, comme par exemple "WHERE
Left(MonChamp, 1) = 'A'. Quel que soit l'indexage utilise sur cette table,
les 5000 MonChamp vont etre evalues en local.

Le dernier point a ce sujet concerne le cache que Jet maintient sur la
machine locale. Dans certaines conditions, Access n'aura pas a aller
rechercher les index ou les enregistrements, ce qui supprime un aller-retour
sur le fil.

Si vous voulez des informations plus detaillees, ma reference en la matiere
depuis la version 95 d'Access est l'excellent livre de Dan Haught et Jim
Fergusson : Jet Database Engine Programmer's Guide, qui etait disponible en
ligne sur msdn, mais que je n'arrive plus a trouver :-(

J'espere que ca vous donne quelques pointeurs...

--
Daniel :-)

Computing Technologies International - www.computing-tech.com - We
provide solutions...

"Guy" <anonymous@discussions.microsoft.com> wrote in message
news:0a8801c39e07$d2ba99f0$a301280a@phx.gbl...
Bonjour à tous,

J'ai un DB Access 97 sur un serveur. Une appli client
fait appelle à cette DB via des requêtes.

Question:
Sachant qu'Access ne fonctionne ni comme SQL Server ni
comme Oracle, si une table contient 5000 records et que je
lance une requête (SELECT) via l'application ne demandant
que 100 records en retour, qu'est-ce qui transite sur le
réseau ? Les 5000 records pour être traités en local ou
seulement le 100 records demandés ?

Je n'ai jamais eu de réponses bien précises à ce sujet ou
alors qui se contredisent. Pouvez-vous m'éclairer très
précisément ?

Merci à tous.

Guy

Bonjour

J-Pierre <pas.de.pub.jpberchtold@hotmail.com> a confié :
[...]
je me souviens avoir fait des tests sur
| des tables très grosses, et cela semblait marcher de cette
| manière.....Serait-il temps d'en refaire ?????????

Je profite de ce fil pour poster un bout de code trouvé sur comp.databases.ms-access
il y a quelques mois, et qui pourra peut-être faire avancer le schmilblick,
à condition que les résultats soient analysés avec méthode :

Sub testDiskStats()
Call DiskStats(True)
DoCmd.OpenQuery "Requete1"
DoCmd.Close
Call DiskStats(False)
Call DiskStats(True)
DoCmd.OpenQuery "Requete2"
DoCmd.Close
Call DiskStats(False)
End Sub

Public Function DiskStats(bolReset As Boolean)
Dim lngTemp As Long
If bolReset = True Then
DBEngine(0).BeginTrans
DBEngine(0).CommitTrans
lngTemp = DBEngine.ISAMStats(0, True)
lngTemp = DBEngine.ISAMStats(1, True)
lngTemp = DBEngine.ISAMStats(2, True)
lngTemp = DBEngine.ISAMStats(3, True)
lngTemp = DBEngine.ISAMStats(4, True)
lngTemp = DBEngine.ISAMStats(5, True)
Else
msgbox "DiskRead = " & DBEngine.ISAMStats(0) & vbCrLf & _
"DiskWrite = " & DBEngine.ISAMStats(1) & vbCrLf & _
"CacheRead = " & DBEngine.ISAMStats(2) & vbCrLf & _
"CacheReadAheadCache = " & DBEngine.ISAMStats(3) & vbCrLf & _
"LocksPlaced = " & DBEngine.ISAMStats(4) & vbCrLf & _
"LocksReleased = " & DBEngine.ISAMStats(5)
End If
End Function

Enjoy ;-)
--
à+
Arnaud
--------------------------------------------------
Avant toute chose : http://users.skynet.be/mpfa/
Access Memorandum - http://memoaccess.free.fr
## Réponses souhaitées sur ce forum, merci. ##
--------------------------------------------------

Bonjour Daniel,

Ne serait ce pas de ce lien dont tu parlais ?
http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/sql/proddocs/msjet/jetch04.asp

Gael.

"Daniel Carollo" <danielc@NO_SPAM_PLEASE.computing-tech.com> a écrit dans le
message de news:eHmUVDhnDHA.1708@TK2MSFTNGP12.phx.gbl...

Bonjour Guy!

Juste pour complementer un peu la reponse de Gael.... :-)

Si Jet peut utiliser un index sur la (ou les) table(s) concernees, alors
5000 valeurs d'index (au maximum) vont transiter sur le fil, et les champs
necessaires des 100 enregistrements. C'est la qu'on s'appercoit que c'est
utile d'avoir des bons index.

Je dis 5000 au maximum, car Rushmore permet d'eliminer de grosses portions
de la table qui ne correspondent pas au critere.

Si par contre la requete est faite de telle maniere qu'elle force Jet a
faire un "table scan", alors les 5000 champs sur lesquels se fait la
selection vont passer sur le fil. C'est le cas quand on utilise des
calculs

ou des fonctions dans la clause WHERE, comme par exemple "WHERE
Left(MonChamp, 1) = 'A'. Quel que soit l'indexage utilise sur cette table,
les 5000 MonChamp vont etre evalues en local.

Le dernier point a ce sujet concerne le cache que Jet maintient sur la
machine locale. Dans certaines conditions, Access n'aura pas a aller
rechercher les index ou les enregistrements, ce qui supprime un
aller-retour

sur le fil.

Si vous voulez des informations plus detaillees, ma reference en la
matiere

depuis la version 95 d'Access est l'excellent livre de Dan Haught et Jim
Fergusson : Jet Database Engine Programmer's Guide, qui etait disponible
en

ligne sur msdn, mais que je n'arrive plus a trouver :-(

J'espere que ca vous donne quelques pointeurs...

--
Daniel :-)

Computing Technologies International - www.computing-tech.com - We
provide solutions...

"Guy" <anonymous@discussions.microsoft.com> wrote in message
news:0a8801c39e07$d2ba99f0$a301280a@phx.gbl...
Bonjour à tous,

J'ai un DB Access 97 sur un serveur. Une appli client
fait appelle à cette DB via des requêtes.

Question:
Sachant qu'Access ne fonctionne ni comme SQL Server ni
comme Oracle, si une table contient 5000 records et que je
lance une requête (SELECT) via l'application ne demandant
que 100 records en retour, qu'est-ce qui transite sur le
réseau ? Les 5000 records pour être traités en local ou
seulement le 100 records demandés ?

Je n'ai jamais eu de réponses bien précises à ce sujet ou
alors qui se contredisent. Pouvez-vous m'éclairer très
précisément ?

Merci à tous.

Guy

Bonjour Gael!

Ca a l'air d'etre celui-ci, en effet, bien qu'il n'y ait aucune mention des
auteurs du livre. Je l'avais achete quand Access 95 etait sorti, puis la
version mise a jour pour Jet 3.5 a la sortie d'Access 97. Les chapitres
disponibles en ligne sont d'une lecture essentielle, mais il y a aussi
beaucoup d'information dans les chapitres suivants, en particulier le
chapitre 13 sur la performance...

Je n'ai pas les livres physiques avec moi (je bouge trop), mais s'il y avait
une nouvelle version pour Jet 4, ce serait un tres bon investissement pour
ceux qui aiment savoir ce qu'il y a sous le capot, et comment ca marche.

J'ai appris quelque chose aujourd'hui: une recherche sur MSDN ne couvre pas
le contenu de technet :-(

Si tu travailles pour microsoft, pourais-tu te renseigner si Jim et Dan ont
l'intention d'ecrire une nouvelle version, ou peut-etre y a-t-il un bouquin
du genre "Inside SQL Server", mais pour Access/Jet...

A bientot.
--
Daniel :-)

Computing Technologies International - www.computing-tech.com - We
provide solutions...

"Gaël Schmitt" <gaels@online.microsoft.com> wrote in message
news:eBKgiRhnDHA.1728@TK2MSFTNGP09.phx.gbl...

Bonjour Daniel,

Ne serait ce pas de ce lien dont tu parlais ?

http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/sql/proddocs/msjet/jetch04.asp

Gael.

En fait Jim et Dan sont des indépendants.
Ils ont fait valider le contenu de leur livre avant la publication par
Microsoft press.

Sinon depuis aucun livre de Dan ne poursuit dans l'étude du moteur Jet.

De plus je n'ai pas trouvé de livre très pointu sur les liens Jet/Access
pour le moteur Jet4.

Gael.
"Daniel Carollo" <danielc@NO_SPAM_PLEASE.computing-tech.com> a écrit dans le
message de news:%23xqY$ehnDHA.688@TK2MSFTNGP10.phx.gbl...

Bonjour Gael!

Ca a l'air d'etre celui-ci, en effet, bien qu'il n'y ait aucune mention
des

auteurs du livre. Je l'avais achete quand Access 95 etait sorti, puis la
version mise a jour pour Jet 3.5 a la sortie d'Access 97. Les chapitres
disponibles en ligne sont d'une lecture essentielle, mais il y a aussi
beaucoup d'information dans les chapitres suivants, en particulier le
chapitre 13 sur la performance...

Je n'ai pas les livres physiques avec moi (je bouge trop), mais s'il y
avait

une nouvelle version pour Jet 4, ce serait un tres bon investissement pour
ceux qui aiment savoir ce qu'il y a sous le capot, et comment ca marche.

J'ai appris quelque chose aujourd'hui: une recherche sur MSDN ne couvre
pas

le contenu de technet :-(

Si tu travailles pour microsoft, pourais-tu te renseigner si Jim et Dan
ont

l'intention d'ecrire une nouvelle version, ou peut-etre y a-t-il un
bouquin

du genre "Inside SQL Server", mais pour Access/Jet...

A bientot.
--
Daniel :-)

Computing Technologies International - www.computing-tech.com - We
provide solutions...

"Gaël Schmitt" <gaels@online.microsoft.com> wrote in message
news:eBKgiRhnDHA.1728@TK2MSFTNGP09.phx.gbl...

Bonjour Daniel,

Ne serait ce pas de ce lien dont tu parlais ?

http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/sql/proddocs/msjet/jetch04.asp

Gael.

-----Message d'origine-----
Bonjour à tous,

J'ai un DB Access 97 sur un serveur. Une appli client
fait appelle à cette DB via des requêtes.

Question:
Sachant qu'Access ne fonctionne ni comme SQL Server ni
comme Oracle, si une table contient 5000 records et que
je

lance une requête (SELECT) via l'application ne
demandant

que 100 records en retour, qu'est-ce qui transite sur le
réseau ? Les 5000 records pour être traités en local ou
seulement le 100 records demandés ?

Je n'ai jamais eu de réponses bien précises à ce sujet
ou

alors qui se contredisent. Pouvez-vous m'éclairer très
précisément ?

Merci à tous.

Guy


.

Bien sûr seuls les 5000 enregistrements transiteront par

le réseau pour être traités en local (il ne s'agit pas
d'un soft client-serveur) ou bien, utiliser SQL comme
dorsal !!

Salut,

Voilà, j'ai refait des essais.

La base MDB fait 400 megs, elle est ouverte depuis un autre poste, le réseau local est à 100 Mb.

La table "T027_infographie_taches" contient plus de 3 millions de lignes, et comporte 10 colonnes.
La clé primaire se compose des 3 premières colonnes, Dossier, Fonction, Sequence.
Un index avec doublons sur la colonne dossier
pas d'index sur les autres colonnes.

Un formulaire en mode continu, source (sélection sur l'index):

SELECT T027_infographie_taches.*, X037_infographie_fonctions_type.X037_facturable FROM T027_infographie_taches LEFT JOIN
X037_infographie_fonctions_type ON T027_infographie_taches.T027_fonction_type = X037_infographie_fonctions_type.X037_fonction_type
WHERE (((T027_infographie_taches.T027_no_projet)=[Forms]![F011_infographie_taches]![T001_no_projet]) AND
((T027_infographie_taches.T027_fonction_type)=[Forms]![F011_infographie_taches]![Modifiable128])) ORDER BY
T027_infographie_taches.T027_sequence;

J'ouvre le formulaire, réponse instantanée (pas mesurable manuellement), le recordSet contient 121 lignes, Access a lu l'index puis
n'a transféré que les lignes correspondant au Dossier. Le fait que la colonne Fonction ne soit pas définie comme index ne détériore
pas la performance, car un Dossier se compose d'environ 500 lignes. Mais suivant les cas, il peut être intéressant d'avoir plus
d'index pour réduire encore plus les données qui transitent sur le réseau. Mais attention, trop d'index tue aussi et peut ralentir
la performance......

Je supprime la clé primaire et l'index.
Je réouvre le formulaire. réponse une minute, le recordSet contient toujours 121 lignes, mais dans ce cas, Access a transféré la
totalité de la table.

J'approuve totalement Daniel, la manière de créer et d'utiliser les index est capitale.
L'ouverture en mode feuille de données d'une table de 6000 lignes se fait en moins de 2 secondes sur un réseau local. Mais s'il y a
10 utilisateurs, cela fera 20 secondes en tout, avec saturation du réseau...... Bien souvent, pour les PME, en réseau local, le
passage à SQL n'est pas justifié, il suffit de se pencher sérieusement sur la conception de la base et l'accès aux données.

Et puis, les erreurs de conception ou de programmation ont le même effet avec Access ou avec SQL server, les temps de réponse sont
désastreux.
Ne vous méprenez pas, j'adore SQL server, mais a-t-on besoin d'un marteau-pilon pour écraser une mouche ?

J-Pierre

Bonjour Jean-Pierre!

"J-Pierre" <pas.de.pub.jpberchtold@hotmail.com> wrote in message
news:Ov3HMxinDHA.2140@TK2MSFTNGP09.phx.gbl...

Salut,

Voilà, j'ai refait des essais.

C'est tres bien ca, de faire des essais chiffres pour appuyer ce dont on
discute. Ca n'arrive pas assez souvent.

8>< tout plein de texte coupe ><8

... Mais suivant les cas, il peut être intéressant d'avoir plus
d'index pour réduire encore plus les données qui transitent sur le réseau.
Mais attention, trop d'index tue aussi et peut ralentir

la performance......

Dans ce cas particulier, on ne peut pas avoir trop d'index. S'il y en a "en
trop", ils ne seront tout simplement pas utilises, et il n'y aura bien sur
pas de gain en performance, mais il n'y aura pas de perte non plus.

Les seuls deux inconvenients a avoir trop d'index, sont les suivants:
- la base grossit (car il faut stocker les index)
- les temps d'ecriture (sauvegarde de nouveaux enregistrement et mise a
jour des champs qui sont indexes) augmentent.

Si quelqu'un a d'autres raisons que ces deux la, j'aimerais bien les
connaitre (on en apprend tous les jours).

J'approuve totalement Daniel, la manière de créer et d'utiliser les index
est capitale.

L'ouverture en mode feuille de données d'une table de 6000 lignes se fait
en moins de 2 secondes sur un réseau

local. Mais s'il y a 10 utilisateurs, cela fera 20 secondes en tout, avec
saturation du réseau......

Pas forcement, ca vaudrait le coup de faire l'essai, mesures a l'appui. Les
operations rallentissent _beaucoup_ quand Jet doit ecrire les donnees
relatives aux verrouillages dans le fichier .ldb. D'apres mon experience,
les temps d'attente ont tendance a devenir exponentiels quand on passe de
deux a trois utilisateurs a plus. A vue de nez, je dirais que 2 secondes
pour un utilisateur va probablement se traduire par 4 a 6 secondes pour 3 ou
4 utilisateurs, mais probablement 8 a 12 secondes pour un utilisateur de
plus, puis 16 a 24 pour deux de plus etc...
C'est tres rarement lineaire.

... Bien souvent, pour les PME, en réseau local, le
passage à SQL n'est pas justifié, il suffit de se pencher sérieusement sur
la conception de la base et l'accès aux données.

La je suis pas du tout d'accord avec vous, et voici mes raisons:
- La performance n'est pas forcement l'element decisif au niveau du choix
d'architecture.
- La facilite de programmation est souvent une barriere a l'obtention d'une
application stable et de qualite. (Je phrase ca de facon un peu provocative
;-)
- La replication de Jet / Access est risible comparee a celle de SQL Server.
- Les fonctionnalites d'Access au niveau de la securite sont difficile a
mettre en place, et lles ne peuvent pas etre integrees a la securite de
Windows.
- Les fonctionnalites d'Access au niveau des sauvegardes est inexistante.

A mon avis, les deux dernieres raisons "pesent" 75% du poids de la decision.
Si les donnees ne peuvent etre securisees contre la perte, le risque est
trop grand.

Oui, je sais, il est possible de mettre en place des schemas tordus de
sauvegarde, mais l'effort investi la dedans (souvent apres-coup) est
completement ridicule. De plus, pour en arriver a un niveau de protection
des donnees au point ou l'on n'a _jamais_ plus d'une seule transaction
perdue, il faut se lever de bonne heure avec Access. Alors qu'avec SQL,
c'est (presque) automatique, en faisant une installation et une
configuration soignee.

Et puis, les erreurs de conception ou de programmation ont le même effet
avec Access ou avec SQL server,

les temps de réponse sont désastreux.

(Sur l'air de la Mere Denis) Ca c'est bien vrai, ca!!!

Ne vous méprenez pas, j'adore SQL server, mais a-t-on besoin d'un
marteau-pilon pour écraser une mouche ?

Eh bien moi maintenant, je dis un peu le contraire: j'aime bien Access, mais
quand on veut developper des applications propres, pour une utilisation
professionnelle, il vaut mieux utiliser un outil plus adapte aux exigences
d'une application moderne.
Pour acceder aux donnees depuis n'importe ou, a partir de n'importe quel
gadget (portable ou non), sur Windows ou pas, il faut quelque chose de plus
flexible.

Et je n'ai pas encore commence a parler des outils qui sont autour de SQL
Server: les services d'analyse, le DTS (Services de Transformation des
Donnees), XML, Index Server, Full Text Indexing, Reporting services...

Access pour moi est maintenant devenu un outil de developpement de
prototypes rapides. En general, les gens qui insistent pour l'utiliser dans
une entreprise sont a peine mieux que des utilisateurs de Lotus 123...
;-)