Test di effettiva connessione al database

di il
13 risposte

Test di effettiva connessione al database

Salve a tutti.
Quando ci colleghiamo via codice ad un Database che sia esso SqlServer, MySql o qualsiasi altro, abbiamo la possibilità di testare lo stato della nostra connessione con la proprietà State.

C'è però un problema. Lo stato della connessione non effettua nessun test di effettiva connessione al database ma si limita a riportare lo stato fino all'ultima operazione precedente eseguita. Mi spiego con qualche riga di codice. 

'Utilizzo una connessione SqlServer
Dim cn As New SqlConnection ("Data Source = server_name; Initial Catalog = database_name; Integrated Security = True") 
Try
    cn.Open () 
    Console.WriteLine ("Lo stato della mia connessione è :" & cn.state)
    Stop
Catch
    Console.WriteLine ( "Impossibile connettersi!")
Finally
    cn.Close ()
End Try

Se la connessione va a buon fine il programma si interrompe sullo stop.
A questo punto stacco il cavo lan dal pc o provo a disconnettere la wireless o semplicemente interrompo i sevizi di SqlServer insomma simulo una disconnessione fisica ed effettiva dal database senza fermare il mio debug.
Torno sul mio codice e sposto il punto di breakpoint (che al momento è fermo sullo stop) all'operazione precedente ovvero 

Console.WriteLine ("Lo stato della mia connessione è :" & cn.state)

Ebbene noterete che la connessione risulta ancora aperta e non ha cambiato stato.
Questo cosa significa? 
Significa che se non si effettuano prima operazioni (tipo di interrogazione di una tabella o di scrittura per esempio) sulla connessione la proprietà State non sarà mai precisa.
Mi sto sbagliando ? Ci sono metodi più efficaci per testare la connessione al database?
Al momento per essere sicuri se la connessione è ancora aperta e valida la devo testare con una semplice Select top 1 ‘nomecampo’ from MiaTabella.
Qualcuno può suggerire altri metodi?

13 Risposte

  • Re: Test di effettiva connessione al database

    Lo stesso discorso vale per il “testare la connessione ad Internet”, ma è una questione abbastanza irrilevante in verità.

    Mi spiego di seguito.

    04/09/2023 - Vincenzo76 ha scritto:


    Qualcuno può suggerire altri metodi?

    Il metodo più efficace è tentare di eseguire una operazione: se questa riesce, la connessione è OK, altrimenti ti ritroverai con l'errore.

    Non ha senso testare prima, in quanto potrebbe accadere che il test vada a buon fine e la connessione si perda appena dopo, tra il test e l'utilizzo della connessione stessa per eseguire un comando.

    Non c'è un modo “ufficiale” perché non ha senso farlo.

    Se la connessione è ballerina e avvengono disconnessioni frequenti, forse conviene adottare un altro modo di accedere ai dati, ad esempio tramite una Web API che via HTTP è stateless.

  • Re: Test di effettiva connessione al database

    Si è proprio questo il punto. 
    La connessione può cadere subito dopo. 
    Quindi se è questa l'unica strada, continuerò ad usare questa.
    Ma mi chiedo a che serve la proprietà State allora?

  • Re: Test di effettiva connessione al database

    04/09/2023 - Vincenzo76 ha scritto:


    Ma mi chiedo a che serve la proprietà State allora?

    La connessione può essere aperta, chiusa o trovarsi in un altro stato esplicitamente.

    Io potrei avere la necessità di aprire una connessione, chiuderla e poi riaprirla: l'oggetto che rappresenta la connessione stessa e il suo stato ha il dovere logico di memorizzare questa informazione.

    Ciò non autorizza la classe a prendersi la briga di fare altre operazioni, tipo controllare in background se la connessione è fisicamente perennemente attiva o cessata, perché magari 1) non mi interessa saperlo, come effettivamente è, 2) l'operazione può avere un costo computazionale.

  • Re: Test di effettiva connessione al database

    04/09/2023 - Vincenzo76 ha scritto:


    Ma mi chiedo a che serve la proprietà State allora?

    Per la connessione di rete ci pensa il s.o. (se manca internet o rete assente viene notificato)

    Lo stato della connessione al db significa che hai tutti i parametri per dialogare col db. Supponi di avere il db A e il db B lo stato ti dice che sei configurato per il db A

    Considera che essere connessi al db non significa che i dati transitano finché non chiudi la connessione. In realtà se apri una tabella invii una richiesta al server, il server ti invia quanto chiesto e chiude.

    A titolo di esempio, se apri un file txt mandi al pc il comando di leggere e visualizzare il contenuto del file. Ma un altro utente può fare la stessa richiesta e addirittura modificare e salvare il file mentre tu ancora visualizzi il file ante modifica.

  • Re: Test di effettiva connessione al database

    04/09/2023 - sihsandrea ha scritto:


    Considera che essere connessi al db non significa che i dati transitano finché non chiudi la connessione. In realtà se apri una tabella invii una richiesta al server, il server ti invia quanto chiesto e chiude.

    In realtà non è propriamente così, poiché non si tratta di una comunicazione HTTP.

    Quando attivi una connessione, un socket viene effettivamente aperto verso il server, e in alcuni casi addirittura più di uno se siamo in presenza di un pool.

    In breve, non è vero che il server “invia e chiude”, altrimenti eseguire comandi con o senza connessione avrebbe le stesse tempistiche e non è così. Il server risponde, ma la connessione rimane attiva e risulta peraltro elencata in apposite tabelle di sistema sulla maggior parte dei database.

    04/09/2023 - sihsandrea ha scritto:


    A titolo di esempio, se apri un file txt mandi al pc il comando di leggere e visualizzare il contenuto del file. Ma un altro utente può fare la stessa richiesta e addirittura modificare e salvare il file mentre tu ancora visualizzi il file ante modifica.

    Ma questo non ha a che vedere con la connessione al DB: non è detto che se una procedura usa un determinato protocollo che prevede apertura e chiusura del socket, tutte le comunicazioni di tipo client/server debbano avvenire con le stesse modalità.

  • Re: Test di effettiva connessione al database

    04/09/2023 - Alka ha scritto:


    In breve, non è vero che il server “invia e chiude”, altrimenti eseguire comandi con o senza connessione avrebbe le stesse tempistiche e non è così. Il server risponde, ma la connessione rimane attiva e risulta peraltro elencata in apposite tabelle di sistema sulla maggior parte dei database.

    Hai sempre un timeout

    04/09/2023 - Alka ha scritto:


    Ma questo non ha a che vedere con la connessione al DB: non è detto che se una procedura usa un determinato protocollo che prevede apertura e chiusura del socket, tutte le comunicazioni di tipo client/server debbano avvenire con le stesse modalità.

    Era un esempio per far capire cosa avviene. Non è che se parliamo di token usiamo i gettoni del bingo… stiamo parafrasando come “gettone di richiesta”.

  • Re: Test di effettiva connessione al database

    04/09/2023 - sihsandrea ha scritto:


    Hai sempre un timeout

    Non capisco cosa c'entra. Tu scrivi che "il server quando risponde a un comando poi chiude”. Invece, non chiude niente.

    04/09/2023 - sihsandrea ha scritto:


    Era un esempio per far capire cosa avviene.

    Era un esempio sbagliato, perché l'accesso ai file è totalmente diverso da quello che avviene nell'accesso al DB.

    04/09/2023 - sihsandrea ha scritto:


    Non è che se parliamo di token usiamo i gettoni del bingo… stiamo parafrasando come “gettone di richiesta”.

    Scusa ma, oltre a non aver capito di cosa stai parlando, non capisco cosa c'entri. :)

    Si stava parlando di database, di connessioni e del perché c'è una proprietà che indica lo stato della connessione: questa non viene chiusa, e si comporta in modo del tutto diverso dall'accesso ai file, quindi non capisco la finalità di questi esempi, di “gettoni” o di non so che... :|

  • Re: Test di effettiva connessione al database

    Giusto per precisione:

    il DBMS/DB server NON CHIUDE LA CONNESSIONE

    E sempre responsabilità del client creare la connessione, chiuderla, cosi' come creare la transazione e chiuderla con commit/rollback. 

    poi' c'e' il discorso del connection pool, che si dovrebbe sempre usare, che fa sì che la connessione non venga realmente chiusa ma solo messa nel pool in attesa del prossimo utilizzo. 

    Ma questa e' un'altra storia. 

    Per esperienza, non sempre le strutture dati adibite alla gestione della connessione al dbms si accorgono se la connessione tcp/IP e' stata interrotta. se ne accorgono di sicuro durante l'esecuzione del primo statement dopo l'interruzione della stessa. 

    Ma questo dovrebbe essere un fatto mooooooooolto raro. Se accade con regolarità serve

    capire perche' avviene

    se non c'e' modo di evitarlo, serve un meccanismo intelligente di riconessione automatica e riesecuzione dello statemenrlt. 

    Complicato anche se non difficile . 


    Attenzione a non far “confusione” con le connessioni HTTP che funzionano proprio in questo modo: il client apre la connessione, fa una richiesta, il server risponde e la chiude.

    Anche qui, non e' detto che la chiuda veramente, magari la connessione rimane aperta per un certo tempo per permettere la comunicazione in modo piu' efficiente


    Il discorso con il file e' TUTTA un'altra storia, e non centra nulla con una connessione TCP/IP: la possibilita da parte di UN'ALTRO client di leggere o modificare un file dipende dal SO e dai permessi durante l'apertura da parte del PRIMO client. Si puo' fare ma anche no.

    Insomma e' come confrontare mattoni con biondine in spiaggia: si puo' anche fare, ma di sicuro i mattono non sono un valido sostituto ;-)

  • Re: Test di effettiva connessione al database

    05/09/2023 - migliorabile ha scritto:


    Giusto per precisione: […]

    Per quanto possa valere, quoto in toto. :)

  • Re: Test di effettiva connessione al database

    05/09/2023 - migliorabile ha scritto:


    il DBMS/DB server NON CHIUDE LA CONNESSIONE

    Magari mi sono espresso male io…

    Intendevo far capire che connessione al db non ha lo stesso valore di una connessione ad una rete.

    Che la connessione sia attiva (o risulta tale) non significa che server e client scambiano ping…

    Il server resta in ascolto, ovvio che risponde alle richieste e non fa di testa sua.

    I casi di mancata connessione sono tanti, anche se la rete funziona.

    Era questo il messaggio. Per questo ho fatto l'esempio del file di testo. Anche quando apro un file lo manipolo in memoria prima di confermare il salvataggio (richiesta/risposta).

    La domanda

    04/09/2023 - Vincenzo76 ha scritto:


    Ma mi chiedo a che serve la proprietà State allora?

    Indica che è avvenuta una connessione, cioè il client ha i permessi, si collega a quel o quei database anche se di fatto il client non sta inviando richieste al server. 

    Forse con questo si riesce a capire il significato di connessione:

    https://learn.microsoft.com/it-it/sql/reporting-services/troubleshooting/troubleshoot-server-and-database-connection-problems-with-reporting-services?view=sql-server-ver16

    Quanto alla ragazza: beh se si usa l'espressione “alza un muro davanti a sé” non vuole significare che fa il muratore ne tantomeno che la donna è fatta di mattoni.

  • Re: Test di effettiva connessione al database

    Quindi la proprietà riporta l'ultimo stato rilevato e non lo stato effettivo e l'unico test per controllare che la comunicazione tra server e client è ancora in corso è quella di “chiedere qualcosa” al database.

    Grazie a tutti per il supporto.

  • Re: Test di effettiva connessione al database

    06/09/2023 - Vincenzo76 ha scritto:


    Quindi la proprietà riporta l'ultimo stato rilevato e non lo stato effettivo e l'unico test per controllare che la comunicazione tra server e client è ancora in corso è quella di “chiedere qualcosa” al database.

    Non è uno stato “rilevato”. Se chiedi di aprire la connessione, la richiesta verrà mandata alla libreria client per instaurarla con il server: se l'operazione va a buon fine, lo stato viene messo a “connected” (o similare), se non va a buon fine verrà sollevata ipoteticamente una eccezione.

    Da quel momento, lo stato è “connesso”, a prescindere da quello che succede sul socket che in genere non viene monitorato costantemente.

    E' come se fosse un campo, una variabile, una informazione salvata.
    Tutto qui.

  • Re: Test di effettiva connessione al database

    Tutto chiaro. Grazie.

Devi accedere o registrarti per scrivere nel forum
13 risposte