Quando conviene usare macro e quando VBA in Access dipende soprattutto da complessità, sicurezza, manutenzione e modalità di distribuzione. Le macro sono ideali per automazioni semplici, eventi di maschere, apertura di report, navigazione e operazioni standard; VBA è preferibile quando servono funzioni personalizzate, cicli, gestione avanzata degli errori, automazione di file e applicazioni esterne, DAO, API Windows o logiche riutilizzabili complesse.
Microsoft distingue chiaramente le macro di Access dal codice VBA. Le macro vengono costruite nel Generatore di macro come sequenze di azioni; VBA viene scritto nell’editor Visual Basic e offre un set di funzionalità molto più ampio. Per approfondire consulta la categoria Guide Access, la guida su come creare una macro, quella su come usare VBA e la guida su come risolvere gli errori VBA.
La differenza fondamentale tra macro e VBA
Una macro di Access è una raccolta dichiarativa di azioni. Se vuoi aprire una maschera, applicare un filtro, mostrare un messaggio, eseguire una query salvata, aprire un report o impostare un valore, spesso puoi farlo selezionando azioni e argomenti dal Generatore di macro. Il vantaggio è che la logica è leggibile anche da chi non programma e molte attività possono essere implementate senza sintassi.
VBA, invece, è un linguaggio di programmazione completo integrato nelle applicazioni desktop di Microsoft Office. In Access puoi creare procedure Sub e Function, variabili, strutture If, Select Case, For, Do, oggetti DAO, classi, chiamate API, automazioni verso Excel o Outlook classico e funzioni personalizzate richiamabili da query ed espressioni. È quindi più potente, ma anche più facile da rendere fragile se manca disciplina progettuale.
Regola decisionale rapida
Se l’automazione può essere descritta come una sequenza lineare di azioni Access ben supportate dal Generatore di macro, inizia da una macro. Se invece devi manipolare molti record uno alla volta, iterare file, creare algoritmi, riutilizzare funzioni in più punti, controllare errori dettagliati o interagire in profondità con il sistema operativo, scegli VBA.
- Usa macro per apertura e chiusura di oggetti, navigazione, filtri semplici, messaggi, esecuzione di comandi e logiche evento lineari.
- Usa VBA per calcoli complessi, funzioni personalizzate, DAO, transazioni, gestione file, cicli, strutture dati, integrazioni e diagnostica avanzata.
- Usali insieme quando una macro gestisce l’interfaccia e richiama una funzione VBA per la parte tecnica più complessa.
Quando scegliere una macro
Le macro funzionano bene quando il processo è vicino all’interfaccia utente e può essere rappresentato con azioni standard. Un pulsante che apre un report filtrato, una maschera che all’apertura imposta un valore predefinito, una procedura che chiude una finestra e ne apre un’altra o una macro AutoExec per avviare una routine all’apertura del database sono casi classici.
La semplicità ha un valore operativo. In un database gestito da personale non tecnico, una macro può essere più facile da leggere, modificare e documentare. Il Generatore di macro espone gli argomenti, riduce gli errori di sintassi e impedisce molte classi di bug tipiche del codice scritto manualmente. Per applicazioni piccole questo può ridurre notevolmente i costi di manutenzione.
Macro incorporate negli eventi
Access permette di incorporare una macro direttamente in proprietà evento di maschere e controlli. Se la logica appartiene soltanto a quel pulsante o a quella maschera, una macro incorporata rende evidente il collegamento tra evento e comportamento. Quando l’oggetto viene copiato, la macro incorporata resta associata all’oggetto.
AutoExec e AutoKeys
Alcune attività sono naturalmente legate alle macro. Una macro denominata AutoExec viene eseguita quando il database si apre, prima di altre macro o codice collegato alla maschera di avvio. AutoKeys consente invece di associare azioni a combinazioni di tasti. Questi scenari sono documentati da Microsoft come casi tipici in cui le macro hanno un ruolo specifico.
Quando scegliere VBA
VBA diventa preferibile quando la logica supera una sequenza di azioni. Se devi elaborare una cartella con cinquanta file Excel, controllare i nomi, importarli, registrare esito e dimensione, spostare quelli riusciti e inviare una notifica in caso di errore, una macro diventerebbe lunga e difficile da controllare. In VBA puoi scomporre il processo in funzioni piccole e testabili.
VBA è inoltre necessario o fortemente consigliato quando devi creare funzioni personalizzate, manipolare oggetti in modo dinamico, usare DAO Recordset, eseguire transazioni, gestire collezioni, interagire con API Windows o creare logiche di errore centralizzate. Microsoft indica proprio la creazione di funzioni, la manipolazione degli oggetti e le operazioni a livello di sistema tra i motivi per usare VBA invece delle sole macro.
Esempio pratico: aprire un report
Per aprire un report con un pulsante, una macro è spesso la scelta migliore. L’azione OpenReport può specificare il nome del report, la modalità di visualizzazione e una condizione Where. Non serve scrivere codice se il comportamento è fisso e facilmente configurabile.
Se invece il filtro deve essere costruito da molti controlli opzionali, validato, registrato in log e adattato ai permessi dell’utente, VBA offre una struttura più chiara. Puoi creare una funzione che costruisce la condizione, controlla i valori e chiama DoCmd.OpenReport. La differenza non è soltanto la potenza: è la possibilità di separare responsabilità e riutilizzare codice.
Esempio pratico: importare dati
Per importare un singolo file con percorso noto puoi usare una macro con ImportExportSpreadsheet o una procedura simile. Se il file è sempre lo stesso e il processo non richiede controlli particolari, una macro è semplice e trasparente.
Se devi scorrere una cartella, importare tutti i file che rispettano un pattern, evitare duplicati, gestire errori file per file e scrivere un log, VBA è molto più adatto. Puoi usare Dir o FileSystemObject, cicli For/Do, DoCmd.TransferSpreadsheet e un gestore errori. Una macro lineare non è progettata per offrire la stessa flessibilità algoritmica.
Esempio pratico: aggiornare dati
Per eseguire una query di aggiornamento salvata tramite pulsante una macro è sufficiente. Tuttavia, per processi critici conviene considerare VBA con DAO Execute e dbFailOnError, soprattutto se devi verificare RecordsAffected, gestire transazioni o eseguire più query come un’unica unità logica.
La scelta dipende quindi dal rischio. Un comando occasionale su dati non critici può essere macro; una procedura che contabilizza movimenti, modifica più tabelle e deve poter effettuare rollback merita VBA, controlli e log dettagliati.
Sicurezza: macro e VBA non sono equivalenti
Microsoft sottolinea che VBA può eseguire operazioni potenti, compresa l’interazione con file e altre applicazioni. Per questo un database che contiene codice deve provenire da una fonte affidabile. Le impostazioni del Centro protezione possono disabilitare contenuti attivi in file non attendibili.
Le macro sono generalmente più limitate e alcune azioni possono essere eseguite senza richiedere lo stesso livello di attendibilità. Microsoft consiglia, quando possibile, di usare macro per operazioni che non richiedono VBA, soprattutto quando il database deve essere distribuito ad altri utenti. Questo non significa che una macro sia automaticamente sicura: bisogna comunque controllare azioni, query e origine del file.
Manutenzione nel lungo periodo
Un database vive spesso più a lungo di quanto previsto. Il criterio migliore non è “scrivere meno codice”, ma scegliere una struttura che un altro tecnico possa comprendere. Una macro di venti azioni annidate può essere più difficile da mantenere di una funzione VBA di trenta righe ben nominata. Allo stesso modo, una procedura VBA enorme usata solo per aprire una maschera è complessità inutile.
Dividi la logica in unità coerenti. Le macro possono occuparsi di flussi di interfaccia. I moduli standard VBA possono contenere funzioni comuni, validazione, import/export e servizi. I moduli di classe di maschere e report dovrebbero contenere soprattutto codice strettamente legato agli eventi di quell’oggetto.
Debug: dove VBA è superiore
Il Generatore di macro offre strumenti di esecuzione e gestione errori, ma l’editor VBA dispone di breakpoint, Step Into, Step Over, Watch, Locals, Call Stack, Immediate Window e Debug.Print. Per una logica complessa questa osservabilità è decisiva. Puoi fermarti prima della riga sospetta, verificare i valori e modificare temporaneamente una variabile per testare un ramo.
Se un processo è così importante da richiedere diagnosi dettagliata in produzione, VBA tende a essere la scelta migliore, soprattutto se accompagni il codice con una tabella log che registra procedura, numero errore, descrizione, utente, versione del front-end e timestamp.
Gestione degli errori nelle macro
Le macro moderne di Access includono azioni per gestire errori in modo più strutturato rispetto alle versioni molto vecchie. Questo permette di costruire flussi robusti senza scrivere codice per ogni caso. Tuttavia, se devi analizzare errori restituiti da DAO, distinguere numeri specifici, fare retry controllati o eseguire cleanup di oggetti, VBA offre un controllo più fine.
Non scegliere VBA soltanto perché “gestisce gli errori”. Prima valuta se il rischio è reale. Per una macro che apre una maschera, mostra un messaggio e chiude l’oggetto corrente, un’infrastruttura di logging VBA sarebbe eccessiva. Per un processo di importazione notturno, invece, è quasi indispensabile.
Prestazioni: macro o VBA?
Per operazioni semplici la differenza di prestazioni è raramente il criterio principale. Il vero costo è spesso nelle query, nell’accesso ai dati, nella rete e nel numero di record elaborati. Se una macro esegue una query SQL efficiente, sarà molto più veloce di un ciclo VBA che aggiorna record uno per uno. Non usare VBA per sostituire inutilmente operazioni set-based che Access sa già eseguire con query.
VBA è utile quando serve orchestrare query efficienti, non quando deve imitare il motore SQL. Un buon pattern consiste nel preparare parametri e logica in VBA, eseguire una query di azione set-based con DAO Execute e registrare il numero di righe interessate.
Macro e Access Runtime
Access Runtime può eseguire applicazioni contenenti macro e VBA, ma non offre l’esperienza completa di progettazione. Per questo la scelta deve considerare ciò che succede quando qualcosa va storto. Una macro semplice può essere più prevedibile per un utente Runtime, mentre il VBA complesso deve includere messaggi e logging perché l’utente non può entrare comodamente nell’editor e fare debug.
Non confondere Runtime con una sandbox di sicurezza. Il fatto che l’utente non veda l’editor non rende automaticamente sicuro il codice. Distribuisci solo file controllati, considera ACCDE per impedire modifiche al sorgente e usa percorsi attendibili gestiti quando appropriato.
Macro e file ACCDE
ACCDE compila il codice VBA e rimuove la possibilità di modificarne il sorgente nell’app distribuita. È utile per proteggere la progettazione del front-end e ridurre modifiche accidentali. Le macro continuano a far parte dell’applicazione e possono essere usate normalmente. Se prevedi aggiornamenti frequenti, mantieni sempre il file sorgente ACCDB in un repository o backup separato: un ACCDE non deve diventare l’unica copia del progetto.
32 bit e 64 bit
Le macro standard di Access sono meno esposte ai problemi di bitness. VBA diventa invece sensibile quando usa API Windows, ActiveX o librerie COM esterne. Se una soluzione deve funzionare su Access 32 e 64 bit, verifica le dichiarazioni PtrSafe e LongPtr e la disponibilità dei componenti esterni. Una scelta macro può quindi ridurre dipendenze quando l’automazione richiesta rientra già nelle azioni disponibili.
Il normale codice VBA che usa oggetti Access e DAO non deve essere riscritto soltanto perché Office è a 64 bit. I problemi nascono soprattutto alle frontiere con componenti nativi esterni.
Macro e integrazione con Excel o Outlook
Per avviare un’applicazione o trasferire dati standard puoi utilizzare azioni macro e comandi DoCmd. Se però devi controllare celle Excel, formattare cartelle di lavoro, creare grafici, iterare fogli o comporre email con allegati e regole dinamiche, VBA con Automation offre un controllo molto maggiore.
Per Outlook considera anche l’evoluzione del client. L’automazione COM tradizionale è legata al modello desktop classico; il nuovo Outlook per Windows non offre la stessa compatibilità con COM/VSTO. Un progetto Access che dipende da Outlook.Application deve quindi essere testato con il client effettivamente distribuito.
Macro e multiutente
In un database multiutente la decisione non cambia soltanto per il numero di persone. Conta dove gira la logica. Con un database diviso ogni utente dovrebbe avere una copia locale del front-end, mentre il back-end contiene le tabelle condivise. Macro e VBA del front-end vengono quindi eseguiti localmente sul PC dell’utente.
Questo rende importante distribuire la stessa versione del front-end a tutti. Se una modifica VBA cambia una query o un flusso, utenti con versioni diverse possono comportarsi in modo incoerente. Implementa un controllo versione e una procedura di aggiornamento del front-end.
Approccio ibrido consigliato
Molte applicazioni migliori non scelgono esclusivamente macro o VBA. Una maschera può usare una macro incorporata per aprire un report; un altro pulsante può chiamare una funzione VBA che esegue un’elaborazione complessa. L’obiettivo è mantenere la logica nel livello più semplice che riesce a soddisfare bene il requisito.
Un buon criterio architetturale è concentrare il codice comune nei moduli standard. Se tre maschere devono calcolare lo stesso valore, non duplicare tre macro lunghe: crea una funzione VBA documentata e richiamala dove serve. Se una singola azione serve soltanto a un controllo, evita invece di creare una funzione globale senza motivo.
Matrice decisionale
- Apertura maschera o report: macro.
- Filtro semplice su un pulsante: macro.
- AutoExec all’avvio: macro.
- Funzione personalizzata usata in query: VBA.
- Ciclo su file o record: VBA.
- Transazione con più query: VBA.
- Automazione avanzata Excel: VBA.
- Chiamata API Windows: VBA.
- Messaggio e navigazione semplice: macro.
- Logging centralizzato: VBA.
- Validazione elementare di un campo: regola di convalida o macro evento.
- Validazione complessa tra tabelle: VBA o query con logica centralizzata.
Come migrare una macro verso VBA
Non convertire tutto per principio. Migra quando la macro è diventata difficile da leggere, contiene troppi rami o deve essere riutilizzata. Prima documenta cosa fa, quali oggetti usa e quali risultati attesi produce. Poi crea una funzione VBA equivalente, mantenendo temporaneamente la macro come punto di ingresso se necessario.
Testa ogni percorso prima di sostituire la versione precedente. Se la macro apriva un report con filtri diversi, crea casi di test per ciascun filtro. Una migrazione tecnica senza test può introdurre regressioni anche se il nuovo codice sembra più elegante.
Come semplificare VBA trasformandolo in macro
Può essere utile anche il percorso opposto. Se trovi decine di righe VBA usate soltanto per aprire oggetti e mostrare messaggi, valuta una macro incorporata. Riduci codice superfluo e dipendenze. La semplificazione è particolarmente utile in database gestiti da utenti avanzati ma non sviluppatori.
Non trasformare però in macro procedure che richiedono error handling fine, loop o manipolazione di dati uno a uno. La leggibilità va valutata sul risultato finale, non sul numero di righe.
Checklist prima di decidere
- La funzione esiste già come azione macro?
- La logica è lineare o richiede cicli e strutture complesse?
- Devo riutilizzare la stessa logica in molti oggetti?
- Serve gestire file, applicazioni esterne o API?
- La procedura modifica dati critici e richiede transazioni?
- Il database sarà distribuito con Runtime?
- Gli utenti lavoreranno in ambiente multiutente?
- Esistono dipendenze 32/64 bit?
- Chi dovrà manutenere l’app fra un anno?
- Serve logging dettagliato in produzione?
FAQ
Le macro di Access sono uguali alle macro Excel?
No. In Access il termine macro indica una sequenza di azioni costruita nel Generatore di macro, mentre in molti altri programmi Office “macro” viene spesso usato come sinonimo di codice VBA.
VBA è deprecato in Access?
No. VBA resta parte centrale dell’automazione desktop di Access. Va però usato tenendo conto di sicurezza, distribuzione e compatibilità con componenti esterni.
Una macro può chiamare VBA?
Sì. Le macro possono richiamare funzioni appropriate, permettendo un approccio ibrido in cui la macro gestisce il flusso e VBA esegue la parte complessa.
Con Access Runtime funzionano le macro?
Sì. Runtime esegue applicazioni Access con macro e VBA, ma non è un ambiente di progettazione completo. La soluzione deve quindi essere pronta e testata prima della distribuzione.
Macro significa maggiore sicurezza?
Le macro sono più limitate e Microsoft suggerisce di preferirle quando bastano, ma non sostituiscono una strategia di sicurezza. Query distruttive o azioni non appropriate possono comunque causare problemi.
Per un database multiutente cosa conviene?
La scelta macro/VBA è separata dall’architettura dati. In genere conviene dividere il database e dare a ciascun utente una copia locale del front-end. Macro e VBA vengono eseguiti nel front-end locale.
Conclusione
Quando conviene usare macro e quando VBA in Access si decide valutando il livello di complessità reale. Per automazioni semplici, navigazione, eventi lineari e operazioni standard, la macro è spesso la soluzione più pulita. Per elaborazioni complesse, DAO, transazioni, funzioni personalizzate, integrazioni, gestione file, diagnostica e log centralizzati, VBA è lo strumento corretto.
La documentazione Microsoft sulla programmazione in Access chiarisce le differenze e suggerisce di usare macro quando possibile e VBA quando servono funzionalità non disponibili tramite azioni macro. La scelta migliore non è ideologica: è quella che rende il database più semplice da capire, testare, distribuire e mantenere.