Newsgroup: it.comp.lang.visual-basic
Titolo: è plausibile questa spiegazione ?

comunicato della softwarehouse che ci fornisce il programma( a proposito di 
rallentamenti nel gestionale scritto in 
VB.NET
 , archivi MS access 2000, 
motore Jet sp8 .
E' un gestionale nativo win32 ):
i rallentamenti riscontrati nell'utilizzo di alcune funzioni del gestionale 
, sono determinati dal nuovo componente ADO 2.8  (che ha sostituito il DAO 
in precedenza usato) necessario per la lettura/scrittura di database di 
diverso formato (Access 2000  e MSDE/SQL Server)....
Vi risulta ?
ciao e  grazie 

 diverso formato (Access 2000  e MSDE/SQL Server)....
Chiaramente non posso sapere cosa intendi per 'rallentamenti'...l'unica
cosa che ti posso dire che, _dipendentemente_ da come è scritta
l'applicazione, le connessioni ad un MDB attraverso il  Jet hanno un
'tempo di latenza' tra il momento in cui si scrive il dato in una
tabella ed il momento in cui il nuovo dato viene caricato nella cache
della connessione e questo può provocare rallentamenti nel senso che
l'applicazione deve 'aspettare' che il nuovo valore sia disponibile...
guarda questa discussione:
http://groups.google.it/group/it.comp.lang.visual-basic/browse_frm/thread/b6a170d91065e5d4/08db6bc607c178b6?lnk=gst&q=Multiutenza+sun+MDB&rnum=1&hl=it#08db6bc607c178b6
ciao
Daniele.

 diverso formato (Access 2000  e MSDE/SQL Server)....
Chiaramente non posso sapere cosa intendi per 'rallentamenti'
In un form ( ad es. CLIENTI , FATTURE , etc) se tento di scorrere i record 
presenti con le solite frecce ci impiego 2 secondi a passare
da un record all'altro , prima ci mettevo qualche decimo di secondo !
Capita con MDB di qualche decina di MB ( 50.000 righe ad esempio ) . Con 
archivi piccoli il rallentamento e impercettibile.
ciao 

 archivi piccoli il rallentamento e impercettibile.
Se con piccoli archivi questo rallentamento non c'è...mi viene da
pensare che sia dovuto a come è scritto il software...ma ovviamente
senza conoscere il codice questo mio pensiero non ha valore!
Ciao,
Daniele.

 archivi piccoli il rallentamento e impercettibile.
Detto così è un po' difficile da dire: le concause potrebbero essere 
molteplici.
Così a occhio direi che l'uso di ADO anzichè DAO benchè più lento non 
dovrebbe produrre rallentamenti percettibili a parità di condizioni.
Però non ho capito: prima era un win32 + dao e ora un 
vb.net
 + ADO?
Gli archivi sono rimasti Access?
L'unico rallentamento detto così (poi in pratica è tutto da vedere) potrebbe 
essere dato da un 
vb.net
 + ado anzichè un 
vb.net
 + 
ado.net
, dove .net per le 
chiamate a oledb potrebbe metterci di più.
Comunque sia, se il sw è diventato "inutilizzabile" per me potrebbero averci 
messo sotto anche un acceleratore di particelle ma il problema va risolto.
Ciao 

 Gli archivi sono rimasti Access?
 era VB6  +dao   (  win 32 nel senso che è nativo windows e non deriva dal 
DOS o Cobol )
ciao 

 ha scritto nel messaggio news:456cb799$0$7638


e adesso?
Tanto per curiosità.
Ciao 

gabriele ha spiegato il 28/11/2006 :

Non farti prendere per il culo.
In 
VB.NET
 non si utilizza ADO 2.8
Cioè, lo si può utilizzare, con una forzatura, ma è una porcheria. Sia 
perchè 
ADO.NET
 è decisamente più veloce (almeno così mi sembra), sia 
perchè per utilizzare ADO2.8 occorre appoggiarsi a dll esterne, e 
questo è comunque una cosa assurda.
E' vero che, in un applicativo in VB6, occorreva passare da DAO a ADO 
per poter usare MSDE, ma 
VB.NET
 *NON* è VB6.
Ciao
Alberto
-- 
Karl Marx: Uno scrittore è produttivo non nella misura in cui produce 
idee, ma nella misura in cui arricchisce l'editore che pubblica le sue 
opere.

 comunque una cosa assurda.
Sei sicuro?
Per access in .Net io devo usare un provider OleDB generico, che viene 
installato con il jet.
Quindi secondo me passa comunque per ADO (sinceramente non ricordo).
Se usi un provider specifico come per SqlServer allora questo non accade.
Ciao 

 senza conoscere il codice questo mio pensiero non ha valore!
idem, magari come al solito ora di cambia il dao e poi si ottimizzera' 
meglio !
Purtroppo il cambio e' anche un cambio di architettura del software che puo' 
sfruttare le migliorie del net o subirne i rallentamenti...
-- 
Gigio2k
www.g2kweb.it
mi trovi su --> 
http://www.g2kweb.it/?3099
 

 Se usi un provider specifico come per SqlServer allora questo non accade.
Cosa centra il provider con la libreria?
Sono su due livelli diversi.
Se usi un provider .Net, come per Sql-Server, allora il livello 
libreria e il livello provider sono fusi insieme (che poi non si 
discosta molto dal vecchio DAO). Ma se usi un provider generico, come 
appunto JET, la libreria è Ado.Net, e il provider è Jet.
Ado2.X non solo non serve, ma può addirittura non essere neppure 
installato sulla macchina.
Ciao
Alberto
-- 
Charles Baudelaire: C'è un solo modo di dimenticare il tempo: 
impiegarlo.

 il provider è Jet.
Non è vero, perchè non usi il direttamente provider jet, ma passi attraverso 
il layer dell'oledb.
Ciao 

Fabio ha pensato forte :

Jet è un OleDb, e si collega ad Ado.Net attraverso il linker generico 
per OleDb.
Ma NON passi per Ado.
Ciao
Alberto
-- 
L'economia sa tutto di te e tu non sai niente dell'economia. La tua 
banca sa tutto di te, di quanti soldi hai, e quando li spendi; ma tu 
non sai niente di cosa fa la banca dei tuoi soldi e dove li mette, e se 
ce li ha!