Newsgroup: it.comp.appl.access
Titolo: Prestazioni di Access

Dall'help in linea:
------------
Utilizzare dei filtri o delle query per limitare il numero di record
visualizzati in una maschera o in un foglio dati. Un numero inferiore di
dati verrà trasferito in rete.
------------
Questa frase mi lascia perplesso.
qualcuno ha gia' esaminato cosa possa esattamente significare?
Sib


A me è sempre sembrata una cosa ovvia.
Ciao, Sandro.
--------------------------------
Inviato via 
http://usenet.libero.it


Spesso le applicazioni create con Access sono suddivise in due parti
chiamate Front End (FE) e Back End (BE).
In generale sono due file .mdb o mde, il FE contiene l'interfaccia utente,
mentre il BE i dati.
Supponiao la situazione in cui FE e BE non siano memorizzati sullo stesso
PC, ma in una rete aziendale, in questo caso i dati vengono trasferiti tra
FE e BE tramite una rete locale o anche geografica.
Può nascere la necessità di migliorare le prestazioni, nel caso in cui le
tabelle contengano molti dati.
La frase da te citata, quindi serve a precisare che nel caso l'origine dati
di una maschera sia una Query la quale filtra secondo vari criteri i dati,
sulla rete verranno trasferiti solo i dati già filtrati e non l'intera
tabella.
Spero di essere stato chiaro.
Ciao, Antonio.

"Sib" <si...@SPAMiol.it> ha scritto nel messaggio
news:MHCL9.37032$lV4.1...@news2.tin.it...

Che nei casi di database in rete, sulla rete viaggia solo il risultato delle
query (e quindi una quantità di dati ridotta) rispetto ai dati completi
Forse...
Antonio

"Sib" <si...@SPAMiol.it> ha scritto nel messaggio
news:MHCL9.37032$lV4.1...@news2.tin.it...

Se il BE è un database client-server vero
Se il Be è un file mdb mi sembra una fesseria, le query vengono sempre
eseguite in locale
AEOM

"Sib" <si...@SPAMiol.it> ha scritto nel messaggio
news:MHCL9.37032$lV4.1...@news2.tin.it...

Tutto verissimo e non è affatto una fesseria come ha scritto qualcuno.
Gli indici servono proprio a questo!
Ciao.

 ha scritto nel messaggio
news:VyEL9.23755$TC5.7...@twister1.libero.it...

cosa centrano gli indici con la parte where di un'istruzione sql.
se in un archivio nomi hai 400.000 righe e una maschera che ti mostra i nomi
che iniziano per A (suppooniamo siano 20), tutti i 400.000 nomi vengono
trasferiti dalla rete sul pc locale, e lq query viene eseguita in locale
Ribadisco che secondo me è una fesseria
Attendo di essere smentito ma non lo credo.
AEOM

 ha scritto nel messaggio
news:aNDL9.23542$TC5.7...@twister1.libero.it...

Se il BE è access, in rete passa tutto l'archivio
AEOM

 Attendo di essere smentito ma non lo credo.
Esempio:
1) Crea una tabellina di movimenti di magazzino: Data, Cod. Art.,
ImportoRiga, etc.
2) Genera un indice a duplicati ammessi sul campo Data.
3) Genera a codice 1.000.000 di records con un range di date (distribuite
razionalmente ed equamente come da realtą) che vanno dallo 01/01/2002 a
oggi.
4) Crea una query sulla tabella con un parametro di tipo Data.
5) Se imposti come parametro la data d'inizio anno, verranno selezionati
tutti i records (con enorme spreco di risorse di rete).
6) Se imposti come parametro di selezione una settimana fa verranno
selezionati istantaneamete pochi records.
A questo servono gli indici.
Concludendo: č ovvio che con JET non puoi creare query pass-throught, ma č
altrettanto vero che sfuttando come si deve l'indicizzazione l'affermazione
dall'Help di Access č sacrosanta.
Ciao.


ciao

 Questo è falso,  mi ci giocherei il libretto della macchina
No comment.
Ciao.

 ha scritto nel messaggio
news:KFEL9.28511$ab2.9...@news1.tin.it...

No aspetta, sei rimasto un po' indietro.
Tutto questo è vero fino all'A97.
Dal 2000 in poi è stata utilizzata la tecnica dell SQLServer per cui le
query sono eseguite in remoto e viene trasferito solo il risultato.
Ci sono un sacco di articoli in merito, controlla!
Antonio

 ha scritto nel messaggio
news:ysFL9.24215$Ou4.7...@twister2.libero.it...

questa mi è nuova.... e allora MSDE cosa l'hanno messo a fare?
AEOM

 questa mi è nuova.... e allora MSDE cosa l'hanno messo a fare?
Infatti...
Prova a cercare su deja questo thread che proprio io postai tanto tempo
fa... e la successiva risposta di Stefano Radice
Access 2000 =~ SQL server?
11/03/2000
Antonio

 dall'Help di Access è sacrosanta.
In buona sostanza, tu dici che filtrando in base a un campo indicizzato
access non si scarica tutto il recordset ma cerca la posizione dell'indice
in modo da andare a leggere solo la porzione di tabella che interessa.
Mi sembra una buona spiegazione, in effetti lo avevo immaginato (era l'unica
possibilita' di limitare, da remoto, la lettura dei record) ma sull'help
quella frase laconica buttata li' senza ulteriori chiarimenti mi sembrava
piu' un errore di traduzione che altro.
Ciao
Sib

 A me è sempre sembrata una cosa ovvia.
probabilmente perche' non hai approfondito bene il funzionamento di Access.
Ciao
Sib

 Spero di essere stato chiaro.
Antonio, sei stato chiarissimo e ti ringrazio, ma il problema che mi ponevo
e':
come fa un database file sharing come access a limitare il numero di record
letti se comunque il filtro lo deve applicare in locale e quindi *dopo* aver
gia' letto i record stessi?
Sib

 Forse...
Pare sia cosi'.
L'ipotesi buona l'ha fatta oscar.
Ciao
Sib

 Per effettuare ricerche in un file indice?
Personalmente penso che la tecnica migliore sia quello della bisezione.
cut
Ragazzi vogliamo camarci?
ultimamente noto la tendenza ad una eccessiva aggressivita'.
Non sara' l'avvicinarsi delle feste?
Sib

 ultimamente noto la tendenza ad una eccessiva aggressivita'.
Hai ragione: ho esagerato nel tono e chiedo scusa a chi si sia sentito
offeso.
Ciao.

 potenzialità del motore dell'SQL server?
Dipende: se usi Access 2000 con SQL Server sì, se continui a usare Access
con il BackEnd sul server no (vista la tua enorme esperienza e il tuo enorbe
bagaglio tecnico, quest'ultima precisazione non serviva di certo :)  )
Tieni presente che con il 97 potevi fare delle query pass-thru e SQL Server
eseguiva le query per te: Nella versione 2000, questo è automatico.
....."
se il BE e un file mdb le query vengono fatte in locale
qui sopra si parla di sql server.
Ma scusa... creati un archivio BE MDB, caricaci 1.000.000 di record da
100byte, creati una maschera che poggia su una query che estrapola un solo
record, aprila sullo stesso pc e aprila su un pc in rete con gli archivi
collegati e guarda che differenza... ti sembra che per la rete siano passati
solo 100 byte?
Rifai l'esperimento con BE MSDE e guarda che differenza
AEOM

 piu' un errore di traduzione che altro.
Già, e ho postato pure un esempio _che secondo me si può implementare
rapidamente_  per gli increduli ;-)
Comunque mi fa piacere riscontrare da parte tua interesse e voglia di
approfondire senza preclusioni una questione piuttosto importante.
Ciao.

 solo in ambiti MONOUTENTI
Beh! ora non esageriamo.
Io ho molte installazioni con 4  e 5 utenti che lavorano forte senza alcun
problema.
Sib

 Sib
Su questo mi dovrei documentare meglio, a rigor di logica mi viene da
pensare che qualunque filtro sia applicato in locale poichč in teoria il BE
potrebbe risiedere su un server linux il quale non ha nessun supporto per il
motore jet e quindi non č in grado di operare come *server*.
Potresti dirmi dove hai reperito quella documentazione sotto che voce
dell'help?
Antonio.

"Sib" <si...@SPAMiol.it> ha scritto nel messaggio
news:IpGL9.29086$ab2.9...@news1.tin.it...

Ciao Sib, la clausola Where delle query e i filtri vengono ottimizzati
prendendo in considerazione i campi indice quindi se un indice è ben
strutturato Access non prende in esame tutti i record .
Forse nella sezione dell'help manca il collegamento all'informazione sugli
indici.
Vedi Help alla sezione
-----------------------------------------------
Informazioni sull'indicizzazione di campi e record in un database di Access
Se si prevede di effettuare frequentemente ricerche o ordinamenti
utilizzando due o più campi alla volta, è possibile creare un indice per
quella combinazione di campi. Se ad esempio si impostano spesso dei criteri
per i campi Cognome e Nome nella stessa query, è utile creare un indice
multicampo su entrambi i campi.
Quando si ordina una tabella in base a un indice multicampo, l'ordinamento
viene eseguito inizialmente in base al primo campo definito per l'indice. Se
sono presenti record con valori identici nel primo campo, l'ordinamento
viene poi eseguito in base al secondo campo definito per l'indice e così
via.
È possibile includere fino a 10 campi in un indice multicampo.
------------------------------------------------
Ciao Giorgio.

 dell'help?
Non saprei sull'help, comunque considera che per ottenere l'elaborazione
remota dei record si usano i driver odbc, le query pass-trought, ecc.
Sib

 ha scritto nel messaggio

Precluso giammai.
"farmi convinto" si'.
Infatti ho verificato creando un db con 1.000.000 di record remoti, una
maschera che aptre tutta la tabella e un'altra che apre gli ultimi 100.000
record (WHERE id>900.000) . ho usato la funzione timer come marcatempo e ho
forzato lo spostamento all'ultimo record nell'evento apertura.
il record visualizzato e' quindi il milionesimo in entrambi i casi, ma nel
primo caso impiego 95 centesimi di secondo, nel secondo soltanto 9.
in buona sostanza e' certo dal mio punto di vista, che access applichi i
criteri dell'opzione WHERE sull'indice, se esiste.
Sib

 probabilmente perche' non hai approfondito bene il funzionamento di
Access.
Probabilmente se la cosa è sembrata ovvia a me, che di Access e database non
capisco una minchia, a maggior ragione potrà esser sembrato ovvio amche a
M$.
Ciao, Sandro.
--------------------------------
Inviato via 
http://usenet.libero.it

 Se il BE è access, in rete passa tutto l'archivio
Non è vero. Ho appena provato con un file-server smb con access xp, e la
maschera ci mette sostanzialmente lo stesso tempo a comporsi.


 criteri dell'opzione WHERE sull'indice, se esiste.
Facendo una maschera filtrata su un campo non indicizzato ha impiegato 50
centesimi di secondo.
Questo vuol dire che comunque una certa ottimizzazione avviene sempre.
Sib


la tua risposta dice:
a2k =~ sql server
mi sta bene.
e il discorso può filare se ho a2k installato sia sul client che sul server
(anche se non ne sono convinto...)
ma se ho access solo sul client e sul server ho magari linux con samba,
continui a dirmi che una parte delle query viene gestita da samba?
io non credo proprio...
linux non riconosce nemmeno il formato mdb! (lo so, ci sono tools che lo
permettono, ma facciamo finta di non averli installati...)
se usi le condivisioni (aka shares o chiamale come vuoi) per accedere a dei
files mdb (ripeto, il BE è composto da uno o più files MDB/MDE, non c'è
nessun DBMS di nessun tipo, marca, età o altro), è sempre e solo il client
che si occupa di filtrare tutti i record, che deve quindi avere in locale,
cioè deve prima ottenere in locale una copia dei dati per poi filtrarli.
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (
http://www.grisoft.com
).
Version: 6.0.427 / Virus Database: 240 - Release Date: 06/12/2002

 Ciao, Sandro.
il file server era molto carico?
quanti accessi contemporanei?
velocità della rete?
anche io, quando faccio prove a casa, non noto differenze tra accesso a un
mdb su share e uno in locale, però ho una rete switchata 100mb con samba su
linux e io sono l'unico utente...
prova in produzione, magari con 4 o 5 utenti contemporaneamente e poi ne
riparliamo!



mi sono letto il resto del thread...
intendi forse che la capacità di leggersi solo gli indici invece che
l'intera tabella rende a2k~sql?
mi sa che la vediamo un pò diversamente!
:-))



driver odbc e query pt non sono sufficienti per ottenere l'elaborazione
remota.
serve anche un dbms remoto, altrimenti non funzica
:-)
un esempio?
crea una connessione odbc a un file excel su una share e poi vediamo che
elaborazione remota t fa!


 riparliamo!
Prova con netstat.
Prova a vedere il traffico dei pacchetti sull'iconetta sul desktop.


solo in ambiti MONOUTENTI
Le solite esagerazioni...
Ciao, warp


alt!
nel tuo post parlavi di velocità di apertura, non di traffico in rete...
:-)
ho capito anch'io (adesso) che a2k e sup ottimizzano le letture in qualche
maniera leggendo solo gli indici, generando meno traffico.
ho però risposto a una tua osservazione riguardante un argomento diverso.


criteri dell'opzione WHERE sull'indice, se esiste.
IMHO:
Caso 1)
8 centsec = trasferimento file via lan
87 centsec = elaborazione 1 milione di record.
Caso 2)
8 centsec = trasferimento file via lan
1 centsec = elaborazione 100 mila record.
Non dimenticare che sei in una maschera, che ha i suoi luuunghi tempi di
elaborazione. Forse aprendo un recorse la differenza non sarebbe stata cosi'
macroscopica.
Casomai installa un programmino che misura i byte che passano sulla sk di
rete rifai la prova.
Saluti.
Luciano

senza avere le idee chiare.
L'esempio che porti tu e' significativo se misuri il traffico di rete,
mentre a me sembra che tu abbia dedotto che il traffico e' minore in virtu'
di un tempo di elaborazione minore. Se hai una lan a 100Mb la differenza con
localhost la noti appena. Io credo che la tua query sarebbe comunque piu'
veloce perche' usa gli indici ed evita il tablescan, non perche' genera
minore traffico di rete.
Hai effettivamente controllato che passano meno byte sulla lan?
Saluti.
Luciano

query sono eseguite in remoto e viene trasferito solo il risultato.
sqlSERVER appunto...al Jet chi glie lo serveR il risultato scremato?
Saluti.
Luciano

 ha scritto nel messaggio
news:ato3kc$17gf$1...@newsreader1.mclink.it...

Finalmente una conferma a quello che dico io!!!! pensavo di essermi
rincittrullito tutto in un colpo!!!
AEOM

 :-)
ma caro paolo,
la cosa mi sembrava piuttosto scontata.
Se mi metto a usare odbc e query pt con le difficolta' che questo comporta,
l'unico buon motivo e' quello di essere collegati a un dbms remoto.
Ciao
Sib

 rete rifai la prova.
Luciano, All Eyez On me ... provate anche voi a fare il test che ho
consigliato e valutate coi vostri occhi gli effetti sul traffico di rete
prodotti da un select su un indice ;-)
Ripeto, non è il caso di confrontarsi a opinioni, valutiamo i fatti
serenamente.
Ciao, Oscar

 rincittrullito tutto in un colpo!!!
Ma no!
non ti sei rincitrullito!
pero' partiamo dalla frase dell'help: "meno traffico di rete" afferma.
Dato che effettivamente ho verificato un tempo minore diamoci una
spiegazione.
una tabella indice e' ordinata.
quindi il jet non ha bisogno di leggerla tutta per trovare il record 900.000
(vedi mio esempio nel post precedente) ma usera' un metodo rapido (bisezione
o altro) e una volta trovato il valore cercato, preleva i puntatori ai
record da restituire e se li va a pescare a colpo sicuro (accesso random).
in questo senso il traffico di rete e' molto minore perche' scarica solo i
record rispondenti ai criteri.
Luciano, il tempo di elaborazione maschera e' fisso e l'ho cronometrato in 1
centesimo di secondo (il tempo che impiega a mostrare il primo record), ma
la richiesta di spostarsi all'ultimo record, che ho inserito nell'evento
apertura, costringe la maschera ad attendere l'arrivo di tutti i record,
ecco perche' ritengo che sia effettivamente minore il traffico di rete.
Sib

 ecco perche' ritengo che sia effettivamente minore il traffico di rete.
e non trascuriamo l'altro test che ho fatto, e cioe' il filtro su un campo
non indicizzato. anche qui il tempo di accesso e' stato minore ma non
altrettanto efficiente quanto il filtro sul campo indicizzato e io
spiegherei la cosa dicendo che la ricerca ha richiesto che jet scorresse
tutti i record  ma solo leggendo il campo filtrato per recuperare
interamente solo i record rispondenti ai criteri.
Sib


E' come aprire uno schedario e leggere le etichette delle varie cartelle per
prendere solo quelle che interessano (nel caso del campo indicizzato) o come
aprirle e leggere solo il contenuto di un solo specifico foglio all'interno
per decidere se ci interessa oppure no (nel secondo caso)
Sib


Allora: riporto la frase dell'help da cui è nato questa discussione:
Utilizzare dei filtri o delle query per limitare il numero di record
visualizzati in una maschera o in un foglio dati. Un numero inferiore di
dati verrà trasferito in rete.
Mi sembra che non si parli di indici, si parla del fatta che la where
dell'sql mi fa passare meno record in rete.
e questo non è vero!
Non capisco cosa centrino gli indici in questa discussione.
AEOM

 serenamente.
Daccordissimo. Io ai fatti ci credo e credo ai risultati del tuo test
perche' non vedo per quale motivo dovresti raccontare balle. Pero' non ci
hai detto come hai fatto questo test. Allora ti richiedo, perche' all'altro
mio messaggio non hai risposto: hai *effettivamente* monitorato il traffico
di rete ho hai *dedotto* che fosse minore?
Quanti MB e' il tuo db? Quanti MB passano con la prima query e quanti con la
seconda? Quanti MB generano le due query salvate su file?
I fatti sono questi e la serenita' non vedo perche' dovrebbe
abbandonarci!:-)
Saluti.
Luciano

 non indicizzato.
Sib, tutti i test che hai fatto lasciano Access completo padrone della
situazione, e le variabili in gioco sono tante percio' IMHO non c'e'
certezza di quanto si va affermando. L'unico modo per verificare con
sicurezza assoluta che il traffico di rete sia effettivamente minore e'
monitorarlo.
Saluti.
Luciano

 rincittrullito tutto in un colpo!!!
Non vi e' esclusione automatica ed vicendevole dei due enunciati....:-))))
Saluti.
Luciano

 seconda? Quanti MB generano le due query salvate su file?
Luciano, fai personalmente dei tests sulla questione, poi se avrai voglia ne
riparliamo.
Ciao, Oscar
P.s: sono molto, molto sopreso del tuo stupore.

 Non capisco cosa centrino gli indici in questa discussione.
Mah!
Ciao, Oscar


beh, effettivamente sono stato un tantino pignolo...


 monitorarlo.
Il mio monitor di rete (lavoro su W2000 server) dice quanto segue:
Maschera non filtrata (1.000.000 di record restituiti): 0,8 sec ca, 100%
della banda
Maschera filtrata su campo indicizzato(100.000 record restituiti): 0,1 sec
ca, 90% della banda
Maschera filtrata su campo non indicizzato(100.000 record restituiti): 1,2
sec ca, 100% della banda
(lan 100Mbit)
in questo senso hai ragione tu per quanto riguarda il filtro applicato su
campo non indicizzato mentre nell'altro caso direi proprio che diminuisce (e
anche notevolmente) il traffico di rete.
Ciao
Sib

 ha scritto nel messaggio
news:jHYL9.27476$Ou4.8...@twister2.libero.it...

Va be ci rinuncio, jet è diventato client-server.
ciao, AEOM

 P.s: sono molto, molto sopreso del tuo stupore.
Chiamasi richiesta di dimostrazione scientifica!:-)
Saluti.
Luciano

 anche notevolmente) il traffico di rete.
A me sembra lo stesso test di prima, hai fatto lavorare Access che potrebbe
aver impiegato parte del tempo a gestire i dati che riceve dalla LAN. Senza
contare che i tempi di risposta di una LAN sono influenzati da molti
fattori. Se ad esempio sei connesso ad un hub anziche' ad uno switch sai
meglio di me che che la misurazione del tempo lascia li tempo che trova.
Ma perche' non la fate 'sta prova che vi suggerisco io? Installate un
programmino che conta i byte che passano per la scheda di rete e vediamo. Se
e' vero che si riesce a fare quello che state cercando di dimostrare saremo
tutti ben felici di aver appreso una nuova caratteristica di Access.
Su che parte dell'help l'hai letta quella frase?
Saluti.
Luciano

 Va be ci rinuncio, jet è diventato client-server.
Cerca di essere più serio e leggi quello che scrivo.
Ciao.

 e ci ragioniamo sopra.
E io continuo a rispondere: prova con le tue manine, poi ne riparliamo.
Qui si parla d'informatica, non di politica.
Ciao, Oscar

 tutti ben felici di aver appreso
 >una nuova caratteristica di Access.
Quindi secondo te un gestore ISAM sarebbe una nuova caratteristica di JET?
Andiamo bene.
Oscar


Per favore rispondi a questa domanda :
hai un archivio SENZA ALCUN INDICE (ripeto sulla frase dell' Help
incriminata non si parla di indici)
fai una query da un client su questo archivio
secondo te in rete vengono trasferiti solo i record risultanti dalla query o
tutto l'archivio?
ciao,
AEOM

 incriminata non si parla di indici)
Prendo atto della tua asserzione.
Dal canto mio riporto un'interpretazione di Sib, verosimilmente corretta,
sul testo dell'Help:
(CUT)
"ma sull'help
quella frase laconica buttata li' senza ulteriori chiarimenti mi sembrava
piu' un errore di traduzione che altro"
Ciao, Oscar

 ha scritto nel messaggio
news:vTZL9.27703$Ou4.8...@twister2.libero.it...

Ancora una volta non rispondi alla mia domanda, mi sembri un politico
(ovviamente in tono scherzoso)
ciao, AEOM

 Su che parte dell'help l'hai letta quella frase?
cerca: migliorare prestazioni,
seleziona la voce: migliorare le prestazioni di un database access
espandi la dicitura: migliorare le prestazioni delle tabelle collegate
Ciao
Sib

 (ovviamente in tono scherzoso)
Mi complimento per il tono corretto della vostra conversazione ;-)
dalle prove che ho fatto, "senza alcun indice" va peggio di peggio, mentre
con l'indice va meglio, ma molto meglio.
Ciao
Sib

 Qui si parla d'informatica, non di politica.
mazza! che 3d che ho aperto, giuro che non era mia intenzione, volevo solo
capire il senso di quella frase.
Comunque ribadisco che, fermo restando che jet viene eseguito in locale, fa
una cosa molto semplice.
invece di scaricare la tabella e poi filtrarla, cerca nell'indice la
posizione che gli interessa (e questa e' una ricerca veloce dato che
l'indice e' ordinato) quindi acquisisce i puntatori ai record che deve
scaricare e quindi va a leggere (sempre dal pc locale, intendiamoci)
direttamente i record che gli interessano, non perche' dall'altro lato ci
sia qualcosa che viene eseguito, ma perche' nella lettura sul file server
legge solo i record che gli interessano (avendone i puntatori)
Sib

 Sib
Premetto che come hobbysta non ho esperienza di database multiutenza gestiti
in rete e che non sono in grado (nè ho voglia) di effettuare test di
misurazione del traffico in rete.
Però per mia cultura sto seguendo questo thread, e tra le altre cose sono
andato a leggere sull'help in linea per intiero l'argomento dal quale è
stato estrapolato il brano che ha generato il dibattito in corso.
In calce a questo messaggio (se a qualcuno può tornare utile) ho trascritto
per intiero l'argomento dell'help intitolato Ottenere prestazioni ottimali
con le tabelle collegate, che contiene la frase "incriminata".
Preciso che il brano è tratto dall'help in linea di Access 97.
A mio avviso sembrerebbe che nel brano si scrive che l'ottimizzazione
avviene a prescindere dall'uso degli indici (i vantaggi dell'uso degli
indici eventualmente si sommerebbero).
Non mi sembra che nell'articolo si dica che l'ottimizzazione si ha solamente
usando database SQL e/o Access2000.
Nell'articolo non si fa per niente riferimento all'uso di query
pass-through.
Tenuto anche conto del tenore delle altre frasi scritte nell'articolo, mi
sentirei di escludere che la frase "incriminata" contenga vizi di
traduzione.
Per quanto ho scritto sopra non vedo alcun motivo per mettere in dubbio
quanto scritto sull'help circa le cose da fare per ottimizzare le
prestazioni di un database che usa tabelle collegate, quindi non vedo perché
alcuni frequentatori del NG si strappino i capelli e si straccino le vesti
gridando all'eresia.
L'unica cosa che si potrebbe opinare è che i vantaggi che si ottengono dal
rispetto di tali regole non siano necessariamente rilevanti.
Ecco il testo dell'argomento di cui accennavo qui sopra:
======================================
Ottenere prestazioni ottimali con le tabelle collegate
Sebbene sia possibile utilizzare delle tabelle collegate come delle normali
tabelle di Microsoft Access, si noti che queste non si trovano realmente nel
database in uso. Ogni volta che si visualizzano dei dati di una tabella
collegata, vengono recuperati dei record da un altro file. L'operazione può
richiedere del tempo, soprattutto se la tabella collegata si trova su una
rete o in un database SQL.
Se si sta utilizzando una tabella collegata su una rete o in un database
SQL, seguire le istruzioni riportate di seguito:
· È possibile migliorare notevolmente le prestazioni quando si aprono il
database principale e le tabelle e le maschere, forzando il database
collegato in modo che rimanga aperto. A tal fine, creare una tabella vuota
nel database collegato e collegarla al database principale, quindi
utilizzare il metodo OpenRecordset per aprire la tabella collegata. Ciò
impedisce che il modulo di gestione di database Microsoft Jet apra e chiuda
più volte il database collegato e crei e distrugga il file con estensione
ldb associato.
· Visualizzare esclusivamente i dati necessari. Non andare alla pagina
precedente e a quella successiva del foglio dati se non è necessario.
Evitare di andare all'ultimo record di una tabella di grandi dimensioni. Se
si vogliono aggiungere dei nuovi record ad una tabella di grandi dimensioni,
utilizzare il comando Immissione dati del menu Record, per evitare il
caricamento in memoria dei record esistenti.
******************
· Utilizzare dei filtri o delle query per limitare il numero di record
visualizzati in una maschera o in un foglio dati. Un numero inferiore di
dati verrà trasferito in rete.
******************
· Nelle query che comprendono delle tabelle collegate, evitare l'utilizzo di
funzioni nei criteri della query. Non utilizzare, in particolare, le
funzioni di aggregazione sui domini come, ad esempio, DSum. Quando si
utilizza una funzione di aggregazione sui domini, per eseguire la query
vengono recuperati tutti i dati della tabella collegata.
· Se le aggiunte di record ad una tabella collegata sono frequenti, creare
una maschera per l'aggiunta di record impostando la proprietà ImmissioneDati
a Sì. Quando si apre la maschera per immettere dei nuovi dati, nessuno dei
record esistenti viene visualizzato. Questa impostazione di proprietà
consente un risparmio di tempo, poiché non è necessario recuperare tutti i
record della tabella collegata.
· È bene tener presente che più utenti contemporaneamente possono tentare di
utilizzare una tabella esterna: occorre, quindi, evitare di bloccare dei
record più del tempo necessario.
==========================
--
Roberto
---------------------------------------------
il Sito Comune di it.comp.appl.access:
http://www.sitocomune.com
---------------------------------------------


Ho deciso di non postare più su questo argomento, ho letto l'intero capitolo
della quida in linea e ribadisco che non si parla mai di indici ma di query
no nvedo quindi che cavolo serva testare query con indici o senza indici.
L'utilità degli indici è fuori discussione.
Ribadisco la mia idea, con jet come BE l'intero archivio/i oggetti della
query vengono trasferiti in locale con il relativo carico di rete.
Adios
AEOM

 Sib
A me fa lo stesso effetto.
Correggimi se sbaglio, ma il filtro non viene eseguito in locale dopo aver
ricevuto tutti i record ?
Mi sembra piu' un affermazione per DB su SQL server.
Giuliano

 Precisamente passanno ca. 20Kbyte nel caso 1, 5K nel caso 2 e 30K nel caso
3
Sib, nel tuo post precedente parlavi di tempo e % occupazione banda non di
Mbyte. Ora che hai postato questi valori la cosa e' piu' chiara. Ho fatto
anche io qualche prova ed ho ottenuto gli stessi risultati, ovvero,
miglioramento con indici, nessun miglioramento senza. Ho anche notato che
lanciando  un SELECT * FROM tuatabella la prima volta ci mette 7 sec le
altre <1. Parallelamente c'e' un aumento dell'utilizzo delle risorse del
computer. Questo vuol dire che evidentemente riesce a fare determinate
operazioni in locale. Come, rimane poco chiaro.
Comunque, lanciando la query da codice e da query builder le prestazioni
sono notevolmente differenti, il che conferma che un monitoraggio da
maschera non e' significativo.
Saluti.
Luciano

 Qui si parla d'informatica, non di politica.
Caro Oscar, di cosa si parla qui lo sappiamo benissimo tutti avendo alle
spalle anni di frequentazione di questo NG. Quello che invece non sappiamo,
o almeno io non riesco a capire, e' perche' tu senta la necessita di
scaldarti tanto e prenderla come un fatto personale. Ieri ti sei alterato
con AEOM al punto da ritenere opportuno, a fine giornata, porgere le tue
scuse pubblicamente, e anche oggi il tono dei tuoi post non e' tra i piu'
pacati. Problemi tuoi, comunque.
Per restare al tema del thread, ho fatto anche io 'sto bel testarello con 1
milione di record in remoto ed effettivamente sembra che in qualche modo gli
indici riescano a funzionare su tabelle remote. L'assioma di partenza pero'
era un altro e cioe': mettere un WHERE riduce il traffico di rete. Il che
dal mio test, e mi sembra anche da quelli di Sib e Paolo Opg, non si evince
proprio.
Saluti.
Luciano

 legge solo i record che gli interessano (avendone i puntatori)
In sostanza stai dicendo che un file server e' in grado di esaudire una
richiesta formulata in questo modo: dammi quel file, ma non tutto, solo dal
bye x al byte y. Francamente non so se cio' sia possibile o no.
Saluti.
Luciano

 bye x al byte y. Francamente non so se cio' sia possibile o no.
Che c'č di cosě strano?
E' l'applicazione che decide quando e cosa leggere di un file.
Supponi di volerti fare un programmino che ti modifichi un byte in un file
da un giga. Non vai a beccarti QUEL byte e te lo modifichi? Mica ti devi per
forza leggere tutto il file? Ma se non ti leggi tutto il file, il
file-server cosa dovrebbe inviarti sulla rete?
Ciao, Sandro.
--------------------------------
Inviato via 
http://usenet.libero.it

 qualcuno ha gia' esaminato cosa possa esattamente significare?
La cosa mi si fa piuttosto complicata.
A parziale rettifica di un mio post precedente, vi do i dati corretti
relativi al traffico di rete che ho riscontrato:
Situazione:
BE 720Mb
Tabella con 1000000 di record.
tutta la tabella: 7,3Mb trasferiti in rete - 1,7 sec
100.000 record filtrati su campo indicizzato: 890Kb trasferiti in rete - 0,1
sec
100.000 record filtrati su campo non indicizzato: 68Mb trasferiti in rete -
7,5 sec
qualcosa non mi torna.
Se access scarica il recordset e poi lo filtra, nella peggiore delle ipotesi
il traffico di scaricamento della query filtrata su campo non indicizzato
dovrebbe essere pari a quello di tutta la tabella. invece la proporzione e'
di 1 a 10!
Boh
Sib

 Adios
Comprendo il tuo punto di vista, ma nulla di strano che l'help parlasse a un
pubblico "inesperto" e quindi si limita a dire che le prestazioni migliorano
in generale. per quanto abbia verificato alcune anomalie.
Sib

 maschera non e' significativo.
Forse in termini di tempo, ma in termini di traffico non cambia molto.
ad ogni modo dai una letta al mio ultimo post, c'e' qualcosa che mi lascia
perplesso.
Ciao
Sib

 Saluti.
Ciao
Sib


la pensavo anche io così.
però ho fatto qualche prova...
fermo restando che un dbms è un'altro pianeta, pare che se esegui una select
su  un campo indicizzato, si riduca il traffico sulla rete. ed
effettivamente facendo qualche prova mi è proprio successo questo.
quello che dici tu (intero db in locale) l'ho verificato nel caso di select
su campo non indicizzato: monitorando la rete ho un traffico pari a quello
generato dal trasferimento dell'intero mdb be.
il perchè mi sfugge, ma pare proprio sia così!
:-)


 (ovviamente in tono scherzoso)
Non ti rispondo perchè il *mio* pensiero è stato esposto nitidamente sin dai
primi post.
Ho risposto a Sib in questo modo (al di là dell'eccesso di veemenza):
"Tutto verissimo e non è affatto una fesseria come ha scritto qualcuno.
Gli indici servono proprio a questo!"
Cosa ne deduci?
... senza contare poi i post successivi.
Ciao, Oscar

 legge solo i record che gli interessano (avendone i puntatori)
L'analisi è correttissima e la conseguenza è un abbattimento del traffico di
rete.
Ciao.

 proprio.
Come ho già scritto, do per scontato che il campo sui cui si effettui il
WHERE sia indicizzato.
Diversamente solo con un Server di database si può far forzare l'esecuzione
sulla macchina Server.
Ciao, Oscar.
P.S. comunque pure io oggi mi sono beccato del politico, quindi non te la
prendere ;-)

 sulla macchina Server.
... abbattendo conseguentemente il numero di pacchetti inviati attraverso la
rete per la visualizzazione dei risultati.
Ciao.



Mi sembra una cosa dell'altro mondo , mi vuoi dire che se passa WHERE
su un campo non indicizzato Jet va in crisi e continua a richiamare il
BE.
Meno male che quando mi ero studiato SQL standard, si diceva che
WHERE, in una query,  era la prima condizione che passava per
ottimizzare le risorse, ma per Jet, se mancano gli indici , manca
tutto.
Ma sei sicuro di questi dati , Sib ? 68 Mb ? ma cosa se ne fa ?
Per curiosità che SELECT  hai fatto ? Richiamava più tabelle ?
Cmq questo thread ha messo in luce cose nuove: da appendere in bacheca
!!!
E' un anno che sento dire che Jet non riesce a gestire bene queste
cose e invece guarda che sorprese.
Ciao. Fabrizio.
(Access XP (sp2), Win ME, P4 1Ghz, 320 RAM)


che non hai letto il post iniziale, o quanto meno non attentamente
:-)
come ti hanno già fatto notare, nel post iniziale non si fa nessun cenno a
indici di nessun tipo.
siamo tutti d'accordo che con gli indici la situazione migliora nettamente,
ma purtroppo nella frase citata dall'help non se ne fa nessun cenno...
a questo punto, mi sa che è un pò 'colpa' dell'help in linea (o quanto meno
dell'ambiguità del pezzo riportato), che dà un suggerimento incompleto.
cioè dice che su un be in rete, una query su campi indicizzati migliora le
prestazioni, ma non che una query su campi non indicizzati, non cambia la
situazione.
tra le altre cose, dalla frase riportata, non si capisce se il be è un mdb,
un file di testo, una tabella excel, un dbms...


 un file di testo, una tabella excel, un dbms...
solo perche' l'ho estrapolato dal suo contesto. Si riferisce alle tabelle
collegate.
Sib

 cose e invece guarda che sorprese.
sono lieto che il mio dubbio sia stato condiviso.
Ciao
Sib

sono lieto che il mio dubbio sia stato condiviso.
Ti dirò , quando hai buttato lì quella frase , avevo tirato dritto ( è
cmq una cosa che ancora non faccio e che non ero interessato a fare
con Access e poi sapevo altro ) , ma visto poi il numero di post , mi
sono fermato a leggere meglio: ueh che sorprese, quasi quasi a questo
punto, per quello che mi serve , posso usare Access.
Vabbuò passo e chiudo.
Bravi ragazzi !!


 Che c'č di cosě strano?
Ora che lo so, nulla!:-)
Saluti.
Luciano

 WHERE sia indicizzato.
Io invece do per scontato che si ragioni di cio' che si e' iniziato a
ragionare, ovvero filtri su tabelle remote.
Saluti.
Luciano

 abbiano apportato modifiche.
E' la prima prova che ho fatto: ho modifcato un record in locale e ho
rilanciato al query da remoto. Risultato: atlee quale a prima della
modifica.
Ho provato anche ad aggiungere da locale un record all'indice e poi a
rilanciare la query: rimane veloce. ne dedurrei che per prima cosa si
ciuccia l'indice (che nel file occupa la posizione dal byte x al byet y) poi
cerca li' e solo allora chiede i dati, ossia dal byte n al byte n+1, dal
byte l al bye l+1 e cosi via per ogni record.
Non ho pero' avuto tempo di fare altre prove tipo usare un indice multicampo
o lanciare un query con join.
Ciao.
Luciano

 siamo tutti d'accordo che con gli indici la situazione migliora
nettamente,
Invece non siete tutti d'accordo.
O meglio, molti (te compreso mi pare) sono d'accordo solo dopo aver testato
la faccenda o aver letto i tests di Sib.
Ciao, Oscar

 Luciano
Ciao
Sib