Creare un’installazione professionale Access significa trasformare un semplice file .accdb in un’applicazione desktop distribuibile, versionata e aggiornabile. Non basta copiare il database sul Desktop: bisogna separare front-end e back-end, creare una build ACCDE, installare o verificare Access Runtime, gestire i percorsi, creare collegamenti, controllare prerequisiti e predisporre aggiornamenti e rollback.
Una buona installazione deve essere ripetibile. Due PC configurati con lo stesso pacchetto devono ottenere lo stesso risultato. L’utente non dovrebbe scegliere manualmente cartelle tecniche, driver ODBC o collegamenti al back-end senza necessità. In questa guida costruiamo un modello pratico per Access per Microsoft 365 e Access 2024 su Windows.
Indice
- Architettura dell’applicazione
- Preparare il front-end
- ACCDE
- Access Runtime
- 32/64 bit
- Cartelle locali
- Back-end
- Installer
- Shortcut
- Trusted Locations
- ODBC
- Versioni e update
- Rollback
- Disinstallazione
- Test e FAQ
Partire da un’architettura corretta
La base è un database diviso. Il back-end contiene i dati e rimane su server di rete o SQL Server; il front-end viene installato localmente su ogni PC. Questo separa il ciclo di vita dell’applicazione da quello dei dati.
Se ancora usi un unico file condiviso, consulta come dividere un database Access. Un installer professionale non dovrebbe distribuire un monolite che tutti aprono dalla stessa cartella di rete.
Definire cosa installare
Crea un inventario: front-end ACCDE, eventuali file di configurazione, icona, manuale PDF, template, DLL o controlli esterni, driver ODBC, Access Runtime, collegamenti e script di update. Distingui prerequisiti obbligatori da componenti opzionali.
Evita di includere file inutili del PC dello sviluppatore. Ogni dipendenza deve avere una ragione e una licenza di ridistribuzione compatibile.
Preparare il front-end
Prima del packaging compila VBA, elimina riferimenti mancanti, verifica collegamenti e testa maschere e report. Il front-end deve avere una maschera startup e non dipendere dal riquadro di spostamento per operazioni normali.
Inserisci un numero di versione visibile, per esempio 4.3.1. Registra anche una versione minima del back-end. Questo consente all’applicazione di bloccare l’avvio se lo schema dati non è compatibile.
Creare la build ACCDE
Per gli utenti finali è spesso preferibile un ACCDE. Microsoft indica che il formato compila il VBA, rimuove il sorgente modificabile e impedisce normali modifiche al design di moduli, maschere e report.
Conserva l’ACCDB sorgente in un archivio protetto. La guida come creare un file ACCDE descrive la preparazione e la compatibilità.
Decidere se installare Access Runtime
Se il PC non possiede Access completo, puoi distribuire Microsoft 365 Access Runtime. Microsoft lo rende disponibile gratuitamente in 32 e 64 bit. Runtime consente l’esecuzione ma limita funzioni di progettazione e navigazione.
Non installarlo alla cieca su qualsiasi Office esistente. Microsoft documenta regole di compatibilità tra Click-to-Run, versioni Office e architettura. In azienda usa Office Deployment Tool quando appropriato.
Inventariare Office prima dell’installazione
Un installer robusto dovrebbe rilevare se è presente Office/Access e la relativa architettura. Se trova una configurazione non supportata, deve fermarsi con un messaggio chiaro invece di installare componenti incompatibili.
Per distribuzioni gestite, questo controllo può essere effettuato dall’IT prima del rollout tramite inventory software.
32 o 64 bit
La build e i prerequisiti devono essere coerenti con l’architettura. Driver ODBC, controlli ActiveX e dichiarazioni API possono dipendere da 32/64 bit. Se l’organizzazione usa entrambe, crea pacchetti distinti e identifica chiaramente la build.
Se puoi standardizzare Office, riduci notevolmente il costo di supporto.
Scegliere la cartella del front-end
Il front-end deve essere locale e aggiornabile. Una cartella sotto il profilo utente è spesso pratica perché non richiede scrittura in Program Files. In ambienti enterprise puoi usare una directory applicativa gestita con permessi appropriati.
Non mettere dati condivisi o back-end nella stessa cartella. Se l’updater sostituisce il front-end, non deve cancellare configurazioni o file prodotti dall’utente.
Separare configurazione e binari
Una buona installazione distingue file applicativi sostituibili da impostazioni persistenti. Per esempio, salva preferenze locali in una tabella o file dedicato e non nel front-end che viene sovrascritto.
Se hai tabelle locali necessarie, pianifica una migrazione durante l’update oppure spostale in un database locale separato.
Collegamento al back-end
Il front-end deve conoscere il percorso del back-end. Puoi distribuire un percorso standard oppure eseguire un controllo al primo avvio. Se il back-end non è raggiungibile, mostra un errore comprensibile e non lasciare l’utente in una schermata tecnica.
Per interventi amministrativi usa Gestione tabelle collegate. Per utenti Runtime può servire una routine DAO di relink controllata.
Percorsi UNC e unità mappate
In molte aziende un percorso UNC uniforme è più prevedibile di una lettera mappata che può cambiare tra utenti. Testa la raggiungibilità con account standard e verifica i permessi della cartella.
Non incorporare percorsi personali dello sviluppatore nella build.
Scegliere lo strumento installer
Puoi usare MSI, MSIX, strumenti di packaging enterprise, script PowerShell firmati o soluzioni commerciali. La scelta dipende dall’infrastruttura e dalle policy. L’importante è che il processo sia ripetibile, loggato e in grado di aggiornare senza perdita dati.
Non esiste un unico installer Microsoft dedicato a tutte le app Access moderne. Runtime può essere distribuito con Office Deployment Tool, mentre il tuo front-end richiede un meccanismo di packaging scelto dal team.
Funzioni minime dell’installer
Un pacchetto professionale dovrebbe verificare prerequisiti, creare cartelle, copiare file, impostare permessi locali se necessari, creare collegamento, registrare versione installata e produrre un log. Se installa componenti, deve anche poterli rimuovere o aggiornare.
Non modificare impostazioni di sistema globali più del necessario.
Creare il collegamento
Il collegamento può puntare direttamente all’ACCDE. Se vuoi forzare la modalità Runtime su un PC con Access completo, puoi richiamare MSACCESS.EXE con il parametro /runtime, come documentato da Microsoft.
Evita percorsi hard-coded di Office senza rilevarli, perché posizione e architettura possono cambiare.
Icona e identità dell’app
Usa nome, icona e descrizione coerenti. Nell’interfaccia Access configura titolo applicazione e maschera iniziale. Un utente deve distinguere chiaramente produzione da ambiente test.
Se esiste una versione di collaudo, usa un nome visibile diverso per evitare inserimenti accidentali nel database sbagliato.
Trusted Locations
Se l’app contiene VBA, Access può mostrare avvisi di sicurezza. In ambienti gestiti puoi configurare una Trusted Location specifica tramite policy oppure usare firme digitali. Non rendere attendibile un’intera cartella generica come Download.
La scelta deve essere concordata con l’IT. Ridurre prompt non deve ridurre la sicurezza dell’intero Office.
Firma digitale
Firmare il codice o i pacchetti aiuta a verificare l’origine. La firma non cifra i dati e non sostituisce ACCDE. Proteggi la chiave privata di firma e definisci un processo di rinnovo del certificato.
ODBC e SQL Server
Se il front-end usa SQL Server, l’installer deve verificare o installare un driver ODBC Microsoft supportato. DSN e architettura devono corrispondere. In alternativa usa connessioni DSN-less se la tua strategia lo prevede.
Preferisci autenticazione Windows quando possibile e gestisci permessi sul server. Evita password condivise salvate in chiaro nel pacchetto.
Access Runtime e Office Deployment Tool
Per molti PC Microsoft raccomanda Office Deployment Tool per distribuire Access Runtime come parte della configurazione Office. L’IT può controllare lingua, architettura e canale di aggiornamento.
Il packaging dell’applicazione può essere separato: prima installi prerequisiti, poi il front-end.
Versione e manifest
Mantieni un piccolo file manifest o una tabella di configurazione con versione, hash del file, data rilascio e versione schema. L’updater confronta questi valori con quelli locali.
Non basarti soltanto sulla data del file: può cambiare durante copie e backup.
Auto-update
Una strategia comune: all’avvio il front-end legge la versione disponibile su una cartella server; se è maggiore, informa l’utente e avvia un updater esterno. Access si chiude, l’updater copia il nuovo ACCDE e poi riavvia.
Evita di copiare mentre il file è aperto. Se la copia fallisce, conserva la versione precedente.
Rollback
Ogni aggiornamento importante dovrebbe avere un piano di rollback. Conserva almeno la build precedente e assicurati che sia compatibile con lo schema del back-end. Se l’update include una migrazione irreversibile dei dati, il rollback richiede anche backup del back-end.
Prima di cambiare schema crea un backup verificato e pianifica una finestra di manutenzione.
Disinstallazione
La disinstallazione deve rimuovere front-end, shortcut e componenti locali dell’app, ma non cancellare il back-end condiviso. Distingui chiaramente dati utente da file applicativi.
Se esistono log locali che l’azienda deve conservare, chiedi al processo di backup o migrazione di gestirli prima della rimozione.
Log di installazione
Salva un log con versione installer, PC, esito dei prerequisiti, percorso installato ed eventuali errori. Questo accelera supporto remoto.
Non includere password o stringhe di connessione sensibili nei log.
Test su macchina pulita
Crea una VM o PC di test che non contenga strumenti dello sviluppatore. Installa il pacchetto esattamente come farebbe un utente e prova l’app con account standard.
Testa anche upgrade dalla versione precedente, non soltanto installazione pulita.
Test senza rete
Scollega la rete e avvia l’app. Deve mostrare un messaggio chiaro sul back-end non disponibile, senza bloccarsi per minuti. Ripristina la rete e verifica il recupero.
Test con permessi ridotti
Usa un account che non sia amministratore locale. Molti installer funzionano sul PC dello sviluppatore perché ha privilegi elevati, ma falliscono con utenti reali.
Test Runtime
Verifica che nessuna funzione richieda il riquadro di spostamento, la finestra Immediata o il menu completo. Tutte le operazioni devono essere raggiungibili dall’interfaccia.
Approfondisci con distribuire un’app Access con Runtime.
Sicurezza
Un installer non rende sicuro il back-end. Usa permessi Windows, backup, eventuale cifratura e SQL Server se servono autorizzazioni granulari. Runtime e ACCDE proteggono soprattutto l’esperienza e il codice del front-end.
Consulta proteggere il back-end Access condiviso.
Backup prima dell’upgrade
Se l’upgrade modifica soltanto il front-end, il rischio sui dati è minore. Se cambia schema o esegue query di aggiornamento, crea un backup prima della migrazione e verifica che nessuno stia usando il database.
Documentazione per l’utente
Fornisci una guida breve: come avviare, come uscire, cosa fare se la rete non è disponibile, come contattare supporto e dove leggere la versione. Evita manuali enormi per funzioni ovvie, ma documenta procedure critiche.
Documentazione per IT
IT deve conoscere prerequisiti, porte se SQL Server, percorsi, driver, architettura, cartelle attendibili, versione Runtime e procedura di rollback. Mantieni questo documento separato dal manuale utente.
Problemi comuni
Installer funziona solo come amministratore
Controlla dove scrive. Program Files e HKLM richiedono privilegi; una cartella profilo utente può evitare elevazione per il front-end. Se servono prerequisiti di sistema, usa elevazione controllata.
L’app non trova il back-end
Verifica percorso, VPN, DNS, permessi e collegamenti. Non chiedere all’utente di modificare manualmente TableDef senza una procedura.
Runtime e Office entrano in conflitto
Controlla tecnologia di installazione e architettura secondo la documentazione Microsoft. In azienda usa Office Deployment Tool.
Aggiornamento cancella impostazioni
Hai salvato configurazione nel front-end che viene sostituito. Separa dati persistenti dai binari.
Driver ODBC non trovato
Installa il driver corretto e verifica 32/64 bit. Standardizza la configurazione.
Checklist di rilascio
- Sorgente ACCDB archiviato.
- VBA compilato.
- ACCDE creato.
- Versione aggiornata.
- Front-end locale.
- Back-end verificato.
- Runtime/Access inventariato.
- Architettura definita.
- Driver inclusi o documentati.
- Trusted Location definita.
- Installer testato pulito.
- Upgrade testato.
- Rollback disponibile.
- Disinstallazione sicura.
- Log installazione.
- Documentazione IT.
FAQ
Serve un installer MSI?
Non necessariamente. In piccoli ambienti può bastare un updater/script controllato. In enterprise MSI/MSIX o strumenti di gestione offrono tracciabilità migliore.
Posso mettere il front-end in rete?
Meglio distribuirlo localmente a ciascun utente e lasciare in rete il back-end.
Runtime può essere ridistribuito?
Sì, Microsoft lo rende gratuito e lo prevede per la distribuzione delle applicazioni Access.
ACCDE è obbligatorio?
No, ma è raccomandabile per utenti finali quando vuoi proteggere VBA e design.
L’installer deve copiare il back-end?
Solo in una nuova installazione controllata. Negli aggiornamenti normali non deve sovrascrivere dati condivisi.
Posso aggiornare mentre Access è aperto?
Non il file front-end in uso. Fai chiudere Access e usa un updater esterno.
Conclusione
Creare un’installazione professionale Access significa progettare l’intero ciclo di vita: prerequisiti, build, installazione, aggiornamento, rollback e supporto. ACCDE e Runtime sono soltanto due componenti di questo processo.
Con front-end locale, back-end protetto e updater controllato, un’app Access può essere distribuita in modo ordinato anche su molte postazioni. Per altre guide visita Guide Access.
Fonti Microsoft: Deploy an Access application; Microsoft 365 Access Runtime.