Newsgroup: it.comp.appl.access
Titolo: problema da esperti :-)

Ciao a tutti
è la prima volta che posto in questo news e spero che
qualche guru di Access possa aiutarmi :-) dato che io non
sono molto esperto.
La mia situazione è questa: ho un database enorme (più di 3 GB)
costituito da tabelle che raggiungono i 5 milioni di record in alcuni casi.
Questo DB non l'ho fatto io, ma ora ne sono diventato il "responsabile" e
nonchè quello che effettua gli aggiornamenti e miglioramenti.
A causa della sua mole il DB è costituito da circa 50 file MDB, ognuno
contenente
una sola tabella, credo sia stato fatto così a causa delle limitazioni di
Access
(che mi sembra siano di max 2GB), oppure perché proviene da Access 95.
Inoltre c'è un file MDB che contiene varie tabelle più piccole linkate fra
loro
(circa 100 MB). :-))
Il punto è che il database è quindi poco relazionale, non essendo possibile
mettere
tutto all'interno di un unico file MDB.
Fin qui il problema è ancora relativamente piccolo.. ma ora viene il bello.
Tutti questi file sono memorizzati su una workstation NT 4.
Su circa 15 altri PC vi sono dei database da circa 30 MB, i moduli client,
che linkano le tabelle del DB principale con tutti i dati.
Questi DB client, contengono poche tabelle "proprie" e moltissime query
e form.
Per chiarire il concetto posso dirvi che sul server ci sono dei dati di
misure, e
che i client interrogano queste misure per farne dei grafici.
I client hanno circa 250 queries.
Ora vengo al punto:
non so spiegarmi perché il Database è lentissimo!
Non è un problema di rete. Se io apro un modulo client, e addirittura
tento di aprire una SUA tabella (non una linkata) di circa 300 record
in modalità foglio dati, ci mette a volte 10 minuti!!!!!!
Lo stesso tempo ci mette quando, clikkando sui tasti di un form apposito,
si vogliono visualizzare dei grafici di misure (in effetti in questo caso
viene
interrogato il server....)
C'è un modo di velocizzare le cose?
So che l'ideale sarebbe passare a un SQL server, e accedere con moduli
client
in Access, però questo è per ora poco probabile, in quanto comporterebbe una
spesa per l'azienda, e un grosso lavoro di riconversione....
Io avevo pensato di ristrutturare il DB in modo da renderlo più relazionale,
ottimizzare
le queries e tutto quanto... però:
1) non credo sia possibile mettere tutto in un unico file MDB a causa delle
dimensioni
2) non mi spiego la lentezza nell'apertura di tabelle locali piccole!!!
Ho anche provato con un analizzatore di rete a osservare la LAN mentre
eseguo
una query, e i dati che passano sono relativamente pochi, tipo un centinaio
di pacchetti
IP da 1500 bytes per volta (credo che questo sia a causa della segmentazione
che il livello Datalink Ethernet esegue sui pacchetti TCP/IP)....
Quindi il punto è che è proprio il client ad essere "bloccato", ma non so
cosa stia facendo...
Non penso sia un problema di potenza di calcolo, dato che la workstation è
un PII 450
con 256 MB di memoria, HD SCSI da 18 GB, e il mio PC che uso come client
è un PIII 666 con 192 MB di RAM e Win95.
Anche se ho altri problemi, questo è per ora il principale, quindi mi fermo
qui
sapendo che vi ho già annoiati abbastanza.... :-)
Ringrazio chiunque sappia suggerirmi qualcosa... per ora continuo a leggere
manuali
di Access e Help in linea e spero di trovare qualche idea...
Ciao a tutti e grazie anche solo per aver letto il messaggio.
ByZ-2K

 ha scritto nel messaggio
news:Nz4i7.58516$TS4.2...@news2.tin.it...


 è un PIII 666 con 192 MB di RAM e Win95.
Sicuramente non è un problema d'hardware :-)
Ciao, warp
P.S: non usare per favore subject tipo "problema da esperti", "per
espertissimi", "solo guru" etc. etc.

 gruppo di lavoro rallenta molto Access in alcune operazioni.
Comunque ti ringrazio per l'aiuto...
Ciao
ByZ-2K

 espertissimi", "solo guru" etc. etc.
Chiedo scusa per il subject, non sapevo come intitolarlo, ma la prossima
volta cambierň sicuramente... bč ora per non aprire un altro thread perň
continuo
cosě... spero non ci siano problemi...
Fatemi sapere e grazie di tutto
ByZ-2K

 ha scritto nel messaggio
news:yffi7.31274$vC1.3...@news1.tin.it...

ATTENZIONE FORSE HO UNA PICCOLA SOLUZIONE DA PROVARE
Ho avuto all'inizio problemi di apertura maschere in rete; LENTISSIMO con
A2000 e velocissimo con Access 2.0.
A tutti i database sia DATI che PROGRAMMA togli:
strumenti > opzioni > generale > tieni traccia delle informazioni di
correzione.
Questa soluzione mi č stata data da MICROSOFT.
Saluti
G.F.

 ByZ-2K
Ciao, warp

 Ciao, warp
Ciao e grazie per la pazienza :)
ByZ-2K

2) non
mi spiego la lentezza nell'apertura di tabelle locali piccole!!!
Allora,
effettua queste operazioni, prima di tutto 
1) >>>>> Controlla che non
ci siano criteri di ordinamento specificati sulla tabella , fai molta
attenzione, tutte le maschere che permettono Filtro / Ordina, chiedono se
vuoi Salvare le modifiche apportate, se dici di SI, viene impostato un
criterio di ordinamento sulla tabella BE!!! a questo punto è finita, se
provi ad accedere la tabella, prima di fornirti il recordset si scarroccia
tutti e 5 i milioni di record!!!
2) verifica se Office è stato
installato da 'rete' ... , ossia staccando il cavo di rete del client deve
andare tutto 
3) Compatta il FE su almeno 1 macchina e riprova
4) (se
1 da Esito Negativo) Controlla che il WorkGroup ATTIVO (system.mdw ? ) che
tu credi essere in locale, non sia in rete per farlo lancia
c:\win*\system*\WrkgAdm.exe 
5) controlla la versione del DAO (file
dao350.dll x A97 o dao360 x A2K)
deve essere 3.51 nel caso A97 x A2K non
lo so')
6) Verifica qual'è la struttura di tabella che effettivamente ti
rallenta, copia un Mdb su locale e cancella ad uno ad uno i campi della
tabella  fino a quando la velocità di risposta non aumenta (se aumenta)
7) considera che Dao non ammette che il contenuto di 1 record sia più
grande di un certo nr di Kb esempio dimensiona 30 campi testo da 255 chr
poi riempi ogni campo con 255 caratteri(non c riesci)
8) Se risolvi il
problema di performance, unisci su 2 DB i 50 MDB e cambia il FE in modo che
faccia il link ai 2 anzichè ai 50, in questo modo almeno semplifichi la
gestione degli LDB da parte dei FE 
in ogni modo ...
Query che
coinvolgono 5 milioni di record lanciate da un client verso un FILE sono un
massacro, il client deve generare GIGA di file temporanei per poterle
eseguire.
Se proprio non ci salti fuori e non vuoi usare un Server DB ,
fai eseguire tutte le query + pesanti sul server di rete  ( tutte le sere ?
, nell'intervallo?) , facendo delle query di Creazione Tabella (a questo
punto su di un 3° db temporaneo che cancelli e ricrei ogni volta partendo
da un db che contiene solo le query) che creano tabelle che hanno lo stesso
nome della Query, poi colleghi queste ...
ciao
rr
--------------------------------
Inviato via 
http://usenet.iol.it
 

 nome della Query, poi colleghi queste ...
Questo purtroppo non è proprio possibile...
Dovrei eseguire decine di migliaia di query.... e non sarei sicuro di aver
esaurito la casistica.... questo perchè le query dipendono da parametri che
si selezionano sui form...
A proposito.. come faccio a far eseguire le query al server invece che ai
client?
Ciao e mille grazie
ByZ-2K
PS: Se vuoi continuiamo via mail la discussione e ti spiego nel dettaglio
com'è fatto il DB e cosa contiene...
PS2: Comunque ho convinto la mia azienda a farmi fare un corso
di SQL server e un altro di Oracle... :-)

 client?
Si
puo' fare solo se esistono determinate condizioni (a suon di codice ad hoc
sul server)
se le variabili in gioco sono cosi' tante come dici, non è
proponibile ...


 scritto:
 [megacut]
Concordo pienamente con quanto scrive Riccardo.
Soprattutto esegui la compattazione dei file mdb (FE e BE) e UNISCI IN NON
PIU? DI 2 o 3 FILE TUTTI I BE!
Questo e' quasi imperativo.
Hai mai provato a fare un "Compila e salva tutti i moduli"?
Fai la prova e raccontaci i risultati.
Infine, se proprio dopo tutte queste compattazioni non ottenete risultati,
io ritengo che dobbiate passare a SQL. Potreste tranquillamente continuare a
usare access per i FE.
Una azienda che deve gestire milioni di record non capisco che problemi
possa fare per passare a SQL, certamente non economici.
Resto comunque dell'idea che molte cose non vadano in questo vostro db.
Sib
--
----------------------------------------------------
la mia home:
http://digilander.iol.it/syb
----------------------------------------------------
il sito comune di it.comp.database.access:
http://www.sitocomune.com
----------------------------------------------------
4000 anni fa', il saggio egizio Ptahhotep scrisse:
"... perche' non esistono saggi per nascita."
------------------------------------------------------
Saturiamo ECHELON:
bomba saddam attentato medio oriente

 Resto comunque dell'idea che molte cose non vadano in questo vostro db.
Anch'io, ma mi piacerebbe farvi vedere nel dettaglio com'è questo DB
e come lo usiamo per farvi capire la situazione... :-))
ma purtroppo non posso....
Ciao
ByZ-2K

 proponibile ...
è comunque possibile parametrizzare le cose... ma il meccanismo mi
interessa...
qual è?
come realizzo il collegamento client-server, cioè come faccio a fare stare
il server in "attesa" di un messaggio da un client per eseguirgli la query,
e poi
come gli passo i risultati?
Grazie di tutto come sempre, e ciao
ByZ-2K

Allora, una precisazione doverosa , Access NON HA nessun meccanismo client
server, si tratta di scrivere del codice ad hoc (una form ) che lancia
periodicamente una serie di query di creazione tabella che genera i
resultset + complessi, (in sostanza fa tutti i join ma non le where), le
query sui client vengono semplificate, non fanno i join, ma devono
limitarsi ad applicare le eventuali Order by e where che decide l'utente.
E' una soluzione che si può applicare solo se i dati coinvolti non vengono
variati dagli utenti, che si limiteranno a fare solo delle consultazioni.


 ma purtroppo non posso....
Fai le prove di cui si e' parlato, poi ridescrivi la situazione e vediamo.
Se le cose non cambiano l'unica resta passare a SQL.
Sib

 variati dagli utenti, che si limiteranno a fare solo delle consultazioni.
In effetti noi non cambiamo i dati... ma li consultiamo e basta... :-))
Ciao
ByZ-2K

 Se le cose non cambiano l'unica resta passare a SQL.
Ok ma mi farò sentire più avanti perchè ora sono in acque molto vorticose
e al DB posso dedicare un o-piccolo del mio tempo disponibile....
(nelle 12 ore giornaliere di lavoro si intende :-))) )
Ciao e grazie
ByZ-2K

 cosmici....
Si puo' dire che azienda e'?


 
casini del genere li fa solo la telecom e forse la fiat.
--
a.cara

 ha scritto nel messaggio
news:3B97F84C...@blunet.it...

Anche tu nottambulo allora? ;-)


 Fai la prova e raccontaci i risultati.
L'unica spiegazione plausile per tempi di risposta cosě pietosi su tabelle
locali, č che abbia in TrayBar un bel pacco di utility residenti che
impegnino brutalmente il sistema.
Ciao, Simone

 impegnino brutalmente il sistema.
Allora bisognerà cercare un'altra spiegazione plausibile.... :-)
Ciao
ByZ-2K

> casini del genere li fa solo la telecom e forse la fiat.
Ci sei andato molto vicino...
Non dico di più :-)))
Ciao
ByZ-2K