Newsgroup: it.comp.appl.access
Titolo: Access in ambiente di rete... lento, lento, lento!!!

Un mio conoscente usa access in rete (ha un db con le maschere
collegate ad un altro db con i dati).
Da qualche tempo, complice l'aumento dei records, lamenta una lentezza
esasperante. Premesso che vorrei evitare il più possibile di mettere
le mani sul sw, che la rete é da 100 Mbit e non ha problemi, che le
stesse maschere si caricano istantaneamente sulla macchina che fa da
server, che soluzione si può ipotizzare?
Tenendo aperto il task manager, ho notato che é la cpu che va a palla,
mentre rete e memoria (file di paging) si mantengono costanti.
Idee?
Ciao e grazie
GigioTD

 esasperante.
Quale versione di Access possiedi? A me sembra che il 2003 funzioni
meglio in rete.

lui usa la 2000, ma ho anche provato la 2003 senza notare
miglioramenti....

 miglioramenti....
Hai compattato l'mdb sul client?
Così è difficile darti dei consigli perché non descrivi se (per esempio) le form hanno delle immagini come sfondo o usano 
pesantemente le funzioni dlookup (e simili) o chissà che cos'altro.
Prova a realizzare una form semplice che apre una tabella pesante e guarda il risultato se soddisfa o meno...
Ciao.
-- 
Sergio MAZZA 


Access elabora i dati solo localmente xcui ha bisogno di trasferire dal
server tutti i recor per poi elaborarli e restituire i dati richiesti. Ne
consegue che maggiore è il numero di record maggiore è la lentezza di
elaboprazione. Se poi aggiungi l'ambiente multiutenza ....Personalmente per
elaborazioni in rete sono passato ai progetti adp installando su un pc che
funge da server msde2000a (lo trovi sul sito microsoft). In tal modo è al
server che viene demandato il compito di elaborare le istruzioni sql e
restituire solo i dati richiesti. Ti assicuro che in rete ed in ambiante
multiutenza va.
Ciao, Max.
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

> Hai compattato l'mdb sul client?
Purtroppo sì... non é così facile la soluzione. :(
Le form lente sono solo due su una 15ina, quindi evidentemente sono
quelle che hanno qualcosa di pesante. Quello che mi faceva pensare alla
rete é il fatto che sul server queste due form sono istantanee. 
Ciao

che funge da server msde2000a
Uhm... il passaggio é indolore? Ovvero: c'é qualche tool che
trasforma tutto l'mdb in desktop engine? Occorre pagare un'altra
licenza per convertirsi all'msde?
Ti ringrazio molto per le tue delucidazioni.
Ciao


La questione è che in access il motore jet elabora localmente i dati. Ne
consegue che quando l'elaborazione avviene sul pc su cui risiedono i dati
(nel tuo esempio il server stesso), il tempo di elaborazione è dato dalla
prestazione della cpu. Quando però all'mdb si accede via rete da altro pc su
cui è installato access, è il motore jet di quest'ultimo che elaborerà i
dati xcui tutti i record relativi alle tabelle coinvolte nell'interrogazione
dovranno essere prima trasferiti sul pc chiamante per poi da quest'ultimo
successivamente elaborati. Ne consegue come puoi facilmente comprendere che
il tempo di attesa tenderà ad aumentare per quanto maggiore saranno i record
coinvolti che dovranno transitare in rete. In ambiente sql invece le cose
cambiano radicalmente perchè il lavoro sporco di elaborazione dei dati viene
fatto dal server stesso tramite le viste e/o le stored procedure che
risiedono sullo stesso server ed attivate dai pc chiamanti a cui il server
restituirà solo i dati richiesti. Per fare ciò occorre installare su un pc
facente funzioni di server, sql server (a pagamento) oppure msde2000a (free)
o latri motori sql quali mysql. Relativamente al secondo che è quello con il
quale normalmente mi interfaccio, è una versione ridotta di sql server la
cui limitazione, oltre a mancare ad una serie di utility di amministrazione
in parte recuperabili con altre utility free disponibili in rete, risiede
nelle dimensioni max del database nonchè nelle interrogazioni concorrenti
(max 5). Occorre precisare che le interrogazioni concorrenti non coincidono
con il numero di utenti connessi che possono essere anche molti di + ma
semplicemente con le istruzioni che vengono inviate contemporaneamente al
server da + utenti. Quando le interrogazioni concorrenti superano il numero
di 5, le prestazioni tendono a decadere in maniera +o- apprezzabile a
seconda dei singoli casi. Per la sintassi da impiegare e la tipologia dei
dati l'approccio a sql è in certi aspetti diverso da quello tradizionale di
access, ad esempio bisogna dire addio alla libreria dao e passare ad ado.
Per quanto riguarda la conversione dei dati delle tabelle, nel menù
strumenti -> utilità database è presente l'utility upsize guidato che esegue
una prima conversione dei dati per renderli gestibili in sql. La questione è
che il + delle volte a questo primo passaggio deve seguirne un successivo
intervento sulle singole tabelle convertite e risedenti sul server per un
intervento puntuale su alcune tipologie di dati. Il discorso cambia per le
righe di codice ma la cosa è + difficile a dirsi che a farsi. Se l'argomento
può interessarti ti posso consigliare la guida in linea di sql server
(
http://www.microsoft.com/downloads/details.aspx?FamilyId=A6F79CB1-A420-445F-8A4B-BD77A7DA194B&displaylang=it
)
ma soprattutto il testo "Microsoft Access e SQL Server Guida dello
sviluppatore" edito da Mondadori (50 euro). Credo sia un buon testo per
cominciare, almeno a me è servito. Sempre sul sito microsoft troverai che è
prossimo alla licenza finale anche sql2005express (evoluzione di msde2000).
Per concludere considera che access come tale non è nato per applicazioni in
rete per cui se i dati da elaborare sono pochi e/o si accetta la lentezza di
elaborazione in rete, l'approccio all'applicativo è di un tipo ma se
l'applicazione è già un pochino + complessa e/o le performance hanno valenza
non trascurabile, occorre ragionare seriamente al passaggio ad altri sistemi
tra cui anche access+sql ma non solo. Certamente dal forum ci sarà chi a
ragione potrà segnalarti altri sistemi anche + performanti.
In ogni caso saluti e buon lavoro, Max.


Quello che hai scritto mi é chiaro, ma volevo chiederti una cosa: se
io lasciassi le maschere in access e poi collegassi le tabelle (con la
funzione di access "collega tabelle") su un db esterno, che può essere
anche oracle o mysql, secondo te cambierebbe la logica?
Ovvero, non che é le maschere di access poi continuano a lavorare con
la stessa modalità, cioé si scaricano prima tutte le tabelle della
query in locale e poi fanno le join, nonostante il cambio del motore
del db? Il "collega tabelle" di access mi farebbe salvare tutto il sw
fatto in passato, ma mi é sorto questo dubbio...
Ciao e grazie!
GigioTD


Cerco di risponderti:
le maschere, i report, le pagine, le macro, i moduli rimangono in access.
Sul server sql vengono salvate solo le tabelle, le viste e le stored
procedure. La questione è che per maschere e report va definita l'origine
dati della maschera o report che può essere la tabella, una vista o una
stored procedure. Può anche non essere definita a priori ma da codice
sull'evento "su apertura" della maschera stessa. Inoltre a prescindere
dall'origine dati, sia esso vista che tabella ma con l'esclusione delle sp
per le quali il discorso si complica un pò, c'è la possibilità di impostare
la funzione "filtro su server" per cui i dati in fase di apertura della
maschera ma prima del loro caricamento vengono filtrati dal server in base
al filtro impostato. Ne consegue che se correttamente organizzata la
maschera e le righe di codice in essa riportate, non vengono mai travasati
in locale tutti i dati a meno di esplicita richiesta come nel caso di una
maschera continua che deve visualizzare tutti i record.
A titolo di esempio ti passo 2 stringhe di codice che operano in fase di
apertura di 2 distinte maschere. Nel primo caso l'origine dati viene
assegnata in fase di apertura e con esso il criterio di selezione dei dati,
nel secondo caso l'origine dati è già impostata nelle proprietà della
maschera ma in apertura viene impostato il filtro su server ed attivato. In
entrambi i casi è il server che preliminarmente al trasferimento dei dati al
client esegue la selezione dei dati.
Caso 1:
Private Sub Form_Open(Cancel As Integer)
    Me!ElencoDatiSelezionati.RowSourceType = "Tabella/visualizzazione/stored
procedure"
    Me!ElencoDatiSelezionati.RowSource = "SELECT TOP 100 PERCENT Campo1,Campo2
FROM dbo.TBL_ElencoDati WHERE " & str_SelezionaElaborati & " ORDER BY
Campo1"
End Sub
Caso 2:
 Private Sub Form_Open(Cancel As Integer)
    Me.Filter = "[Campo1] = '" & str_Campo1 & "'"
    Me.FilterOn = True
End Sub
 
Spero di averti chiarito qualche dubbio e non contribuito a creartene altri.


Ok, é tutto chiaro... quindi il comportamento cambia semplicemente
spostando i dati su un "vero" db.
Un'ultima cosa: qual é il limite fisico dell'msde2000?
Ciao e grazie
GigioTD

 ha scritto nel messaggio
news:1132070674....@z14g2000cwz.googlegroups.com...

Ciao e grazie
GigioTD
Vedi 
http://www.microsoft.com/italy/sql/msde/productinfo/features.mspx
troverai anche altre indicazioni oltre al limite fisico (2 Gb)
ps. il comportamento cambia nella misura in cui, oltre a spostare i dati sul
server, adegui la sintassi delle righe di programma.
ciao, Max

server, adegui la sintassi delle righe di programma
Dal primo esempio che mi hai fatto, é bastato mettere una "where"
nella select... credo che questo non comporti alcun cambio nella logica
del sw (insomma, la where mi aspetto che ci sia già con Access: se mi
deve dare solo i record con città= 'Milano', che sia Access o Sql non
cambia nulla), oppure mi sfugge qualcosa?
Ciao! ;)
GigioTD


No. La mia è una considerazione di carattere + generale. Ad esempio, se
avrai modo di sviluppare ulteriormente l'approccio ad sql, vedrai che sia le
sp che le viste risiedono sul server ma le prime hanno velocità di
elaborazione superiore in quanto sono , tra virgolette, già compilate dal
server. Le viste e più in generale le istruzioni SELECT trasmesse come negli
esempi che hai visto, devono prima essere "compilate" per poi elaborate. Per
contro le sp hanno dei vincoli che le viste non hanno. Vedrai poi che ci
sono le sp di sistema che consentono determinate operazioni che in una
gestione in rete di un database risultano utili oltre che talvolta
necessarie. Esiste il concetto di proprietario degli oggetti (tabelle, sp)
che se vuole condividerne l'impiego con altri utenti deve abilitare gli
altri utenti all'esecuzione e via di seguito. Troverai libri di testo a iosa
su questo e tanto altro e + in generale su come ottimizzare il connubio
access+sql la cui lettura ti consiglio prima di affrontare il passaggio al
nuovo sistema.
