Stato connessione a server SQL

giovedì 20 luglio 2006 - 16.35

shark986 Profilo | Junior Member

Ciao a tutti....
Come posso controllare (dopo un probabile tempo di inattività dell'applicazione) se la connessione al database sql è ancora attiva?

Ho già visto la proprietà "state" della connessione ma rimane costantemente ad 1 (vbStateOpen).....

Datemi una mano per favoree!!!!

Grazie in anticipo!

P.S.: L'applicazione la stò realizzando in VB6....

alx_81 Profilo | Guru

Ciao!
Puoi spiegarti un po' meglio?
Rimane in attesa? durante che operazione (ad esempio insert, update...)? Ti torna un errore?
un po' più di dettagli in più.. =)
Alx81 =)

http://blogs.dotnethell.it/suxstellino

shark986 Profilo | Junior Member

>Ciao!
>Puoi spiegarti un po' meglio?
>Rimane in attesa? durante che operazione (ad esempio insert,
>update...)? Ti torna un errore?
>un po' più di dettagli in più.. =)
>Alx81 =)
>
>http://blogs.dotnethell.it/suxstellino

Pensavo fosse chiaro.....
Ho un'applicazione che si connette ad un db remoto...
Devo controllare che la connessione al db rimanga attiva per gestire l'eventualità in cui la connessione (per un motivo qualsiasi) sia caduta (ad esempio: l'utente ha lasciato il prog aperto e il db ha chiuso la connessione perkè inattiva; hanno staccato un cavo di rete; ...)

....

alx_81 Profilo | Guru

Ogni qual volta che apri una connessione, se non si verificano errori, hai la proprietà state a vbStateOpen.
Finchè non la chiudi (ovvero, oggettoConnessione.Close()) rimane tale..
Quindi controllare la proprietà state è giusto.. anche perchè gestisce anche le connessioni BROKEN, CLOSED, FETCHING, EXECUTING..

Alx81 =)

http://blogs.dotnethell.it/suxstellino

shark986 Profilo | Junior Member

>Ogni qual volta che apri una connessione, se non si verificano
>errori, hai la proprietà state a vbStateOpen.
>Finchè non la chiudi (ovvero, oggettoConnessione.Close()) rimane
>tale..

Il problema è proprio questo!!!
Mi spiego: io ho bisogno di controllare proprio che la connessione sia attiva, ma state rimane SEMPRE ad 1....
Ovvio che se chiudo la connessione lo state cambia, ma io non ho bisogno di controllare se chiudo la connessione ... io ho bisogno di controllare se la connessione salta per un motivo qualsiasi!!!
Metti che c'è un problema di rete... oppure l'utente lascia il programma aperto senza utilizzarlo... è probabile che il db server chiuda la connessione perchè non è utilizzata e cade in timeout!
Io è questo che devo controllare!
Il fatto è che da alcune prove che stò facendo (staccando i cavi di rete, disabilitando la scheda dei pc, arrestando il db server) mi accorgo che la proprietà state rimane sempre a 1......

...

alx_81 Profilo | Guru

ok.. adesso ho capito..
la state non cambia fino a che non esegui una nuova operazione, non sta "in ascolto"..
quindi io direi che potrebbe essere sufficente controllare la state ad ogni nuovo evento (una pressione di un button, la selezione da una combobox.. ecc.).. non credo tu riesca a fare un ascoltatore che alla caduta della connessione ti dia un alert..
forse con qualche API, ma proprio non ne ho idea..
mi appello agli esperti..
ti chiedo scusa ma non posso essere di aiuto..
Alx81 =)

http://blogs.dotnethell.it/suxstellino

shark986 Profilo | Junior Member

beh intanto non sapevo che che fosse una proprietà "non in ascolto" e quindi già mi hai dato una mano!!

cmq nel frattempo ho risolto con una sub che ad intervalli di tempo fà una "select top 1 ..." e se l'operazione non va a buon fine chiudo e riapro la connessione, ripetendo la query nel caso in cui la connessione è stata aperta senza errori....

magari non è proprio lineare ma funziona! (qui c'è il codice)

Public Sub ConnectionStateControl() On Error Resume Next Err.Clear Dim rs As ADODB.Recordset Set rs = New ADODB.Recordset rs.LockType = adLockOptimistic rs.Open "SELECT TOP 1 * FROM anagrafica1", m_conn, adOpenDynamic If Err.Number <> 0 Then m_conn.Close Err.Clear m_conn.ConnectionString = ConnectionString m_conn.ConnectionTimeout = 10 m_conn.Open If Err.Number = 0 Then rs.Close Err.Clear rs.Open "SELECT TOP 1 * FROM anagrafica1", m_conn, adOpenDynamic If Err.Number = 0 Then 'tutto ok! rs.Close Else 'errore End If Else 'errore End If Else 'tutto ok! rs.Close End If On Error GoTo 0 End Sub

Già che ci sono.... Nelle varie prove che ho fatto ho provato a sospendere (mettere in pausa anzichè in stop) il server sql però la query non restituisce alcun errore.... Sapete dirmi come mai?!?

se qualcuno avesse dei consigli siamo qua per imparare!!!!

e grazie!!

lbenaglia Profilo | Guru

>beh intanto non sapevo che che fosse una proprietà "non in ascolto"
>e quindi già mi hai dato una mano!!
>
>cmq nel frattempo ho risolto con una sub che ad intervalli di
>tempo fà una "select top 1 ..." e se l'operazione non va a buon
>fine chiudo e riapro la connessione, ripetendo la query nel caso
>in cui la connessione è stata aperta senza errori...

Perdonami, ma non sarebbe più semplice gestire l'eccezione in tutte le procedure che accedono al db riaprendo la connessione?
A parte che tenere aperta una connessione per tutta la durata della sessione di lavoro è una pessima idea in quanto allochi inutilmente risorse sul client (e questo vabbé...), sul server (e questo invece è MOLTO grave), aumenti a dismisura i lock o peggio i deadlock, diminuisci la scalabilità dell'applicazione e delle altre che eventualmente si appoggiano al server.
Sono ormai parecchi anni che le best practices suggeriscono di aprire una connessione per lo stretto necessario all'esecuzione di un comando, soprattutto in ambito web.

Ciao!

--
Lorenzo Benaglia
Microsoft MVP - SQL Server
http://blogs.dotnethell.it/lorenzo/
http://italy.mvps.org

shark986 Profilo | Junior Member

>Perdonami, ma non sarebbe più semplice gestire l'eccezione in
>tutte le procedure che accedono al db riaprendo la connessione?

è più o meno quello che faccio...

>A parte che tenere aperta una connessione per tutta la durata
>della sessione di lavoro è una pessima idea in quanto allochi
>inutilmente risorse sul client (e questo vabbé...), sul server
>(e questo invece è MOLTO grave), aumenti a dismisura i lock o
>peggio i deadlock, diminuisci la scalabilità dell'applicazione
>e delle altre che eventualmente si appoggiano al server.

beh l'applicativo dovrebbe girare solo su 2 macchine quindi non penso ci siano più di tanti problemi...

>Sono ormai parecchi anni che le best practices suggeriscono di
>aprire una connessione per lo stretto necessario all'esecuzione
>di un comando, soprattutto in ambito web.

e appunto è un applicativo in una piccola lan non ha nulla a che fare col web....

cmq grazie dell'intervento e del consiglio!!
Partecipa anche tu! Registrati!
Hai bisogno di aiuto ?
Perchè non ti registri subito?

Dopo esserti registrato potrai chiedere
aiuto sul nostro Forum oppure aiutare gli altri

Consulta le Stanze disponibili.

Registrati ora !
Copyright © dotNetHell.it 2002-2025
Running on Windows Server 2008 R2 Standard, SQL Server 2012 & ASP.NET 3.5