Newsgroup: it.comp.lang.visual-basic
Titolo: Server sql inesistente o accesso negato

Un'applicazione VB (della quale gi� scrissi in altro 3d) esegue un lungo
ciclo di letture e scritture su un db SQL Server. Il programma � installato
su centinaia di macchine con le pi� varie configurazioni e sembra funzionare
correttamente. Presso un solo cliente, si riscontra un'anomalia.
Dopo aver elaborato correttamente i dati di una sessantina di dipendenti, il
programma si interrompe e segnala il seguente messaggio di errore:
[DBNetLib][Server sql inesistente o accesso negato]
Dopo la segnalazione di errore, il programma riprende a funzionare e termina
correttamente.
L'errore si verifica se il programma viene eseguito attraverso la rete, 
mentre non si verifica se viene eseguito sulla macchina che fa da server 
SQL.
In ufficio non si riesce a riprodurre l'errore, nemmeno su un VirtualPC con
pochissime risorse; anche l'esecuzione in rete non pare che dia problemi.
Presso il cliente, l'errore non si manifesta sempre, ma quasi e, quando si
verifica, lo fa sullo stesso dipendente, ma non sempre nello stesso punto di
programma (una volta, leggendo dalla tabella A, un'altra volta leggendo
dalla tabella B, una terza volta leggendo dalla tabella C...). Il comune
denominatore � l'apertura di un recordset per leggere dati da una tabella
del db.
Aggiungendo una semplice msgbox al codice, prima dell'elaborazione del 
dipendente incriminato, l'errore non si verifica.
Mi era venuto in mente che potevano rimanere recordset aperti e che il 
programma, per qualche motivo, arrivasse ad esaurire qualche risorsa.
In effetti, ho trovato nel codice alcuni recordset aperti e non chiusi; li 
ho chiusi e impostati a Nothing al termine di ogni procedura.
Mi aspettavo di vedere qualche miglioramento, ma il comportamento del 
programma � rimasto esattamente lo stesso: si ferma sempre nello stesso 
modo, sullo stesso dipendente, facendo le stesse cose che un attimo prima e 
un attimo dopo sembrano funzionare perfettamente.
Qualcuno sa darmi qualche suggerimento?
Ciao!
    Alex

 
[cut]
problemi di controllo dell'input?
qualche apice che fa scazzare il tutto?
le elaborazioni sono fatte tramite sql costruito dal codice oppure 
tramite chiamate a stored procedures?
provato a cambiare metodo (da sql a sp o viceversa)?
-- 
Paolo opg
BE AWARE that this post uses a fake reply-to address
to contact me write to:
janickg ( at ) hotmail ( dot ) com
--

 magari dal cliente hai sp2 e tu usi sp3, tanto per dire...
Riprodotto proprio un minuto fa il problema: si verifica se il server SQL � 
un Windows 2003.
    Alex

 attimo dopo sembrano funzionare perfettamente.
L'aleatorietï¿œ ï¿œ un indice importante.
Se tu stessi sbagliando una password, oppure non fossi autenticato NT 
(a proposito, un errore come quello presuppone di concentrarsi sulla 
sicurezza del SqlServer e sulla rete, e sono le uniche cose di cui non 
parli), avresti il totale non funzionamento del software (sempre che il 
software non usi credenziali diverse per operazioni diverse, nel qual 
caso dovresti sapere tu).
Il fatto che in genere vada, ma che si fermi nel compiere una 
determinata operazione su un determinato record, fa pensare a qualcosa 
di collegato alla specifica elaborazione.
E sai solo tu cosa avvenga per ogni elemento da gestire. Ad esempio, 
avvengono sempre le stesse cose per ciascun dipendente, o avvengono 
cose diverse per dipendenti diversi? Se cosï¿œ fosse, verificherei cosa 
avviene per quel dipendente e che non avviene per gli altri.
O anche solo se per quel dipendente devono essere eseguite operazioni 
piï¿œ lunghe, potrebbe esserci un timeout, poi cerchi di riconnetterti ma 
magari non hai attivato il persist-security-info, o cose del genere.
Purtroppo, oltre non si puï¿œ dire senza sapere esattamente cosa avvenga 
per quel dipendente.
Ciao
Alberto
-- 
Alessandro Bergonzoni: Il tempo vola e noi no. Strano sarebbe se noi 
volassimo e il tempo no, il cielo sarebbe pieno di uomini con 
l'orologio fermo.

 non hai attivato il persist-security-info, o cose del genere.
In realt�, il programma non si ferma sempre nello stesso punto preciso: si
blocca sull'elaborazione dello stesso lavoratore (talvolta quello
successivo), ma non sempre nella stessa routine. Il programma, per ogni
lavoratore, legge dati da diverse tabelle, esegue delle elaborazioni, scrive
i risultati. L'errore si verifica di volta in volta durante la lettura di
una tabella diversa.
L'oggetto connection viene aperto solo una volta, all'inizio
dell'elaborazione, e viene chiuso una volta, al termine dell'esecuzione
(questo potrebbe essere fonte di problemi?).
Nel corso dell'elaborazione, diversi recordset vengono aperti e (se non mi
son perso qualcosa) chiusi.
Spero di essermi spiegato.
E' come se si esaurisse un determinato spazio per un numero limitato di 
interrogazioni del database, superato il quale tutto si blocca; il gestore 
dell'ipotetico spazio per le interrogazioni sfoltisce man mano la coda, ma 
se la velocit� con cui vengono aperte connessioni al db � troppo veloce, la 
coda finisce per saturarsi.
Se si rallenta l'elaborazione, la coda non si riempie; per lo stesso motivo, 
dopo la segnalazione dell'errore, tutto riprende a funzionare: il gestore 
delle connessioni al db, nel frattempo, � riuscito a svuotare la coda.
Finora, ci� che ho constatato � che l'errore sembra verificarsi solo se il 
server SQL � Windows 2003.
    Alex

Il problema sembra riguardare i pc client connessi a Windows 2003 con SQL 
Server 2005.
In attesa di capire un po' meglio e di indagare sull'eventuale eccesso di 
risorse sfruttate (e magari lasciate "appese") dal programma, per il 
momento, mi pare di aver risolto impostando sui pc client le seguenti chiavi 
di registro:
- MaxUserPort
- TcpTimedWaitDelay
http://www.sqlservermart.com/SQLServer.aspx
http://support.microsoft.com/kb/328476
Grazie moltissime a Paolo, Albe e a tutti per la disponibilit�.
Ciao!
 Alex

 server SQL ï¿œ Windows 2003.
Forse con W2003 il connection pooling funziona in modo diverso, in 
effetti ï¿œ una cosa che la stessa MS ha 'deprecato' subito dopo averla 
inventata.
Comunque vado a sentimento, io ho sempre evitato questo tipo di 
approccio...
Alberto
-- 
Charles Baudelaire: C'ï¿œ un solo modo di dimenticare il tempo: 
impiegarlo.

 approccio...
Che ti devo dire...? Io sono senz'altro un ignorante, ma questo tipo di 
approccio non me lo sono scelto io. :-)
Grazie ancora.
    Alex


in parole povere, il connection pool e' nato in quanto la genesi di una 
connessione e' un'operazione dispendiosa :)
in tal modo, le connessioni rilasciate non vengono immediatamente distrutte 
ma restano nel pool per circa 1 minuto prima del reale rilascio completo.. 
cio' consente di poterle "ripescare" senza dover generarne di nuove, cosa 
che, nuovamente, e' un'operazione costosa..
perche' una connessione possa essere resuscitata e' pero' necessario che la 
stringa di connessione sia completamente uguale, a livello letterale, anche 
in termini di spazi o quant'altro.. diversamente questa non potra' essere 
riutilizzata..
saluti
-- 
Andrea Montanari (Microsoft MVP - SQL Server)
http://www.asql.biz
DbaMgr2k ver 0.21.1 - DbaMgr ver 0.65.1 and further SQL Tools
http://www.hotelsole.com
 - 
http://www.hotelsolericcione.de
--------- remove DMO to reply