Dopo svariate ricerche sulla rete, mi pare di comprendere che questo sia uno dei tanti punti oscuri nella documentazione di Microsoft.
A quanto ho capito i codici di errore della SQLException possono provenire da un minestrone di fonti diverse (ovviamente non decodificabili da informazioni passate nella SQLException).
Qua ho trovato alcune dritte utili :
Alcuni errori sono a livello di sistema che non hanno nulla a che fare con Sql Server ma sono generati da servizi che SQL Server utilizza (e aggiungo io dal software client di connessione)
Ad esempio, l'errore 2 è FILE NOT FOUND, l'errore 53 è "Network path not found" o qualcosa del genere. Errori simili a 10XXX sono di solito errori TCP/IP o Winsock. Il codice di errore 10061 significa "Connection Refused"
Se non trovi l'errore nei Books Online prova a cercare tra i codici di errore di Win32 nell'SDK
Ovvero da nessuna parte esiste una lista esaustiva dei codici di errore per il semplice fatto che non può esistere, potendo gli errori provenire da n diverse fonti.
Ho anche reperito anche alcuni snippet come il seguente
codice:
switch (ex.Number)
{
case -2:
//Connection timeout
break;
case 18456:
case 1326:
//login failed
break;
case 4060:
//if database is not found
break;
case 229:
//login credentials check
break;
case 2601:
case 2627:
//unique key voilation
break;
case 547:
//Foreign Key voilation.
break;
default:
//any other exceptions
}
la lista non è esaustiva o quanto meno non esaurisce i casi che mi piacerebbe catturare, pertanto considero il caso chiuso senza soluzioni praticabili.
Lascio questo scritto a futura memoria, per quanto riguarda invece la mia applicazione ho deciso di considerare l'ipotesi di avere gli operatori per la maggior parte del tempo sotto copertura, in modo tale che per loro non sarà una tragedia ricevere un errore di transazione fallita nonostante la loro richiesta di transazione possa essere perfettamente legale ma impossibile da eseguire a causa della mancanza di segnale.
Rispondi quotando
