Newsgroup: it.comp.appl.access
Titolo: TABELLE COLLEGATE

Le Tabelle Collegate sono davvero così lente ?
Ho sempre scritto applicazioni (in rete) con MsAccess 97/2000 includendo
Forms / Tabelle ecc in un unico database anche perchè notavo una buona
velocità.
Per diversi motivi ho dovuto dividere tabelle in 1 databese ed
interfaccia ( Forms / Query / VBA ) in 1 altro ed è diventato tutto
drammaticamente lento.
L'Hardware è OK.
Cosa SI DEVE e cosa non SI DEVE FARE per limitare i danni ? .
Ringrazio anticipatamente chi avrà la cortesi di rispondermi. Marco. 
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 wrote in message
a007f7adaa9f6b50917...@mygate.mailgate.org...

Lente? ma di cosa parli... la lentezza è talmente relativa in
quest'operazione... è quasi impercettibile...
Io ho un applicazione strutturata con front e back ma di lentezza non se ne
parla proprio... ma quanto è grande la tua applicazione...

 Ringrazio anticipatamente chi avrà la cortesi di rispondermi. Marco.
Non Capisco se sei ironico o convinto. Il DB con i dati ad oggi è 70 MB
(tabelle anche di 80.000 records).Il DB con Forms Ecc. 3/4 MB. Soffro
quando devo aprire Form con SubForm (Es. Ordine di un determinato anno
+ Righe dell'ordine selezionato ) e nelle 2 forms ci sono caselle
combinate
che caricano fornitori , articoli ...  . Tutto questo è normale (ottima
velocità) quando le tabelle non sono collegate. Succede anche che per
salvare una form o un report in struttura con una normalissima origine
dati passano minuti ! . Tu come ti comporti nelle tue applicazioni ?
Grazie
MArco


 Tu come ti comporti nelle tue applicazioni ?
Quando a me accade ciò che sta accadendo a te, prima di tutto RIVEDO in
maniera più che scrupolosa tutti i codici e le relazioni di riferimento, se
è tutto liscio compatto, mi copio le maschere con altro nome, cancello
quelle originali, rinomino quelle copiate con il nome d'origine e
ricompatto... sarà banale, ma a me funziona
Dammi altri elementi per capire...
(Fai una cosa... vedi se dopo aver svolto qualsiasi di queste operazioni che
ti fanno "perdere" tempo, il front aumenta o meno in dimensione)

 Ringrazio anticipatamente chi avrà la cortesi di rispondermi. Marco.
Mi riferivo all'ironia pensando a me che rispondo a chi mi dovesse
chiedere notizie in merito ... . Chiarito l'equivoco ti ringrazio per
l'aiuto e aggiungo notizie.
Il Back è su server NT 4.0 Ethernet 100 (a questo punto verifico). Ne
utilizzo anche uno piccolissimo sul PC locale. I Client (10/15) sono PIV
1xxx 256/512 RAM. Ho scritto "parecchio" codice VBA e utilizzo relazioni
(che verificherò). In effetti il front aumenta dopo dopo la modifica
della struttura delle forms/reports, ma questa la considero cosa normale
risolvibile con compact. Posso aggiungere che durante queste operazioni
i leds dell'hub segnalano attività frenetica e a volte ritrovo un sacco
di
parentesi in più nelle condizioni che filtrano la query di origine dati.
L'Assurdo è che se riunisco tutto in un solo MDB vado come una scheggia.
Mi chiedo: è sufficiente collegare le tabelle oppure co sono regole da
rispettare?. Altra cosa, se non esagero. Ho notato anche che se aggiungo
da codice VBA records nella tabella origine dati della form spesso ci 
sono dei ritardi nel refresh cosa che non accade con 1 solo mdb.
Ti ringrazio per l'interessamento e spero di avere ancora tue nuove.
Ciao Marco


 sono dei ritardi nel refresh cosa che non accade con 1 solo mdb.
Questo devo guardarlo!
Fammi sapere
Maurizio

 ecc...
Purtroppo Jet... non è proprio un 'jet' quando lavora con tanti rcd; tu
lavori in CONDIVISIONE (motore jet) e non con un sistema CLIENT/SERVER
(tipo SQL7 o MSDE) quindi elabori "tutto" in locale (sul front);  poi basta
avere solo 2 PC front collegati ai dati che tutto rallenta. Che sappia io
nun ce' stà niente da fà se non convertire i DB in .adp e collocare le
tabelle su un  server con SQLSERVER o MSDE(gratuito e presente sul CD di
office: :\SQL\X86\SETUP\SETUPSQL.EXE). Saluti

 office: :\SQL\X86\SETUP\SETUPSQL.EXE). Saluti
Non sono per niente daccordo... sulla mia applicazione ci lavorano +/- 40
pc, e altro che tabelle collegate che ha...

 wrote in message
news:gSNh8.1010$%d1.1...@twister2.libero.it...

In effetti avevo già sentito parlare di lentezza a proposito di Access
ma mi rifiuto di credere cha faccia così schifo. La rete stando ai led
sulle shede (tutte 3COM 905) e sugli hub viaggia regolarmente a 100 (i
client sono 10/15, non viaggiano a 10).Sul fatto delle licenze
attualmente
solo 2 sono regolari perchè pensavo di distribuire un run-time una volta
ottenuta una release decente. Pensi ci possa essere una protezione ? .
Questa mattina per togliermi una curiosità : altra rete (comunque 100),
altri PC, altro server, altre tabelle .....
Ne collego alcune, scrivo una query (che usa altre query), la uso come
origine dati di un report che parte e si apre in struttura normalmente.
Complico leggermente il report con un subreport banalissimo (legge una
tabella ed è collegato al principale tramite id) provo a salvarlo ...
minuti !. Provo ad esegirlo ... minuti!. Finalmente riesco ad aprirlo in
struttura (minuti, naturalmente!) e trovo nelle formule un sacco di
parentesi corrette come sintassi ma inutili e aumentate rispetto a
prima.
Creo allora altro mdb, importo tutto, torno alla normalità. Lavoro un
tot (modifico, salvo, eseguo) e mi si rallenta ancora. Altro mdb, altra
importazione, altra normalità, altra rottura di palle, altro loop.
Alla fine forse ho risolto non specificando l'origine dati direttamente
nel report ma passandogliela direttamente in apertura.
A prescindere da tutto, Qualcosa in più sull'MSDE ?.


 ma mi rifiuto di credere cha faccia così schifo.
Forse il problema non è sulle tabelle collegate ma sul codice di
apertura delle tabelle che sfrutta ADO.
In un'altra discussione di questo gruppo ho notato un altro utente che
sembra soffrire dello stesso problema di "ritardi" e sembra che gestendo
il codice con DAO la cosa sia stata superata (prova a leggere la
discussione "Ritardi con collegamenti DAO"(o simile).
Ciao.
Gianpaolo 
