Il problema si manifesta in tre specifiche situazioni, su tre server diversi (due con SQL Server 2005 e uno con Sql server 2005 express edition). Le due situazioni più urgenti sono entrambe su server di produzione che non possono essere cambiati.
Quello che mi fa arrabbiare è che sembra che in alcune situazioni il sistema smetta di eseguire correttamente le SELECT, ma anche le INSERT e le UPDATE (sulla DELETE non ho dati).
All'applicazione web sono connesse massimo 30 persone (è una intranet), con una media stabile però di solo 10. In alcuni momenti una SELECT (di solito straordinariamente semplice, visto che si tratta di leggere un record data la chiave) non risponde correttamente (il record esiste ma la datatable è vuota). Da questo momento tutti gli utenti sperimentano malfunzionamenti che si risolvono solo riavviando l'applicazione web.

Vi chiedo una cosa, che magari potrebbe essere correlata.

E' corretto secondo voi invocare esplicitamente il metodo Dispose() sugli adapter tipizzati che si utilizzano? Per prassi se un oggetto mette disponibile un metodo dispose ed io non son certo di quale tipologia di risorse vada ad utilizzare (managed o not managed) allora di norma invoco direttamente il Dispose() al termine del suo utilizzo (nel finally di un try catch, a scanso di equivoci).

Tale approccio lo uso anche sulle data table (sia tipizzate che generiche): appena ho finito di usare una datatable ne chiamo il dispose.

Chissà, forse questo problema può essere in un qualche modo legato a risorse che non eliminate correttamente vanno ad alterare il funzionamento dell'applicazione in genere?

vuoi dire che quando rilevi la table di lettura vuota e fai ( se lo fai ) la insert sulla table di log su un db di un' altro server, la insert fallisce?

Se così comincerei a pensare ad IIS, visto anche che solo IISRESET risolve la situazione.

Anche io , la notte, perso per perso il sistema, devo fare System.Diagnostics.Process.Start("IISRESET").

Fa schifo ma al mattino sono entrati altri ordini dal web...
ciao