Creare ACCDE Access significa trasformare una copia del database applicativo in un file compilato destinato alla distribuzione. Nel formato .accde il codice VBA viene compilato e il sorgente modificabile viene rimosso; inoltre gli utenti non possono modificare il design di moduli, maschere e report come farebbero in un normale .accdb. Microsoft consiglia questo formato quando vuoi impedire modifiche al design dell’applicazione e nascondere il codice VBA agli utenti finali.
La regola fondamentale è conservare sempre il file .accdb sorgente. L’ACCDE non è il progetto da modificare: è l’artefatto di rilascio. Ogni nuova versione deve essere sviluppata nell’ACCDB, compilata, testata e poi nuovamente salvata come ACCDE. In questa guida vediamo la procedura completa per Access per Microsoft 365 e Access 2024, con particolare attenzione a riferimenti VBA, architettura 32/64 bit, database divisi e Access Runtime.
Indice
- Cos’è un file ACCDE
- Cosa cambia rispetto ad ACCDB
- Quando conviene usarlo
- Preparare il database
- Compilare VBA
- Correggere riferimenti mancanti
- Creare ACCDE passo passo
- 32/64 bit
- Database diviso
- Runtime
- Aggiornamenti
- Errori comuni
- Sicurezza
- FAQ
Cos’è ACCDE
ACCDE è il formato binario compilato di Access per i database nel formato moderno. Microsoft lo descrive come un file in cui tutto il codice VBA è compilato e il sorgente modificabile non rimane. L’applicazione continua a eseguire macro, query, maschere, report e funzioni VBA compilate, ma l’utente non può entrare nell’editor e modificare quel codice.
Questo lo rende ideale per un front-end distribuito. L’utente può lavorare con i dati e usare l’interfaccia, mentre lo sviluppatore mantiene il sorgente in un archivio separato. ACCDE riduce anche la possibilità di modifiche accidentali agli oggetti di design.
ACCDE non è una copia di backup
Non usare l’ACCDE come unica copia del progetto. Una volta rimosso il sorgente VBA non puoi ricostruire comodamente il codice originale dal file distribuito. Conserva ACCDB, documentazione, eventuali moduli esportati e una copia versionata in un sistema di backup o controllo versione.
La sequenza corretta è: sviluppo su ACCDB, test, compilazione, backup del sorgente, creazione ACCDE, test dell’ACCDE e distribuzione.
Quando conviene usare ACCDE
ACCDE è consigliabile quando distribuisci un’applicazione a utenti che non devono modificare maschere, report o codice. È particolarmente utile insieme ad Access Runtime, perché crea una separazione chiara tra ambiente di sviluppo e ambiente di esecuzione.
Puoi usarlo anche con utenti che hanno Access completo. Il fatto che abbiano l’applicazione completa installata non rende modificabile il sorgente VBA dell’ACCDE.
Quando non usarlo durante lo sviluppo
Durante sviluppo e debug lavora su ACCDB. Devi poter aprire editor VBA, modificare maschere, aggiungere controlli e cambiare report. Generare un ACCDE dopo ogni piccola modifica rende il ciclo inefficiente.
Tratta ACCDE come una build di produzione. Se devi correggere un bug, apri l’ACCDB corrispondente a quella versione, modifica, ricompila, aggiorna versione e crea un nuovo ACCDE.
Prerequisito: un database pulito
Prima di creare ACCDE, il database deve compilare senza errori. Un riferimento mancante, una dichiarazione API incompatibile o un modulo con errore impediscono la creazione. Perciò la fase di preparazione è più importante del click finale.
Lavora su una copia del front-end e fai un backup. Se il database è multiutente, non creare l’ACCDE sul file condiviso mentre gli utenti lavorano. Il front-end master deve essere un file di sviluppo separato.
Dividere front-end e back-end
ACCDE è particolarmente adatto al front-end, non al back-end che contiene le tabelle. In una soluzione multiutente crea un back-end .accdb condiviso e un front-end .accdb con tabelle collegate. Poi compila il front-end in .accde.
Se il database non è ancora diviso, consulta come dividere un database Access in front-end e back-end. Il back-end resta aggiornabile dagli utenti tramite le tabelle collegate, mentre il front-end ACCDE protegge design e codice.
Compilare il progetto VBA
Apri l’ACCDB con Access completo, premi Alt+F11 per aprire l’editor VBA e usa il menu Debug per compilare il progetto. Se il comando Compila è disponibile, eseguilo. Access si ferma al primo errore di compilazione.
Correggi tutti gli errori: variabili non dichiarate, procedure mancanti, riferimenti, costanti errate e dichiarazioni API. Ripeti finché il comando di compilazione non segnala più problemi.
Usare Option Explicit
Inserire Option Explicit nei moduli aiuta a intercettare errori di battitura nelle variabili. Nelle opzioni VBA puoi richiedere la dichiarazione obbligatoria delle variabili per i nuovi moduli. È una buona pratica perché un ACCDE deve essere il risultato di codice già verificato.
Controllare i riferimenti VBA
Nell’editor VBA apri Strumenti e Riferimenti. Se compare una voce MISSING o Mancante, risolvila prima di creare ACCDE. Un riferimento mancante può bloccare la compilazione e, anche quando l’applicazione sembra funzionare su un PC, può fallire su un altro.
Riduci i riferimenti non necessari. Se usi automazione verso Excel o Outlook, valuta late binding per diminuire dipendenze da versioni specifiche, quando appropriato. Non rimuovere librerie necessarie senza test.
32 bit e 64 bit
Un punto critico è l’architettura di Access. Microsoft documenta restrizioni quando si crea e distribuisce ACCDE tra ambienti 32 e 64 bit, soprattutto se il progetto contiene chiamate API o componenti specifici. In pratica devi creare e testare l’ACCDE nella stessa architettura che supporti in produzione.
Se l’app deve funzionare sia su Access 32 bit sia 64 bit, testa attentamente. Le dichiarazioni API devono usare PtrSafe e tipi corretti sotto VBA7. Alcuni controlli ActiveX a 32 bit non esistono in 64 bit.
Standardizzare conviene
Se puoi, scegli un’architettura Office aziendale unica. Riduce il numero di build, semplifica driver ODBC e rende più semplice il supporto. Se devi mantenere due ambienti, conserva build distinte con nomi e versioni chiare.
Verificare dipendenze esterne
Prima della build inventaria DLL, ActiveX, driver ODBC, file di configurazione, template Word, cartelle, stampanti e librerie esterne. ACCDE compila il VBA ma non incorpora automaticamente ogni dipendenza del sistema.
Se un controllo ActiveX è registrato sul PC dello sviluppatore ma non sui client, l’ACCDE può aprirsi con errori. Testa sempre su una macchina pulita.
Compattare il front-end
Prima della build può essere utile eseguire Compatta e ripristina sulla copia di sviluppo dopo aver creato un backup. Questo elimina spazio inutilizzato e può rendere il file più pulito. Non farlo mentre altri utenti accedono allo stesso file.
Chiudi e riapri il database dopo la compattazione, ricompila VBA e fai un rapido test delle funzioni principali.
Procedura per creare ACCDE
Con il database sorgente aperto in Access, vai su File, quindi nella sezione dedicata al salvataggio/pubblicazione del database e scegli l’opzione per creare un file ACCDE. Il nome esatto dei comandi può variare leggermente tra versioni e lingua, ma Microsoft documenta la funzione come Make ACCDE.
Scegli una cartella di build separata dal sorgente. Assegna un nome con versione, per esempio Gestionale_3_4.accde. Non sovrascrivere l’ACCDB.
Se Access non crea il file
Il motivo più comune è un problema di compilazione o compatibilità. Torna nell’editor VBA e compila. Controlla riferimenti, moduli e API. Verifica anche che il percorso di destinazione sia scrivibile e che il database non abbia condizioni che impediscono la conversione.
Testare l’ACCDE
Non distribuire immediatamente. Apri l’ACCDE e prova ogni percorso critico: startup, login, maschere, filtri, salvataggio, cancellazione controllata, report, PDF, import/export, email, collegamenti ODBC e chiusura.
Testa con un account standard e, se gli utenti useranno Runtime, esegui anche la modalità Runtime. Il comportamento può differire dall’ambiente completo dello sviluppatore.
ACCDE e Access Runtime
Microsoft conferma che Access Runtime può aprire file ACCDE. È una combinazione comune per distribuire app a utenti senza Access completo. Runtime limita funzioni dell’interfaccia; ACCDE protegge il sorgente e il design.
Consulta come distribuire un’app Access con Runtime per configurazione, 32/64 bit e Office Deployment Tool.
ACCDE non è crittografia
Il formato impedisce la modifica del sorgente VBA ma non cifra automaticamente i dati del back-end. Se un utente ha accesso al file dati può potenzialmente aprirlo direttamente. Proteggi il back-end con permessi Windows e, se appropriato, crittografia con password o un database server.
Approfondisci con come proteggere il back-end Access condiviso.
Nascondere oggetti e riquadro
Puoi configurare opzioni di startup, maschera iniziale e riquadro di spostamento per migliorare l’esperienza. Questi controlli sono utili, ma non sostituiscono ACCDE né i permessi.
In Runtime il riquadro non è disponibile per impostazione predefinita, ma Microsoft precisa che Runtime non è una misura di sicurezza primaria.
Versionare l’ACCDE
Inserisci una costante o tabella locale con la versione front-end. Mostrala in una schermata Informazioni. Quando un utente segnala un errore, sapere che usa la versione 3.4 anziché 3.2 cambia completamente la diagnosi.
Conserva un archivio delle build rilasciate, ma non infinite copie confuse. Associa ogni ACCDE al commit o backup del relativo ACCDB sorgente.
Aggiornare gli utenti
Un ACCDE aperto non può essere semplicemente sovrascritto. Progetta un updater esterno: il front-end verifica se esiste una versione più recente, avvisa, chiude Access e un piccolo script o programma copia il nuovo file.
Ogni utente deve avere una copia locale. Aggiornare un solo ACCDE condiviso sulla rete mentre tutti lo eseguono è un modello fragile.
Collegamenti al back-end
Prima della build verifica che i link puntino alla produzione corretta. Se hai ambienti test e produzione, non distribuire per errore un ACCDE collegato al database di test.
Puoi includere una routine che controlla la connessione all’avvio e, se necessario, ricollega usando DAO. Evita di chiedere all’utente Runtime di gestire manualmente tabelle collegate.
ACCDE e SQL Server
Se il front-end usa tabelle ODBC, l’ACCDE conserva la logica ma i client devono avere driver e configurazione corretti. Verifica DSN, autenticazione e architettura. La compilazione non incorpora il driver ODBC.
Per credenziali sensibili preferisci autenticazione server-side e Windows quando possibile, invece di password hard-coded nel VBA.
Firmare il codice
La firma digitale e ACCDE risolvono problemi diversi. ACCDE rimuove il sorgente modificabile; la firma aiuta a stabilire origine e integrità. In ambienti aziendali puoi combinare firma, Trusted Locations e distribuzione controllata.
Errore: impossibile creare ACCDE
Procedi in ordine: crea una copia, compila VBA, controlla riferimenti, verifica moduli e API, esegui Compatta e ripristina, riapri e riprova. Se il problema persiste, crea un nuovo database vuoto e importa gli oggetti per capire se esiste una corruzione o un oggetto problematico.
Non lavorare direttamente sull’unica copia del sorgente.
Errore su un altro PC
Se l’ACCDE funziona sul PC dello sviluppatore ma non sul client, confronta versione Access, 32/64 bit, riferimenti, driver ODBC, ActiveX, font, stampanti e percorsi. Un ACCDE non rende portabili dipendenze non installate.
Errore dopo aggiornamento Office
Un aggiornamento può esporre dipendenze obsolete o incompatibilità. Testa gli aggiornamenti su un gruppo pilota quando l’applicazione è critica. Mantieni il sorgente per poter ricreare la build con la versione supportata.
Proteggere il sorgente ACCDB
Il file di sviluppo deve essere conservato in una posizione accessibile soltanto agli sviluppatori. Non distribuire ACCDB e ACCDE insieme agli utenti: vanificheresti parte dello scopo.
Usa backup versionati e, se possibile, esporta moduli e oggetti importanti in un sistema di versionamento adatto al team.
Access 2024 e Microsoft 365
Microsoft documenta ACCDE per le versioni desktop moderne, compresi Access per Microsoft 365 e Access 2024. Le schermate possono differire con gli aggiornamenti, ma il principio non cambia.
Evita di creare la build finale su una versione più recente se devi supportare client molto più vecchi senza test. Definisci una matrice di compatibilità aziendale.
ACCDE e dati locali
Un front-end può contenere tabelle locali per configurazione, cache e log. Gli utenti possono aggiornare i dati in queste tabelle anche se il file è ACCDE, perché ACCDE limita il design e il codice, non rende il database interamente di sola lettura.
Se vuoi che la configurazione sia preservata tra aggiornamenti, non sovrascrivere senza strategia le tabelle locali. Salvale in un file separato o migra i valori nella nuova versione.
Checklist prima della build
- Backup del sorgente ACCDB.
- Database diviso.
- Collegamenti corretti.
- Compilazione VBA senza errori.
- Nessun riferimento MISSING.
- API compatibili 32/64 bit.
- Dipendenze documentate.
- Versione front-end aggiornata.
- Test in Access completo.
- Compatta e ripristina se appropriato.
- Creazione ACCDE in cartella build.
- Test ACCDE.
- Test Runtime.
- Test su PC pulito.
- Archivio della build.
FAQ
Posso tornare da ACCDE ad ACCDB?
Non devi considerarlo un percorso di sviluppo. Conserva sempre l’ACCDB sorgente originale.
ACCDE nasconde il VBA?
Sì, Microsoft indica che il sorgente VBA modificabile viene rimosso dal file compilato.
Gli utenti possono modificare i dati?
Sì, se l’applicazione e i permessi lo consentono. ACCDE non rende i dati automaticamente di sola lettura.
ACCDE funziona con Runtime?
Sì. È una delle combinazioni più usate per distribuzione.
Devo creare un ACCDE diverso per 32 e 64 bit?
Se supporti entrambe le architetture, devi testare e spesso mantenere build compatibili con ciascun ambiente, soprattutto con API e componenti specifici.
ACCDE protegge il back-end?
No. Protegge il front-end. Usa permessi, cifratura o SQL Server per i dati.
Conclusione
Creare ACCDE Access è l’ultimo passaggio di una build, non il primo. Prima devi avere un front-end stabile, compilato, versionato e indipendente da configurazioni casuali del PC dello sviluppatore. Poi crei ACCDE, lo testi e lo distribuisci.
Per una soluzione completa combina ACCDE con Runtime, front-end locale, updater e back-end protetto. Consulta anche tutte le Guide Access.
Fonti Microsoft: Hide VBA code from users; Deploy an Access application.