Newsgroup: it.comp.lang.visual-basic
Titolo: OLEDB Access ....come ottimizzarlo?

Una domanda..
premesso che usare ADO non sarà il massimo e che forse DAO sarebbe meglio
nello specifico..
.
Però che alternativa ho al provider OLEDB di M$ per velocità di accesso e
risposta ad un db access 2000?Provider alternativi ad un costo onesto?
e se mi tocca tenere quello di M$ mi sapete consigliare (ammesso che
esistano) dei settaggi per incrementare la velocità di risposta di un db
access 2000?
da mie prove la velocità non si incrementa molto con ram cpu e
quant'altro...a parte un HD scsi...ma allora mi sorgono altre domande...per
ora rispondetemi a questa per favore....grazie!
:-)....
(io mi vergogno un po' in mezzo a voi guru..però mi piacerebbe venire al
meeting!)


guru?
ugu-guru?    :-P
almeno!!!!
vieni, vieni.
Lo scopo del meeting è proprio di conoscerci.
Sarebbe bello esserci tutti...
ciao
ugo

 lei...    ;-PPPPP
la chiamano mimi' ...

 ha scritto nel messaggio
news:9oqe2v$enbm7$1...@ID-51318.news.dfncis.de...

LOL
ciao
ugo

 In cosa esattamente hai problemi di velocità?
ri-cut
quando eseguo una conn la prima volta "va piano" alle successive "molto più"
veloce ...(io credo si crei qualche vaariabile o workspace su HD)...è
abbastanza evidente con win 95,98,nt workstation molto meno con winMe e
ancora meno con win 2000...
Uso vb6 sp4 e compilazione per ottimizzare velocità...
il caso specifico:
una applicazione (fatta male lo so...ma non è  farina del mio sacco) ha un
form che richiama altri 3 form ognuno con le sue conn ed i suoi recordset
open sul medesimo db accesss....questo per dar modo di avere 3 specie di
prog indipendenti...ad es un form carica un ordine al volo...un altro
registra un acquisto...etc etc...(fa schifo lo so ma così deve continuare ad
essere!)...tale applicazione risente in maniera drammatica sopratutto
dell'hard disk (con un normale samsung eide fa schifo!)...
mi veniva in mente...ora le ram costano poco...con 256Mb o + ci sarebbe
verso far girare il programma totalmente in ram...una volta col dos c'era il
ramdisk ....sto sparando cazzate o c'è verso dire ad un prog ed a Access di
stare tutto in ram?(sopratutto con win 95,98)
...
Utopia:
...avere tutto il SO in ram sarebbe il massimo...(ditemi al limite in che ng
andare!)
Thanks un monte!
:-)


il grandissimo Beppe !
ciao, hal
p.s. ma non si chiamava Violetta ?

 andare!)
quanta ram hai ? ora mi trovo con 384m, e un mdb da 100 mb, anche con 4-5
prog aperti, quando lo ricarico sale in pochissimo. oe6 in una frazione di
secondo. ieri avevo aperto photoshop con un file da 40 mb: ps se ne prendeva
300 col suo swap personale, ma io ne avevo 200 liberi... se non devi
swappare, si hanno potenziali miracoli. col 386, 8m di ram, portavo su
clipper e il db. compilazioni e lavoro andavano a fionda. pero', se non usi
un portatile, controlla la carica dell'ups. specie se quando fai modifiche
sostanziali al codice ti scordi di copiarle sul disco solido...
ado o quel che sia, i db su chip sono il futuro piu' ragionevole, imho.
sull'o.s. ci andrei un attimino piu' calmo...
ciao, j.


Ok: ma se ogni form è laciato da un "main" centrale nulla ti vieta di usare
1 connection e passarla ai form "secondari": già qui vedrai la differenza...
ciao
ugo

 ancora meno con win 2000...
Forse dico una stupidaggine, ma ce hai messo qualche indice nelle tabelle?
Quando apri una query, se non hai un indice che contenga i campi di filtro
e/o di ricerca, il motore di database deve crearsi l'ordinamento al volo,
oppuire fare una ricerca sequenziale.
In questo caso, è effettivamente molto diverso il tipo di prestazioni che
ottieni tra il primo ed il secondo accesso, perchè una ricerca sequenziale
fatta in RAM è comunque abbastanza rapida, mentre fatta su disco è
lentissima.
Prova a mettere dei sani indici alle tabelle, e vedrai che la tua
applicazione comincerà a volare.
Ciao
*Roby*