Ado.net lentissimo ?

venerdì 02 marzo 2007 - 22.24

McBarabba Profilo | Newbie

Signori chiedo aiuto...
sono in panne con il mio progetto e rischio grosso.

Il mio boss ha deciso di fare una nuova versione del programma che usiamo e dietro mio consiglio e per stare al passo con i tempi, siam passati dal rassicurante vb6 a vb.net.
Il problema è che il programma nuovo è 10.000 volte più lento del vecchio.

In sintesi tutto il programma si basa su una tabella dati (a video con datagrid o similari) con una trentina di campi per riga e una media di 3000 righe.

il datagrid deve ovviamente gestire le modifiche, gli aggiornamenti, le cancellazioni etc...

ma se provo a cancellare un bel po di righe (che in ado era istantaneo) qui ci mette pure MINUTI...

premetto che sto usando vb.net2003 (lo avevamo già acquistato).


ragazzi sono veramente disperato. qualcuno ha avuto lo stesso problema ? ??


alextyx Profilo | Expert

In realtà potresti usare comunque ADO anche in .net, ma te lo sconsiglio perchè poi ti metti in una situazione 'ibrida'. Mi ci sono trovato anch'io e poi ho deciso di passare ad ADO.Net. Effettivamente VB.Net, in generale, è più lento di VB6, ma se spesso si rivela improponibile in certi ambiti, mi sembra strano che il problema venga fuori su una applicazione di quel tipo. E' vero che ADO.net ha da passare per una 'via crucis' di oggetti, prima di arrivare all'origine dati, ma, pur non essendo molto addentro a questioni di database, mi viene da pensare che forse c'è qualche passo da ottimizzare. Due domande che, se non seviranno a me, magari forniranno dati utili per colleghi più esperti che dovessero leggere la discussione:

Stai usando un databinding (direi di sì da quello che hai scritto) e usavi lo stesso anche in ADO?

Che database stai usando?

Comunque sarebbe utile la testimonianza di qualcuno che ha messo alla frusta ADO.net con applicazioni 'toste', cosa che io non ho mai fatto.

McBarabba Profilo | Newbie

sto usando un MDB,
ma prima che qualcuno possa imputare a questo al colpa, devo dire che ho provato con MSSQL (anche se nn potrei, viste le specifiche, l'ho fatto per puro fine accademico) ma niente da fare.

Il mio atroce dubbio è dato dal fatto che secondo me tutto viene convertito in xml, che io lo voglia o meno.

esiste qualcuno che è in grado di fare una qualsiasi form con una insulsa datagrid collegata ad un db di 5000 righe (30 campi per riga) che funzioni decentemente ? (almeno proponibile)....


Io sto davvero rischiando il posto... ho comprato libri su libri ma non ho risolto nulla. non posso vendere una versione NUOVA del programma che però per salvarti il lavoro ci mette minuti invece che istantanea come prima....

suggerimenti ? accetto di tutto...

alextyx Profilo | Expert

Mah....purtroppo la mia esperienza è su database molto limitati. L'unica esperienza che ho di database giganteschi, non è diretta. E' un lavoro fatto per applicazione TV e al quale non ho partecipato direttamente e che si basa su MSSQL Express. Solo che lì, da quello che ho capito, il lavoro viene fatto lanciando delle procedure parametrizzate, cioè è il motore del database che fa tutto il lavoro.
Ripremettendo che ho solo qualche infarinatura dei problemi dei database, mi viene da pensare che se tu usassi comandi diretti (executenonquery), potresti migliorare le prestazioni. Se ciò non fosse possibile, prima di perdere il lavoro, prova a ributtare tutto sotto ADO, che è sicuramente un oggetto più 'centrato' per certi tipi di lavoro, però sarebbe un peccato. Sono convinto che se passase di qui un certo amico (non faccio nick), riuscirebbe a capire come risolvere il problema, dopo avermi pesantemente insultato per aver osato anche solo ipotizzare l'utilizzo di ADO!
Sono curioso anch'io di vedere se qualcuno potrà aiutare a chiarire se esiste una così grande differenza di velocità fra i due oggetti (ADO e ADO.Net), ovviamente se utilizzati nello stesso modo.

McBarabba Profilo | Newbie

guarda, per come sono messo, sono disposto anche a pagare per una soluzione funzionante...

è impensabile un calo di prestazioni di questo genere.

Quindi se conosci l'amico, magari fagli un fischio lungo tipo "fiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii"

grazie a tutti per l'aiuto

Stroke Profilo | Junior Member

Ho avuto il tuo stesso problema, database mdb e passaggio da vb6 a vb.net e da Ado ad ado.net. Database con tabelle di 240.000 record e 30 campi con una decina di joint da gestire a seconda delle interrogazioni. Tempi decuplicati.
Per risolvere ho iniziato a performare le query evitando i "select *" e nel frattempo sono passato a vs2005 utilizzando il datagridview. Non so dirti quale è stata la chiave di risoluzione, fatto sta che ora i tempi sono arrivati ad essere migliori di quando utilizzavo vb6 e ado.
Quindi ti consiglierei per prima cosa di provare ad ottimizzare le query ed eventualmente scaricaricarti vs2005 express.
Spero di esserti stato utile.
Ciao
Furio

rob88 Profilo | Junior Member

Come hai fatto x ottimizzare le query???

Teech Profilo | Expert

Per ottimizzare le query devi fare in modo che restituiscano solo i dati indispensabili cercando il minor impiego di risorse.
Ad esempio, se richiami sempre tutti i dati della tabella mentre ti servono solo un numero limitato di record puoi aggiungere delle clausole WHERE, oppure, se utilizzi delle sottoquery puoi provare ad eliminarle, ecc...
Non ci sono dei paradigmi per l'ottimizzazione, dipende dalla query.
--------------
Maurizio Brini
--------------
Nessuna impresa è mai stata compiuta da un uomo ragionevole

alexmed Profilo | Guru

Ciao
Premesso che non sono un esperto, soprattutto con database Access, mi chiedevo se potevi farci vedere un pò di codice che usi per capire se magari hai qualche impostazione che ti rallenta.

Ciao

alexmed
Partecipa anche tu! Registrati!
Hai bisogno di aiuto ?
Perchè non ti registri subito?

Dopo esserti registrato potrai chiedere
aiuto sul nostro Forum oppure aiutare gli altri

Consulta le Stanze disponibili.

Registrati ora !
Copyright © dotNetHell.it 2002-2024
Running on Windows Server 2008 R2 Standard, SQL Server 2012 & ASP.NET 3.5