Newsgroup: it.comp.appl.access
Titolo: Accesso in rete e relative prestazioni con tabelle transitorie

Ciao a tutti!
E' qualche giorno che mi diletto a leggere i passati post sul problema
della lentezza di Access in rete. Attualmente utilizziamo Access in
rete da 4 clients tutti con XP Professional sui quali girano i FE, che
si appoggiano a un "server" XP Professional "dedicato" (in pratica un
PC XP Professional che viene utilizzato solo come contenitore di
archivi e che elabora soltanto la parte di Access in BE). Per
migliorare le prestazioni in rete su programmi non soggetti a continue
e grandi modifiche/aggiunte, ho notato dei notevoli miglioramenti se
copio le tabelle o le parti delle tabelle dal server sui singoli
client, che vengono poi utilizzati per query, aggiunte/modifiche. Certo
così facendo complico un pò il programma, posso corere il rischio di
non avere dati aggiornatissimi (per questo secondo me è necessario
utilizzare il sistema su archivi non soggetti a molte e continue
modifiche), ma mi par di limitare il traffico in rete. Le tabelle
transitorie che utilizzo le colloco in locale ma in un altro file di
Access, di modo da poterle compattare ogni volta che esco dalla
procedura in automatico. Cosa ne pensate?
Ciao e grazie dei pareri, grazie a Voi ho potuto imparare tantissimo!

 Per
migliorare le prestazioni in rete su programmi non soggetti a continue
e grandi modifiche/aggiunte, ho notato dei notevoli miglioramenti se
copio le tabelle o le parti delle tabelle dal server sui singoli
client, che vengono poi utilizzati per query, aggiunte/modifiche. Certo
così facendo complico un pò il programma, posso corere il rischio di
non avere dati aggiornatissimi (per questo secondo me è necessario
utilizzare il sistema su archivi non soggetti a molte e continue
modifiche), ma mi par di limitare il traffico in rete. Le tabelle
transitorie che utilizzo le colloco in locale ma in un altro file di
Access, di modo da poterle compattare ogni volta che esco dalla
procedura in automatico. Cosa ne pensate?
quello che stai facendo è un accrocchio...non è una soluzione...
correttamente tu stesso dici "posso correre il rischio di
non avere dati aggiornatissimi " ma guarda che non è un problema da poco!
allora meglio usare carta e penna :-)
beh torniamo a noi e scusami se ho fatto dell'ironia
ma access non è nato per lavorare in multiutenza!
La multiutenza la fai con Sql server o se non vuoi
pagare la licenza con MSDE.
Se con un programma di analisi sul traffico di rete
vedi le valanghe di dati che access riversa
da un client all'altro c'è da perdere paura!!!!
certo ottimizzando i processi si riesce a migliorare
ma....che fatica!
Studiati MSDE/sql server e fai il front con AccesXP
vedrai che oltre a ragiungere performace elevatissimi
e alti livelli di affidabilità avrai pure delle belle soddisfazioni.
Ciao!
ringo 

 ringo
-- 
_ _
Ciao
MAssimiliano Amendola            
www.accessgroup.it
Cisa - Conferenza Italiana per Sviluppatori Access
Info:  
www.donkarl.com/it

Ho letto la tua risposta e non posso che condividerla in buona parte!
Però, se mi permetti, anche se è indubbiamente un escamotage, penso
debba esere messo in riferimento alla realtà in cui si opera. Ad
esempio in un programma di faturazione, laddove si pescano dati
dall'Anagrafica, e laddove gli utenti lavorano a pochi metri gli uni
dagli altri, i rischi di rimanere con dati errati sono veramente
pochissimi! Ad esempio ho creato un database con numeri di telefono:
appoggiandomi ad un archivio provvisorio in locale non intaso la rete
(visto che l'utente tiene normalmente aperta la schermata del telefono
mentre telefona), e le possibilità di errore sono veramente remote (e
se anche capitasse, cosa per ora mai successa, non casca il mondo)! Da
quel poco che posso aver capito negli ultimi anni, tutta l'informatica
è basata su dei compromessi come questo (il fatto stesso che Access
verifichi i dati in rete eventualmente variati ogni 60 secondi secondo
me è un compromesso simile). Altra cosa sarebbe utilizzare questo
sistema delle tabelle transitorie con DB che vengono variati mentre li
si consulta o utilizzati da utenti distanti e molto + numerosi! Grazie
dell'attenzione e della risposta: trovo che è una discussione molto
utile!


un mio db ghiotto e di 180MB
4 anni di lavoro giornaliero
lettura, modifica, scrittura continua
Tabelle corpose sono 260.000 record vendite, 53.000 ricevute di vendita,
86.000 acquisti, 19.000 articoli,
294.000 tabella che verifica le transazioni, e tante tante altre tabelle,
Query che non te ne dico,
182 tra machere e sottomaschere
una 52 di report
30moduli corposetti
12 utenti in contemporanea
delle combobox così cariche che ha fatto perder i capelli a Sergio Mazza (in
quasi tutte le maschere
c'è almeno una combo con tutti e 19000 articoli dentro
Access in FE e Access in BE.
Credimi schizza come un pazzo.
Il tutto è sempre e solo un problema di indicizzazione e struttura del db.
E non ho ancora finito...
questo db è in continua evoluzione




Ciao, aggiungo giusto un tassello alla tesi di MA.
Ho un database access in BE su un server condiviso da circa 20 utenti
e un servizio autonomo che riga su un server remoto. Tale servizio
scrive ogni 60 secondi un record in una tabella del db in BE. Il db al
momento conta circa un milione e 600 mila record (record +, record -).
La dimensione del file è circa 850mb e le ricerche, quando necessarie,
operate dai vari FE sono velocissime... Per migliorare le performance
del tutto si è provveduto (l'ha fatto un collega esperto di access,
ormai andato in altre realtà) a ottimizzare le strutture delle
tabelle, indici compresi.
Quindi access non teme la quantità dei dati in questo caso.
Penso che i motivi per cui si scelga SQL Server o Oracle o database di
questa portata sono ben altri...
ciao.

 ciao.
Allo SMAU io e Pablitomf e TheMax parlavamo con MVP SQL e parlavamo di molte
utenze contemporanee.
Gli chiedevamo del perchè del suo passaggio a SQL.
Ci ha riso in faccia quando ha capito che molte utenze per noi erano un
centinaio, per lui milioni.
Access e SQL sono strumenti diversi per usi diversi e target diversi




Permettimi di aggiungere un ulteriore post per completare il quadro:
SQL è un server database e come tale ha una serie di funzionalità che
access non può avere. Affidabilità e disponibilità, efficienza.
Gestione degli accessi, gestione dei permessi, gestione dei backup in
tempo reale, gestione degli swap, bilanciamento del carico tra server
distribuiti, connettività di livello superiore (appunto milioni e non
centinaia), motore più performante, gestione dei triggers e stored
procedures, ecc... Insomma una altro pianeta, mica vogliamo paragonare
access con SQL Server? Anche perchè access costa poche centinaia di
euro, SQL Server forse qualche migliaia ed un motivo ci sarà! Mamma
Microsoft ha fatto un buon lavoro con SQL Server.
Il fatto è che spesso però si sottovaluta access e le sue
potenzialità: senza dubbio ha dei limiti, ma con un pò di conoscenza
si superano e si riescono a realizzare cose belline.
E' indubbio che li dove ci vuole qualcosa di serio non può essere
pensato in termini di access. Un esempio: un sistema di automazione
industriale che gestisce una grande quantità di dati di processo... in
questo caso access non è applicabile perchè oltre ai dati (che non
sarebbe un grande problema) c'è il discorso dell'affidabilità (che in
un impianto deve essere a livelli elevati).
Comunque access non è un giocattolo, come molti immaginano.
ciao.

>
non è nella mia indole aprire inutili diatribe sul fatto
di usare access o meno come contenitore dei dati
ma voglio solamente in ottica costruttiva dire un mio parere
sugli enormi benefici che porta l'utilizzo di sql server
in una struttura client-server!
Sempre secondo il mio modestissimo parere ada access
gli faccio fare in modo egregio e velocissimo la parte
riguardante i front-end delle applicazioni e per i report!
ciao!
ringo