Newsgroup: it.comp.lang.visual-basic
Titolo: Task manager: progetto immenso!

Qualcuno sa spiegarmi perche' a volte aprendo il task manager
vedo che il processo vb5.exe raggiunge dimensioni enormi (150MB)?
Non faccio casini da codice (connessioni lasciate aperte o cose
del genere).
Uso vb5 sp3 e win2000pro sp2...
Mah...

 ha scritto nel messaggio
news:FTz57.91616$q77.8...@news2.tin.it...


Be, se ti apri un recordset su una tabella di 100 Mb fai presto ad arrivare
a quella cifra...
Dicci qualcosa di più di questo progetto...
Ciao
oZ

 a quella cifra...
Scusa ma sei sicuro? Capirei se lo si aprisse come snapshot, ma un recordset
non dovrebbe mica caricarsi tutto in memoria.
Puoi darmi lumi maggiori?
Grazie
*Roby*

 ha scritto nel messaggio
news:FTz57.91616$q77.8...@news2.tin.it...

con ADO hai impostato nelle connessioni il lato client come lato del cursore
e ti carica tutto l'mdb (io credo che usi Access vero?) ...credo che access
si comporti ugualmente anche se lo imposti server.(almeno dicevano
cosě....io mi sto spostando sempre piů su SQL server..perlomeno su progetti
di una certa importanza!)

 ha scritto nel messaggio
news:TVQ57.104084$q77.9...@news2.tin.it...


 > così....io mi sto spostando sempre più su SQL server..perlomeno su


 a chiudere connessioni e recordset, anche con set rs=nothing...
Ok questo l'abbiamo capito...
Ma quando il tuo programma raggiunge queste dimensioni cosa stai facendo?
Hai sotto 1 o 10 o 100 recordset? Publici o privati? Quante righe hanno le
tabelle che utilizzi? Quante colonne? Quanti MB occupano?Che tipo di cursori
usi quando apri le tabelle? Nelle select fai un bel "Select * from tabella"
oppure fai "Select * from tabella where campo = ..." ???
Non preoccuparti non è un terzo grado, ma secondo me devi risolverlo perchè
su un server con 256 MB ram viaggi tranquillo, ma su un pc "modesto" hai
voglia...
Quindi cerca di fare delle prove...
Ciao
oZ

 Puoi darmi lumi maggiori?
Anch'io quando l'ho scoperto ci sono rimasto male...
Fai una prova:
Vai in SQL (spero che ce l'hai),guarda quanto occupa una tabella (sceglila
di dimensioni molto grandi)..
Fatti una form normale, apriti un recordset sulla tabella e guarda di quanto
aumenta l'occupazione della memoria...
Ti scrivo quello che ho verificato: Tabella da 195 MB, Indice (chiave
primaria) di 13 MB, numero di record 651.631
Nel programma ho una form,un bottone, un oggetto adodb.connection e
adodb.recordset.
Prima di aprire il recordset il programma occupa quasi 2 MB, la Ram occupata
è 218 MB.
Lancio l'apertura della tabella: Il programma arriva ad occupare fino ad 80
Mb di ram, poi improvvisamente si porta su livelli bassi (1-2 MB) ma la Ram
continua a salire (in teoria il task manager dovrebbe continuare ad alzare
anche il livello di Ram occupata dal programma)..
Fine dell'apertura della tabella: la Ram utilizzata è 558 MB.....
Questo l'ho provato su una macchina biprocessore,256 mb Ram, Sql Server
2000, Sql server 7.0, ecc...
P.s. il Db è in locale..pensa a spostare una tabella di 195 MB tramite la
rete...io non lo farei.....
Ciao
oZ

 ha scritto nel messaggio
news:9j8tsu$me1mj$1...@ID-77238.news.dfncis.de...


 le connessioni, i rs e i command sono apreti e chiusi in ogni routine
OMISSIS
...io non mi vorrei ripetere....quindi farei alcune considerazioni...
se ti schizza ha poniamo 100mb ed hai nel tuo pc  256MbRam o anche meno ma
tutto va e non rallenta nulla non ci farei tanto caso.(non hai scaricato
l'intero archivio...e qualche allocazione che rimane nel pc)Si sa che zio
bill ha una gestione della mem a dir poco arzilla e che qualche task può
incasinare il tutto!
il problema è un altro....(secondo me)...
se usi SQL server in fase di analisi hai studiato le specifiche del tuo
cliente e  poni il tuo programma in un ottica client/server e sopratutto
multiutente...(altrimenti ti bastava Access!)...
a questo punto diventa fondamentale:
1) la rete
2) Il server che ospita SQL
e di conseguenza...
3) L'implementazione del tuo programma
più di quanto diventa grosso il tuo programma sul client diventa
fondamentale allora vedere se la rete rallenta (1)o ci sono molti pacchetti
in collisione e se il TASK su server di sql diventa enorme e rallenta(2)...
io ho fatto sempre così...
il più possibile di gestione su SQL server (stored procedure) (sono cacchi
del cliente aumentare la potenza del server...e poi sempre meglio aumentare
un server che 10 pc!)...naturalmente rete a 100 e vari trucchetti(tipo
scheda di rete con 4 uscite ...collegamento a switch etc etc)
Tassativo se usi ADO/OLEDB impostare le connessioni ADuseClient MAI fare
riferimento a tutta una tabella ...quindi mai aprire recordset di una
tabella "liscia" se non in  in casi particolarissimi (compattazione di
movimenti e spostamento su altri server, aggiustamenti "strani" su
registrazioni , etc etc) .
Ha prendere queste ed altre precauzioni non intasi la rete e la velocità
globale è sempre rimasta buona anche con client "disagiati"(win 98 64mb AMD
400mhz)
Bye man!
:-)

 cn.close: set cn=nothing
_prima_ di chiudere le Connection chiudi tutti i RecordSet che ha
originato?
Faber

 ha scritto nel messaggio
news:9j8vli$n5enl$1...@ID-77238.news.dfncis.de...
[snip]
ovviamente tutto questo con cursori client-side
ciao
ugo

 ha scritto nel messaggio
news:sQX57.150975$cd.8...@news1.tin.it...
CUT
