Disconnessione backend durante la sessione.

di il
11 risposte

Disconnessione backend durante la sessione.

Buonasera. Lavoro con un backend montato in una cartella condivisa con percorso UNC e mi capita a volte che la connessione si interrompe. Noto a questo punto che la connessione viene persa e il backend rimane aperto. Per potermi riconnettere devo cliccare sul backend e questo si avvia il processo di recupero del file che crea la copia di backup. Riavvio il frontend e la connessione si ripristina. È un problema noto? Quali indizi posso fornire per avere un suggerimento per arrivare alla risoluzione? Grazie.

11 Risposte

  • Re: Disconnessione backend durante la sessione.

    Ciao,

    penso che come prima cosa si debba eliminare il problema di comunicazione tra la cartella condivisa e il client e viceversa.

    Dato per scontato che provvederai a capire come mai non hai comunicazioni stabili, direi che puoi partire, facendo riferimento al supporto Microsoft, con due semplici funtion che vengono proposte e che puoi personalizzare:

    Lo scopo sarà quello di verificare se la connessione è persa e come ripristinarla.

    Questo evita di riavviare il FE ed assumere un qualche piccolo controllo ….

    Ma se la cartella Condivisa, per la quale non hai specificato dove si trova (su di un server e/o altro…), rimane disconnessa, oppure pur essendo connessa si perde la visibilità del BE, questo va analizzato e risolto sapendo e capendo come condividi le risorse di condivisione.

  • Re: Disconnessione backend durante la sessione.

    Grazie della risposta. Il database si trova in una cartella condivisa del server. Se la connessione viene persa, in questa circostanza come si puo comandare la riconnessione in automatico?

  • Re: Disconnessione backend durante la sessione.

    23/05/2023 - Antony73 ha scritto:


    Grazie della risposta. Il database si trova in una cartella condivisa del server. Se la connessione viene persa, in questa circostanza come si puo comandare la riconnessione in automatico?

    come detto sopra… basta testare una tabella qualsiasi presente nel BE e se ritorna Null allora si cerca di riavviare la connessione nel seguente modo:

    Queste due righe di codice che trovi sul supporto Microsoft le puoi tranquillamente personalizzare allo scopo, magari inserisci una gestione Errori con On Error ResumeNext  e ti fai ritornare dalla Function se la connessione è andata a buon fine oppure no. 

    Idem… puoi fare la stessa cosa intercettando con On Error ResumeNext personalizzando questa semplice funzione per farti ritornare se il test di connessione al BE è andato a buon fine oppure no:

    Se ritorna Errore, in quanto sul " Set Rst  = " si ha valore Null, allora mandi in automatico la riconnesione al BE. 

    Ma questo non risolve il problema di “instabilità connessioni” alle cartelle condivise tra Server e Client. 
    Ti permette solo di Verificare lo stato della connessione tra FE e BE e di ristabilire tale connessione. Ma se il client continua a non vedere il BE nella cartella condivisa, questo è un problema tra i due OS e configurazione delle condivisioni e va risolto a livello di OS.

    In tal caso ci sono diverse cose da verificare… ti faccio un esempio banale:

    Se il Client non è operativo e dopo un certo lasso di tempo va in sospensione e in tale stato viene disabilitata la scheda di rete e questo genera il problema di disconnessione tra il FE e BE… allora delle due una… o si impedisce la sospensione del Client oppure lo spengimento della scheda di rete.

  • Re: Disconnessione backend durante la sessione.

    Ok. Ottimo spunto. Grazie.

  • Re: Disconnessione backend durante la sessione.

    23/05/2023 - By65Franco ha scritto:


    Ciao,

    penso che come prima cosa si debba eliminare il problema di comunicazione tra la cartella condivisa e il client e viceversa.

    Dato per scontato che provvederai a capire come mai non hai comunicazioni stabili, direi che puoi partire, facendo riferimento al supporto Microsoft, con due semplici funtion che vengono proposte e che puoi personalizzare:

    Una considerazione sulla Funzione "TestaConnessione… che proverei a rendere più completa(anche se poi sarebbe da capire quale compito deve assolvere):

    Public Function TestaConnessione() As Boolean
        On Error GoTo Err_Handler
        Dim rs  As DAO.Recordset
        
        Set rs = DBEngine(0)(0).OpenRecordset("SELECT * FROM T_LIBRI1 WHERE 1=0", dbOpenSnapshot, dbReadOnly)
        TestaConnessione = True
    Exit_Here:
        On Error Resume Next
        If Not rs Is Nothing Then
            rs.Close
            Set rs = Nothing
        End If
        Err.Clear
        Exit Function
    Err_Handler:
        Resume Exit_Here
    End Function

    Spiegazioni:

    1. Aprire un RS pieno per testare la connessione significa trasferire dati inutilmente, meglio fare una chiamata che NON restituisce dati
    2. Aprire un RS in scrittura per testare la connessione non è una bella scelta, meglio ReadOnly
    3. Nonn gestire l'errore non consente di poter capire che succede, quella funzione non fa nulla di fatto, ma o si occupa di restituire TRUE/FALSE e basta, delegando a chi la chiama poi la diagnosi del da farsi o, con la gestione errori risolve o tenta di risolvere altrimenti…
    4. Se la connessione non si apre l'errore che ne consegue è doppio, di mancata connessione e successivamente di impossibiiltà di chiudere il tentativo di apertura dell'Oggetto RST… che non essendo aperto non può essere chiuso….

    Ci sono varie cose che si possono fare per ripristinare il Link, e questo a seconda del problema:

    • Provare a ripristinare il Link, se la Tabella è una Linked(ha la proprietà connect valorizzata):
    For Each tdfTableLink In dbCurr.TableDefs
       If Len(tdfTableLink.Connect)>0 then tdfTableLink.RefreshLink
    Next
    • Si prova a ripristinare la connessione
     For Each tdfTableLink In dbCurr.TableDefs
     	If Len(tdfTableLink.Connect)>0 then
       		tdfTableLink.Connect = ";DATABASE=" & (String connection e pwd se serve)
       		tdfTableLink.RefreshLink
       	end if
     Next
    • Se il problema è che il file di Bloccaggio è rimasto appeso, non si riuscirà a riconnettersi, quindi prima si prova a Cancellare il File di Bloccaggio poi si ripete il passaggio precedente

    Questo tema poi aprirebbe una serie di considerazioni da fare… le LINKED andrebbero avviate all'apertura e rimosse alla chiusura, ma l'elenco delle LINKED dove lo si mette…?

    Io lo lascio nel Server(BE) e non nel Client(FE) altrimenti serve aggiornarlo sempre… mentre io prima apro una connessione su apertura se il Login ha successo vado a Linkare altrimenti no, questo per migliorare la sicurezza… se così si può dire, in quanto il Server ha una PWD di accesso e la gestione Utenti è ovviamente separata…

    Vabbè ho scritto troppo…

  • Re: Disconnessione backend durante la sessione.

    24/05/2023 - @Alex ha scritto:


    Io lo lascio nel Server(BE) e non nel Client(FE) altrimenti serve aggiornarlo sempre… mentre io prima apro una connessione su apertura se il Login ha successo vado a Linkare altrimenti no, questo per migliorare la sicurezza… se così si può dire, in quanto il Server ha una PWD di accesso e la gestione Utenti è ovviamente separata…

    Vabbè ho scritto troppo…

    Ottimo !!!! 

    Ovvio che io ho solo dato uno spunto preso pari pari da uno dei supporti Microsoft.
    Poi come hai ben illustrato, sono le considerazioni e le tecniche che fanno la differenza. Veramente ottimo!!!

    Per esempio quando mi capita di dover verificare la connessione al Db uso Connection.State = adStateOpen e da qui decido cosa fare per riaprire la connessione oppure no, etc…

    Certo che se si parla di Link Tabelle altro discorso come hai ben illustrato. 

    Una domanda: per il file di Bloccaggio, come lo testi ? cioè come verifichi la sua esistenza e l'eliminazione quando serve? lo si tratta come un file qualsiasi?


    Grazie @Alex

  • Re: Disconnessione backend durante la sessione.

    Questo è uno dei motivi per cui Access non è adatto all'utilizzo in rete, usa un File in Sharing per gestire le connessioni… quindi potenzialmente in caso di MultiUtenza capace di bloccare tutto, in ogni caso provi a cancellarlo e gestisci l'errore, se è bloccato non si cancella, la chiamata a Kill restituisce errore, significa che qualcuno con connessione attiva è presente.

    Il Tuo FE che si è sconnesso in modo anomalo non bloccherà più il file SOLO DOPO la chiusura del FE inquanto il Blococ è legato al processo aperto, ed alla riapertura puoi ripristinare le Linked.

    Questo ovviamente richiede che sia una procedura ESTERNA al tuo FE a gestire il tentativo di ripristino, quindi serve avere un VBS o VB6 o un BAT esterno a cui delegare la chiusura del FE, il KILL eventuale del file di Bloccaggio, e la riapertura del FE….

    Si può verificare tramite ADO chi risulta Connesso:

    Sub ShowUserRosterMultipleUsers()
        Dim cn As New ADODB.Connection
        Dim rs As New ADODB.Recordset
    
        Set cn = CurrentProject.Connection
    
        ' The user roster is exposed as a provider-specific schema rowset
        ' in the Jet 4.0 OLE DB provider. You have to use a GUID to
        ' reference the schema, as provider-specific schemas are not
        ' listed in ADO's type library for schema rowsets
    
        Set rs = cn.OpenSchema(adSchemaProviderSpecific, _
        , "{947bb102-5d43-11d1-bdbf-00c04fb92675}")
    
        'Output the list of all users in the current database.
    
        Debug.Print rs.Fields(0).Name, "", rs.Fields(1).Name, _
        "", rs.Fields(2).Name, rs.Fields(3).Name
    
        While Not rs.EOF
            Debug.Print rs.Fields(0), rs.Fields(1), _
            rs.Fields(2), rs.Fields(3)
            rs.MoveNext
        WEnd
    
    End Sub

    Saluti

  • Re: Disconnessione backend durante la sessione.

    24/05/2023 - @Alex ha scritto:


    Questo è uno dei motivi per cui Access non è adatto all'utilizzo in rete, usa un File in Sharing per gestire le connessioni… quindi potenzialmente in caso di MultiUtenza capace di bloccare tutto, in ogni caso provi a cancellarlo e gestisci l'errore, se è bloccato non si cancella, la chiamata a Kill restituisce errore, significa che qualcuno con connessione attiva è presente.

    Molto chiaro!

    Grazie mille @Alex
    Super !!!!

  • Re: Disconnessione backend durante la sessione.

    Una curiosità. Nel caso di un backend presente in cartella condivisa su server, in che modo posso operare per consentire di fare lavorare un solo utente alla volta? Nel senso che se già un utente è connesso, in che modo posso impedire ad altri di accedere al backend? Flaggando l'opzione accesso esclusivo?

  • Re: Disconnessione backend durante la sessione.

    Si ma va considerato il Runtime o meno…!

    Onestamente eviterei, non si dovrebbe mai usare l'accesso esclusivo, eventualmente controlla la presenza del file di bloccaggio, se presente è già in uso, lo provi a cancellare se si cancella era rimasta appesa una connessione e ti connetti tu, altrimenti la connessione è in essere e passi… 

  • Re: Disconnessione backend durante la sessione.

    Ok. Buona idea. Grazie.

Devi accedere o registrarti per scrivere nel forum
11 risposte