sbonnini ha scritto:

mpolleschi ha scritto:

il comando arriva a SQL? controlla con Profiler.
ciao

Effettivamente non ho fatto questa verifica ... appena ho qualche risultato in merito vi aggiorno.

Ho fatto il test richiesto ed ho visto che la query arriva a SQL (ho usato appunto il profiler), ma nulla ritorna indietro, anche se - lo riconfermo - il record per l'utente richiesto era presente.

Nella configurazione di rete di SQL Server 2005, nei protocolli per MSSQLSERVER, erano attivi "Shared memory" e "TCP/IP", mentre nei protocolli per SQL Native Client erano attivi anche i "Named pipes". Secondo voi questo può contare? Tenete conto che la stringa di connessione che uso è così fatta:
connectionString="Data Source=SERVERNAME;Initial Catalog=DBNAME;Persist Security Info=True;User ID=sa;Password=****"

mpolleschi ha scritto:

scusa la banalità, ma hai provato a mettere una trim su username?
non so come raccogli questo parametro e tutto può succedere quando c'è input dall'utente.
a titolo diagnostico in caso di row.count==0 tenterei una seconda lettura programmaticamente loggando l'evento.
ciao

In effetti non ho inserito una trim quindi lo faccio subito :-) tuttavia con il debug ho verificato più volte che la stringa proveniente dalla textbox di login è corretta.

Effettivamente ho anche provato quello che hai detto tu. Ho cioè inserito una seconda query da eseguirsi solo quando Rows.Count==0: un SqlCommand con una SELECT hard coded, senza passare cioè attraverso un Table Adapter tipizzato. Ho verificato che nel caso in cui il TableAdapter tipizzato fallisca fallisce anche questa seconda query.
Ammetto che non so proprio più dove sbattere la testa. Il fatto è che quando si manifesta questo comportamento "assurdo" (tra virgolette perchè senz'altro una motivazione ci sarà), ogni successiva query o insert/update/delete fallisce o comunque manifestano comportamenti non prevedibili. Per esempio se l'utente che tenta di accedere inserisce non correttamente le credenziali procedo a scrivere una riga di log in TLogApplicazione. Questa tabella ha una chiave autoincrementante e l'inserimento lo faccio attraverso un banalissimo INSERT attraverso - ovviamente - un TableAdapter tipizzato. Questo insert fallisce clamorosamente se la query iniziale per vedere se l'utente esiste o meno nel database ha fallito. L'errore che viene dato è che - attenzione - "la chiave non può essere null"!. Va da sè, spero mi crediate, che l'INSERT che ho scritto non scrive proprio niente nella chiave (visto che è auto incrementante).
Boh ...

P.S.: il problema si è manifestato anche dopo che ho configurato nel medesimo modo SQL server e SQL Native Client con protocollo TCP/IP e Shared Memory attivate e Named Pipes disabilitate (prima erano abilitate nel native client e disabilitate sul server).
Ri-boh...

Veramente fantastico ... penso che adesso, giusto come tentativo, sostituirò l'uso del TableAdapter con quello di un SqlDataReader (che detto tra noi significa in effetti che non so che pesci pigliare).

Daniele Bochicchio ha scritto:

sei sicuro che non ci siano problemi con il database?
hai modo di provarlo con un altro server/versione?

In effetti questa prova per ora non riesco a farla perché purtroppo ho tempi strettissimi di consegna anche su altre cosette. Tuttavia ho una installazione con Microsoft SQL Server 2008 e proverò su quello: appena fatto vi aggiornerò.
Detto questo vi faccio notare che il medesimo comportamento l'ho riscontrato su tre applicativi diversi che hanno le seguenti caratteristiche:
1. Primo applicativo: ASP.NET 2.0, SQL 2005, os Windows XP ultimo sp;
2. Secondo applicativo: ASP.NET 4.0, SQL 2005, os Windows Server 2003 SE;
3. Terzo applicativo: come il secondo.
In tutti e tre i casi è presente IIS 6.0.