Innanzitutto, un saluto :) è il mio primo post in questo forum.
Scrivo per un problema che trovo abbastanza singolare, spero che qualcuno riesca a darmi dei suggerimenti in proposito perchè brancolo nel buio.
Cercherò di essere il più chiaro possibile.
SCENARIO:
2 server in rete, entrambi Win 2003 server, uno con IIS 6.0 e la mia web application asp.net 2.0 e l'altro con SQL 2005 enterprise.
PROBLEMA:
Ho una stored procedure che restituisce un recordset di 2 colonne e che accetta 6 parametri di cui uno nvarchar(255), destinato a contenere un elenco
di date con separatore (es: "11/11/2008___;;___12/11/2008"). La stored procedure al suo interno poi usa questo parametro cercando determinati
valori all'interno di questa stringa con una function creata appositamente.
Da codice, chiamando questa stp (e impostando un elenco ad esempio di 5 date), il tempo per eseguire il metodo ExecuteReader del mio command è
di circa 12/13 secondi. La stessa stp, lanciata da interfaccia management studio, con i medesmi parametri, ha un tempo di esecuzione inferiore
al secondo.
Di seguito a questa stp ne vengono chiamate altre (a seconda di determinate scelte utente) che hanno un set di parametri identico e a cui vengono
passati gli stessi valori. Il loro tempo di esecuzione, stavolta, è pressochè immediato. Se questo elenco di date è vuoto, il tempo di esecuzione della
prima stp si allinea ai tempi delle altre (e a quelli della chiamata da interfaccia), come se passargli un valore nvarchar di 100 caratteri influisse
esageratamente sui tempi di preparazione del command. Ho provato a chiamare anche il metodo Prepare() del command prima dell' ExecuteReader
ma il collo di bottiglia è proprio l'execute reader.
Alcune note: il metodo di autenticazione sql è protezione integrata, la connection è aperta subito prima l'esecuzione del command e chiusa subito
dopo l'iterazione all'interno del recordset restituito (recorset che con i parametri di test che sto utilizzando contiene 1 riga di risultati),
il connection pool è attivo.
Non riesco a trovare un motivo valido perchè l'esecuzione di ExecuteReader dipenda così strettamente dalla lunghezza di quel parametro, visto che
chiamata da SQL la stp non ha pesantezza di sorta.
Se qualcuno ha idee sono ben accette :)
Grazie
Francesco Milano
Un aggiornamento: provando a passare a null il parametro nvarchar date, e passando l'elenco date in un altro parametro anch'esso nvarchar(255) (in questo caso il nome della persona,
modificato opportunamente in tabella db per dare risultati), l'esecuzione è praticamente istantanea. Quindi ne deduco che la lunghezza di questo
parametro non influisce sull'esecuzione...
Aggiungo il codice della stored procedure