[VBA/ACCESS] Tabelle collegate in rete e utilizzate da più utenti molto lente

[8matt5]

Ciao a tutti.

Ho sviluppato un applicazione tramite Access che lavora su dati in formato mdb.

Questa applicazione deve essere utilizzata su più pc che lavorano sugli stessi dati.
Ho piazzato i files mdb contenenti i dati in una cartella condivisa su un pc e su tutti i pc ho installato la mia applicazione Access.

All'avvio, ogni applicazione sa dove cercare i files mdb ed esegue una routine per connettere le tabelle collegate. La parte della routine che effettivamente connette le tabelle e questa:

Set fileRS = CurrentDb.OpenRecordset("SELECT * FROM _file_dati")

Do While Not fileRS.EOF
       
    strConn = ";DATABASE=" & path & fileRS("filename")
        
    Set tblRS = CurrentDb.OpenRecordset("SELECT * FROM _tbl_collegate WHERE file_dati = " & fileRS("ID_file"))
        
    Do While Not tblRS.EOF

        nomeTabella = tblRS("nomeTabella")

        CurrentDb.TableDefs.Delete nomeTabella
        If Err.Number = 3265 Then
            Err.Clear
        ElseIf Err.Number > 0 Then
            MsgBox "Errore " & Err.Number & ": " & Err.Description & vbCrLf & "Tabella: " & nomeTabella, vbCritical
        End If
        
        Set newTable = CurrentDb.CreateTableDef(nomeTabella)
        newTable.Connect = strConn
        newTable.SourceTableName = nomeTabella
        CurrentDb.TableDefs.Append newTable
        
        If Err.Number > 0 Then
            MsgBox "Errore " & Err.Number & ": " & Err.Description & vbCrLf & "Tabella: " & nomeTabella, vbCritical
            'Stop
            Err.Clear
        End If
        
        Set newTable = Nothing
        
        If Not masch Is Nothing Then    ' masch è una maschera che carico prima di cominciare questo ciclo ed ha una progressBar al suo interno
            masch.aumenta perc          ' aumenta la progressBar della maschera di caricamento (perc viene calcolato prima in base al num di tabelle)
        End If
    
    tblRS.MoveNext
    Loop
fileRS.MoveNext
Loop

Se avvio il programma dal computer su cui sono presenti i dati, tutto viene svolto molto velocemente. Ho appena il tempo di vedere la maschera di caricamento la cui progressBar si riempie in meno di un secondo.

Se avvio il programma da un pc diverso, l'operazione è più lenta, ma impiega in tutto un paio di secondi. Accettabile.

Se avvio il programma sempre da un pc diverso, ma lo faccio mentre anche un altro pc sta eseguendo il programma, questo processo impiega più di un secondo a tabella, impiegando in totale ben più di un minuto, avendo al momento 67 tabelle da caricare (ma in futuro potrebbero aumentare).

So che può sembrare inutile ricollegare le tabelle ad ogni avvio, ma sviluppandolo in una sede diversa e utilizzandolo su più pc, i percorsi delle cartelle sono sempre diversi e ricollegando ho la certezza di avere il percorso giusto.

Inoltre anche durante l'utilizzo, l'apertura delle maschere e dei reports è notevolmente rallentata durante l'utilizzo simultaneo da più postazioni.

è normale che sia così lento o ci può essere qualche cosa che non va nella mia rete o nei miei pc??

[gibra]

Originariamente inviato da 8matt5
So che può sembrare inutile ricollegare le tabelle ad ogni avvio,

Più che strano, direi che è da folli!

Originariamente inviato da 8matt5
ma sviluppandolo in una sede diversa e utilizzandolo su più pc, i percorsi delle cartelle sono sempre diversi e ricollegando ho la certezza di avere il percorso giusto.

Mmmm, secondo me questo discorso non ha alcun senso, né pratico, né logico.
Cosa significa questa tua espressione?
i percorsi delle cartelle sono sempre diversi

Se la connessione al db ha successo, il percorso è giusto, altrimenti non lo è.

Quello che proprio non capisco è: che senso ha ricollegare le tabelle?
Forse non hai dato qualche informazione importante...

Scusa, tu hai il database MDB sul server in una cartella condivisa, giusto?
Collegati a quello e fine della storia.
Non riesco a capire perchè ti complichi la vita inutilmente?
O forse intendi dire che hai una copia del database su ogni signolo pc?

Per me non è né nella rete, né nei pc che devi trovare le casue.
La causa, a mio modesto avviso, risiede in questa strana e bislacca procedura che crea un super lavoro pauroso!
Avrebbe un senso se le tabelle fossero linkate da un db esterno (SQL Server, Oracle, ...), ma anche in questo caso le devi ricollegare solamente una volta, ovvero quando si connette il primo utente.
Rifarlo per ogni utente non ha alcun senso, se non quello di crearti il problema che stai avendo.

Alla chiusura, quando l'ultimo si disconnette, compatti il database.

[8matt5]

Quando dico i percorsi delle cartelle sono sempre diversi intendo dire che rispetto ad ogni copia del database front-end (quello che contiene maschere, reports, etc e ce ne è uno in ogni pc) il percorso relativo del database contenente le tabelle (che quello invece è unico per tutti) è diverso.
Ad es.
- Dove lo sviluppo i files sono in D:/Documenti/Cartella/dati.mdb
- Nel pc1 che fa da server sono in D:/gestione/dati.mdb
- Negli altri pc client invece sono in V:/dati.mdb

Se prendo il front-end ultima versione che ho appena finito di sviluppare, lo porto nel pc1 e lo faccio partire, i percorsi delle tabelle collegate sono sbagliati, quindi devo ricollegarle.

Utilizzare l'utility di access è scomodo ed inoltre è macchinoso per uno che non sa usare access.
Farlo in automatico mi permette di distribuire l'applicazione e i suoi aggiornamenti senza il mio ausilio nell'installazione.

[gibra]

Originariamente inviato da 8matt5
Quando dico i percorsi delle cartelle sono sempre diversi intendo dire che rispetto ad ogni copia del database front-end (quello che contiene maschere, reports, etc e ce ne è uno in ogni pc) il percorso relativo del database contenente le tabelle (che quello invece è unico per tutti) è diverso.
Ad es.
- Dove lo sviluppo i files sono in D:/Documenti/Cartella/dati.mdb
- Nel pc1 che fa da server sono in D:/gestione/dati.mdb
- Negli altri pc client invece sono in V:/dati.mdb

Perchè invece non fai che i pc Client accedano tutti sullo stesso percorso sul server?
Ovvero su: D:/gestione/dati.mdb.
Se tu, giustamente, vuoi mantenere lo sviluppo nel tuo pc in locale, è corretto.
Però puoi fare in modo che quando il programma viene eseguito dal tuo pc, vada a leggere il database in locale, oppure opzionalmente quello sul server, non c'è limite a questo.
Mentre se viene eseguito da un pc CLIENT, andrà a leggere il database sul server.

Originariamente inviato da 8matt5
Se prendo il front-end ultima versione che ho appena finito di sviluppare, lo porto nel pc1 e lo faccio partire, i percorsi delle tabelle collegate sono sbagliati, quindi devo ricollegarle.

Vuoi dire che tu imposti il percorso del database DATI.MDB all'interno del programma?
Se è così, allora è ovvio che ti crea questo problema.
Il percorso dovresti scriverlo in un file di configurazione, e dovrà 'puntare' sempre alla stessa posizione del database che sta sul server: D:/gestione/dati.mdb .
In questo modo avviene che il programma, all'avvio, legge il percorso dal file di configurazione, e si connette al database sul server.

Originariamente inviato da 8matt5
Utilizzare l'utility di access è scomodo ed inoltre è macchinoso per uno che non sa usare access.
Farlo in automatico mi permette di distribuire l'applicazione e i suoi aggiornamenti senza il mio ausilio nell'installazione.

Non so di quale utility parli...

Riguardo invece all'installazione non riesco ad afferrare dove sta il problema.
Hai già scritto che l'applicativo gira so ogni pc client, quindi i componenti necessari sono già installati, per cui cosa c'è da installare? Niente. Devi solo aggiornare il programma ed eventualmente il database.

Considera che potresti compilare il programma, che diventa un eseguibile, e lo metti sul server, nella stessa cartella dove risiede il database, in tal modo basta creare un semplice collegamento dal CLIENT all'eseguibile sul SERVER.

[8matt5]

Forse non ci stiamo capendo...

Originariamente inviato da gibra
Perchè invece non fai che i pc Client accedano tutti sullo stesso percorso sul server?
Ovvero su: D:/gestione/dati.mdb.

Ovviamente il file è lo stesso ma il percorso è diverso per ogni macchina: "V:" è un unità di rete che punta alla cartella D:/gestione sul pc server.
Solamente dove lo sviluppo utilizzo file diversi essendo in un'altra sede e dovendo cmq fare delle prove sui dati che andrebbero a corrompere i dati originali. Utilizzo quindi dati fittizzi.

Originariamente inviato da gibra
Riguardo invece all'installazione non riesco ad afferrare dove sta il problema.
Hai già scritto che l'applicativo gira so ogni pc client, quindi i componenti necessari sono già installati, per cui cosa c'è da installare? Niente. Devi solo aggiornare il programma ed eventualmente il database.

Scusami se ho usato installare come parola, intendevo semplicemente quell'operazione che prende l'mdb front-end più aggiornato e lo va a posizionare al posto di quello più vecchio o su un nuovo pc.

Detto questo non so tu cosa intendi quando dici connette al database sul server. In ms access (per quel che ne so io, se ci sono altre possibilità non vedo l'ora di impararle) ogni TableDef è o una tabella memorizzata direttamente sul db oppure un collegamento una tabella memorizzata su un altro db. Ogni TableDef collegata ha una sua stringa di connessione al db e nome della tabella remota. La mia funzione quindi va ad aggiornare i collegamenti di tutte le TableDefs collegate.

L'mdb front-end è uguale per tutti (ma non lo stesso, ognuno ha la sua copia) e i percorsi (assieme alle varie impostazioni locali del programma che sono valide solo per quel pc) sono salvati su un file esterno che sta sempre nella stessa cartella di questo mdb.

Originariamente inviato da gibra
Non so di quale utility parli...

Per utility intendo quella che trovi fino alla ver 2003 in Strumenti -> Utilità Database -> Gestione Tabelle Collegate; o nella ver 2007 nella scheda Strumenti Database -> Gestione Tabelle Collegate; o in entrambi cliccando col destro su una tabella collegata e selezionando Gestione Tabelle Collegate.

Originariamente inviato da gibra
Considera che potresti compilare il programma, che diventa un eseguibile, e lo metti sul server, nella stessa cartella dove risiede il database, in tal modo basta creare un semplice collegamento dal CLIENT all'eseguibile sul SERVER.

Quanto a compilare il programma l'unica cosa che ho potuto fare è creare l'mde. Inoltre compilare un unico eseguibile ed utilizzare sempre lo stesso in più sessioni su macchine diverse mi sembra veramente una pessima idea, o forse non ho capito cosa intendi...
Rimerrebbe cmq il problema dato che i percorsi vengono calcolati sulla macchina che fa andare il programma e non su quella che lo ospita.

[DragonOfLight]

Originariamente inviato da 8matt5
Ovviamente il file è lo stesso ma il percorso è diverso per ogni macchina: "V:" è un unità di rete che punta alla cartella D:/gestione sul pc server.
Solamente dove lo sviluppo utilizzo file diversi essendo in un'altra sede e dovendo cmq fare delle prove sui dati che andrebbero a corrompere i dati originali. Utilizzo quindi dati fittizzi.

Per evitare il problema puoi mappare su ogni PC l'unità di rete V:
- nel tuo pc punterà alla tua cartella locale con il database per le prove
- sui client punteranno alla cartella condivisa del server ove è contenuto il database
- sul server punterà alla cartella condivisa su se stesso.

In questo modo non hai la necessità di cambiare i collegamenti ogni volta.

In alternativa, se non è possibile fare questo (magari sul server o sul tuo pc l'unità V è già utilizzata per altro) puoi fare così:

1. recuperi il nome del pc
2. recuperi il percorso a cui è collegata una tabella chiave del database
3. in base al nome del pc recuperi il percorso:
4. se il percorso è differente ==> Lanci procedura di allineamento percorsi



Il problema inerente il rallentamento quando è già aperto un altro applicativo si manifesta quando entrambi gli applicativi effettuano la procedura di allineamento o anche quando è solo 1 dei due ad effettuarla?

Mentre l'applicativo effettua la riconnessione delle tabelle l'altro già aperto soffre di rallentamenti o va con le solite tempistiche?

[8matt5]

Mi dispiace scartare la tua proposta, ma far si che tutti abbiano lo stesso percorso per aggirare il problema mi mette un limite che non voglio avere, mi costringe a fare le cose in un modo che non voglio, se ci arriverò sarà proprio perchè è l'ultima spiaggia, ma non lo farò perchè ho già in mente una soluzione alternativa per ridurre al minimo la procedura di collegamento tabelle.

Il problema che è nato in realtà esula da questo, non sto cercando un modo per bypassare questo procedimento, ma sto cercando di capire come mai è così lento...

Originariamente inviato da DragonOfLight
Il problema inerente il rallentamento quando è già aperto un altro applicativo si manifesta quando entrambi gli applicativi effettuano la procedura di allineamento o anche quando è solo 1 dei due ad effettuarla?

Il rallentamento si verifica quando un qualsiasi applicativo ha una maschera aperta che lavora su quei dati, non necessariamente quando entrambi si ricollegano.

Ti spiego: in realtà non ho un solo file dati, ne ho 4! Li ho divisi in base ai loro ambiti perchè avevo bisogno di 4 piccoli files piuttosto che di 1 enorme, dato che devo spesso caricarli su un server remoto, la connessione in upstream è piuttosto lenta e il più delle volte mi basta caricare solo un certo tipo di dati, quindi solo 1 file.
Comunque....
L'applicazione ricollega le tabelle raggruppandole per file, inoltre vicino alla mia barra di caricamento, vedo anche cosa sta caricando.
Succede quindi che noto che se sul pc di fianco al mio ho aperta una maschera che lavora su dati presenti nel file1, mentre sul mio carica le tabelle del file1 va a rilento, ma, appena ha finito, gli altri 3 files vanno a scheggia.
Se per assurdo l'applicazione è aperta sulla schermata iniziale (che non è collegata a nessun tipo di dato), se la apro da un'altra parte il processo di ricollegamento è veloce come se nessuno fosse collegato.

Originariamente inviato da DragonOfLight
Mentre l'applicativo effettua la riconnessione delle tabelle l'altro già aperto soffre di rallentamenti o va con le solite tempistiche?

Mi è sembrato di avere l'impressione che il primo a connettersi abbia un po' la precedenza rispetto agli altri, nel senso che non subisce particolari rallentamenti...
Anche perchè in realtà io ho parlato della routine di collegamento (perchè è la più palese), ma tutto il programma è più lento se utilizzato in simultanea con altri pc.

[gibra]

Originariamente inviato da 8matt5
Forse non ci stiamo capendo...
Ovviamente il file è lo stesso ma il percorso è diverso per ogni macchina: "V:" è un unità di rete che punta alla cartella D:/gestione sul pc server.

Scusa, evidentemente non ci capiamo...
Ma se il percorso è quello sul server (ma mappato sul Client come V, dove sta il problema.

Originariamente inviato da 8matt5
Quanto a compilare il programma l'unica cosa che ho potuto fare è creare l'mde. Inoltre compilare un unico eseguibile ed utilizzare sempre lo stesso in più sessioni su macchine diverse mi sembra veramente una pessima idea,

Non so su quali basi la definisci pessima, io invece consider pessima la tua.
Non hai nessun vantaggio dall'eseguire il front-end in locale, anziché sul server.
Per contro, ogni aggiornamento devi farlo ogni volta su tutti i computer.
Mi sembra tutto fuorchè un'ottima idea.
Poi sei libero di fare come credi.

Originariamente inviato da 8matt5
o forse non ho capito cosa intendi...

può essere.

Originariamente inviato da 8matt5
ogni TableDef è o una tabella memorizzata direttamente sul db

Io non ti capisco proprio: cosa c'entra la struttura del db con il problema di percorsi?

Originariamente inviato da 8matt5
Rimerrebbe cmq il problema dato che i percorsi vengono calcolati sulla macchina che fa andare il programma e non su quella che lo ospita.

Non è vero. Il problema c'è perchè sei tu che te lo sei creato, impostando il programma in questo modo.
L'hai letta la parte dove spiego del file di configurazione?
Se sì, cosa non ti è chiaro?

Ti espongo lo scenario di una mia applicazione installata presso un mio cliente:
- front-end scritto in VB6, compilato (EXE)
- database MDB
- rete LAN di 15 utenti
- il programma ed il database sono sul SERVER, in una cartella condivisa
- in ogni client ho solo installato solo i componenti necessari al programma
- in ogni client c'è un link che punta al programma sul server
- ogni client esegue il programma dal server.
- se devo fare modifiche o aggiornamenti, mi basta aggiornare solo sul SERVER.

Capita che ogni tanto vado dal cliente per fare assistenza.
Sul mio portatile, ho impostato il programma sorgente che all'avvio mi apre (solo a me) una finestra da cui posso scegliere se collegarmi:
A - al MIO database locale (è un programma che uso anch'io)
B - al database del cliente sul server
C - ad una copia di prova del database con dati stupidi (sempre in locale)

Per dimostrarti che tutto si può fare, è solo questione di impostare il programma a fargli fare quello che vuoi tu.

[8matt5]

Come fai partendo da un mdb a compilare un exe?

Ti ricordo che non ho un programma compilato stand-alone, ma un database mdb con le sue maschere, i suoi report, le sue query, i suoi moduli, le sue macro e ... le sue tabelle collegate!!

Quindi la struttura del database centra eccome...

[8matt5]

Inoltre ho anche tabelle vere e proprie all'interno del programma con dati veri (non collegate) e andare a lavorare sullo stesso file, sulle stesse tabelle, ecc, per di più attraverso una connessione di rete creerebbe un carico di lavoro enorme ed inutile al povero PC che fa da Server e un calo di prestazioni significativo che è proprio il problema che ho esposto in questo post e che voglio risolvere...

Resta cmq il fatto che di norma soluzioni del genere non vengono utilizzate; i software gestionali in generale consistono in diverse installazioni Client, che lavorano tutte sugli stessi dati su un Server.

Se poi il tuo software funziona bene così e sei contento mi fa piacere, non ti vengo a dire di cambiare sistema, ci mancherebbe....
Ma per il mio ho voluto un approccio diverso, più standard...

Resta comunque la differenza maggiore: il mio non è un software compilato (.exe), è un database mdb con una GUI ed una struttura dati interna realizzata tramite access. So che non è il massimo, sto cercando infatti di sviluppare lo stesso software parallelamente per liberarmi di Access, ma al momento è quello che ho...