[vb.net] datareader lento

mercoledì 09 dicembre 2009 - 10.42

tankian Profilo | Junior Member

Ciao, mi sono imbattuto a dover aggiornare una procedura che era stata fatta tempo fa (non da me) molto semplice.

Praticamente all'evento SelectedIndexChanged di un ComboBox, popolo altri due ComboBox con un datareader. (il DB è SQL Sevrer 2k5)

L'unico problema è che la popolazione della procedura nuova è molto più lenta , ma il fatto è che dopo aver fatto moltissime prove per capire cosa la rendeva così lenta, ho brutalmente copiato ed incollato le due procedure, cambiando gli oledb con sqlclient.

L'unica differenza rimasta è la stringa di connessione:

Stringa vecchia:

str = "Provider=SQLOLEDB.1;Data Source=" + path + ";Initial Catalog=" + DB + ";Integrated Security=SSPI"

Stringa Nuova:

str = "Data Source=" & server & ";Initial Catalog=" & DB & ";Integrated Security=SSPI;Persist Security Info=False"


Qualcuno ha qualche idea su dove indirizzarmi a controllare?

Brainkiller Profilo | Guru

>L'unico problema è che la popolazione della procedura nuova è
>molto più lenta , ma il fatto è che dopo aver fatto moltissime
>prove per capire cosa la rendeva così lenta, ho brutalmente copiato
>ed incollato le due procedure, cambiando gli oledb con sqlclient.

La pipeline che viene eseguita è molto lunga ed è difficile identificare così rapidamente dove è la lentezza.
Gli elementi che vengono recuperati dal database e che sono usati per riempire le combo quanti sono ?
Hai già fatto le verifiche del caso sul database ? indici a posto ? ecc. ?
Ciao

David De Giacomi | <empty>
http://blogs.dotnethell.it/david/

tankian Profilo | Junior Member

>La pipeline che viene eseguita è molto lunga ed è difficile identificare così rapidamente dove è la lentezza.
>Gli elementi che vengono recuperati dal database e che sono usati per riempire le combo quanti sono ?
>Hai già fatto le verifiche del caso sul database ? indici a posto ? ecc. ?


Ciao, gli elementi possono variare da 6 fino a 2000 circa.

Le verifiche non le ho fatte per il semplice fatto che si tratta dello stesso database e della stessa query identica in entrambe le procedure.

La differenza tra le due è di 6-7 secondi (quando gli elementi sono 2000) quindi ho pensato potesse essere la stringa ma non è così...

Brainkiller Profilo | Guru

>Ciao, gli elementi possono variare da 6 fino a 2000 circa.

6/7 secondi di differenza mi sembrano tanti.
Ma quindi se tu torni alla connection string vecchia va tutto veloce ?

>Le verifiche non le ho fatte per il semplice fatto che si tratta
>dello stesso database e della stessa query identica in entrambe
>le procedure.

Prova ad effettuare la query da SMSS o Query Analyzer e vedi in quanto tempo ti vengono restituiti i risultati.

>La differenza tra le due è di 6-7 secondi (quando gli elementi
>sono 2000) quindi ho pensato potesse essere la stringa ma non
>è così...

Qualora non dovessi risolvere puoi ipotizzare anche l'uso sel caching. Quindi al primo popolamento è più lento mentre dal 2° in poi prendendo i dati da disco o da memoria è molto velocizzato (quindi tempo 0)
Ciao

David De Giacomi | <empty>
http://blogs.dotnethell.it/david/

tankian Profilo | Junior Member

ciao, ho beccato l'intoppo-.-

combobox1.AutoCompleteSource = AutoCompleteSource.ListItems


Avevo settato questa proprietà e rallentava di almeno 6-7 secondi la popolazione dei combo.
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