Come usare moduli VBA in Access: tutorial pratico

access vba: usare moduli VBA in Microsoft Access significa organizzare procedure, funzioni, costanti ed eventi nel contenitore corretto. Access distingue moduli standard, moduli di classe non associati a un oggetto e moduli di classe collegati a maschere e report. Capire questa struttura evita codice duplicato, errori di visibilità e progetti difficili da mantenere.

Questa guida spiega come creare e usare i diversi tipi di modulo, come scegliere tra Public e Private, come organizzare funzioni riutilizzabili, come gestire dipendenze e riferimenti e come distribuire il codice in Access per Microsoft 365, Access 2024 e Runtime.

Indice

Che cos’è un modulo
Modulo standard
Modulo di maschera
Modulo di report
Modulo di classe
Public e Private
Option Explicit
Costanti e variabili di modulo
Dipendenze e riferimenti
Runtime e 32/64 bit
FAQ

Che cos’è un modulo in Access

Microsoft Learn definisce l’oggetto Module come rappresentazione di un modulo standard o di un modulo di classe. Access include inoltre moduli di maschera e report associati ai rispettivi oggetti. La raccolta Modules contiene i moduli aperti, compilati o non compilati.

Un modulo non è una tabella e non contiene dati utente. Contiene codice VBA. Il modo in cui quel codice è accessibile dipende dal tipo di modulo e dalla visibilità delle procedure.

Modulo standard

Il modulo standard è il posto naturale per logica riutilizzabile. Esempi: funzioni di calcolo, importazioni, esportazioni, utility file, funzioni di validazione generiche, routine DAO e procedure richiamate da più maschere.

Crea un modulo dalla scheda Crea e salvalo con nome come modUtility, modImportazioni o modReport. Evita Module1 in progetti reali.

Esempio di modulo standard

Option Compare Database
Option Explicit

Public Const APP_NAME As String = "Gestione Clienti"

Public Function PulisciTesto(ByVal valore As Variant) As String
    PulisciTesto = Trim$(Nz(valore, vbNullString))
End Function

La costante e la funzione possono essere richiamate da altri moduli se Public.

Modulo della maschera

Ogni maschera con codice ha un modulo di classe associato. Qui vivono gli eventi come Form_Load, Form_Current, cmdSalva_Click e Form_BeforeUpdate. Il codice può usare Me per riferirsi all’istanza corrente della maschera.

Esempio:

Private Sub Form_Current()
    Me.cmdElimina.Enabled = Not Me.NewRecord
End Sub

Questo codice appartiene al comportamento della maschera e non ha senso spostarlo interamente in un modulo standard. Puoi però chiamare funzioni generali da qui.

Modulo del report

Analogamente, un report può avere un modulo associato con eventi di apertura, formattazione e altri eventi disponibili. Usa il modulo report per logica specifica del report, non come contenitore generico per funzioni di tutta l’applicazione.

Modulo di classe personalizzato

Access consente anche class module non associati a form o report. Sono utili quando vuoi modellare un oggetto con proprietà, metodi ed eventi propri. Per molte applicazioni Access piccole non sono indispensabili, ma nei progetti complessi possono migliorare la separazione delle responsabilità.

Un class module può rappresentare, per esempio, una configurazione, un servizio di log o un oggetto business. Non introdurre classi soltanto per rendere il progetto più sofisticato: usale quando semplificano realmente struttura e test.

Public e Private

Public Sub e Public Function in un modulo standard sono accessibili da altri moduli. Private limita l’accesso al modulo. Nei moduli di maschera gli eventi sono normalmente Private.

Riduci la superficie Public: se una procedura è un helper interno, rendila Private. In questo modo IntelliSense e struttura del progetto sono meno affollati.

Variabili di modulo

Una variabile dichiarata nella sezione dichiarazioni del modulo può mantenere valore finché il modulo resta caricato e il progetto non viene resettato. Esempio:

Private mAggiornamentoInCorso As Boolean

È utile per flag di stato locali. Evita però di usare variabili globali come database parallelo. Lo stato importante deve essere in tabelle o oggetti progettati appositamente.

Variabili globali

Una Public variable in un modulo standard è accessibile in tutto il progetto, ma può perdere valore se il progetto VBA viene resettato dopo un errore non gestito. Non memorizzare informazioni critiche che devono sopravvivere a un reset. Per configurazioni e sessione valuta TempVars o tabelle, a seconda del requisito.

Option Compare Database

Questa direttiva imposta il confronto stringhe secondo le regole del database. È tipica dei moduli Access. Se usi Option Compare Text o Binary, documenta il motivo perché può cambiare il comportamento dei confronti.

Option Explicit

Attivala sempre. Obbliga a dichiarare le variabili e riduce errori dovuti a nomi scritti male. Nel VBE puoi abilitare Require Variable Declaration affinché venga aggiunta ai nuovi moduli.

Come dividere il codice per responsabilità

Una struttura pratica può essere: modDAO per accesso dati comune, modImport per importazioni, modExport per esportazioni, modUtility per funzioni generiche e moduli form/report per eventi UI. Non creare però decine di moduli con una sola riga ciascuno.

Il criterio è coesione: procedure che lavorano sullo stesso problema dovrebbero stare vicine.

Dipendenze tra moduli

Evita dipendenze circolari. Se modA chiama modB e modB richiede modA, il progetto diventa difficile da comprendere. Sposta funzioni comuni in un livello utility più neutro.

Funzioni usate dalle query

Le Public Function richiamate da query devono stare in moduli standard. Se la funzione è nel modulo di una maschera, una query indipendente non dovrebbe dipendere da quell’istanza. Microsoft documenta regole specifiche per RunCode e ricerca delle funzioni nei moduli standard.

Nome del modulo e nome della funzione

Evita di usare lo stesso nome. Può causare ambiguità e Microsoft segnala che RunCode non può chiamare una Function se il nome della funzione coincide con il nome del modulo.

Riferimenti

I moduli possono usare librerie come DAO, Office o altre. Se un riferimento manca su un altro PC, l’intero progetto può non compilare. Controlla Strumenti → Riferimenti e riduci librerie inutili.

Per automazioni Office valuta late binding quando devi tollerare versioni differenti. Early binding è più comodo in sviluppo per IntelliSense. Qualunque scelta va testata sui PC reali.

Compilare il progetto

Dopo modifiche ai moduli scegli Debug → Compile. La compilazione individua errori di sintassi, procedure non valide e molti problemi di riferimenti. Fallo prima di creare ACCDE o distribuire il front-end.

Moduli e ACCDE

Un file ACCDE contiene il codice VBA compilato e impedisce modifiche al sorgente tramite il normale ambiente Access. È utile per distribuzione, ma devi conservare l’ACCDB sorgente. Non puoi usare l’ACCDE come unica copia di sviluppo.

Moduli e Access Runtime

Runtime esegue il codice incluso ma non è l’ambiente per svilupparlo. Tutte le procedure operative devono essere raggiungibili da maschere e pulsanti. Gestisci errori e configurazioni senza richiedere al tecnico di aprire il VBE sul PC dell’utente.

32 e 64 bit

Il codice VBA normale nei moduli non cambia. Isola dichiarazioni API Windows in moduli dedicati e usa compatibilità VBA7 con PtrSafe e LongPtr quando necessario. Questo rende più facile verificare la migrazione 32/64 bit.

Microsoft 365 e Access 2024

La struttura moduli e il modello VBA sono parte delle versioni desktop moderne. Microsoft Learn documenta Module e Modules. Le differenze pratiche emergono soprattutto da librerie e componenti esterni.

Documentare i moduli

All’inizio del modulo aggiungi commenti con scopo e dipendenze. Per procedure pubbliche documenta parametri e effetti. Non serve un romanzo: bastano informazioni che permettano a un altro sviluppatore di capire perché esiste.

Moduli troppo grandi

Se un modulo contiene migliaia di righe su argomenti diversi, dividilo. Se contiene dieci moduli quasi identici, centralizza. La manutenzione richiede equilibrio.

Gestione errori comune

Puoi creare funzioni comuni per logging, ma non nascondere il contesto. Ogni procedura dovrebbe sapere quale errore può gestire localmente e quale deve propagare.

Test delle funzioni

La finestra Immediata è utile per Public Function e Sub. Per logica critica crea procedure di test che eseguano casi noti. Access non include un framework unit test completo di serie, ma puoi comunque strutturare test ripetibili.

Performance

La posizione del codice nel modulo non cambia direttamente la velocità. Conta ciò che il codice fa. Funzioni usate da query per ogni record possono essere lente; eventi Current con DLookup ripetuti possono rallentare la UI. Organizzare bene i moduli aiuta a individuare e ottimizzare questi punti.

Multiutente

Ogni utente dovrebbe avere una copia locale del front-end con gli stessi moduli/versione, collegata al back-end. Non far eseguire a tutti lo stesso file front-end da rete. Usa un processo di aggiornamento per distribuire nuove versioni.

Problemi comuni

Sub o Function non definita

Controlla visibilità, nome, modulo e compilazione.

Riferimento mancante

Apri References e correggi la libreria. Il problema può apparire solo su alcuni PC.

Ambiguous name detected

Due procedure hanno lo stesso nome nello stesso ambito. Rinominale.

La query non vede la funzione

Mettila Public in modulo standard e compila.

Una variabile globale perde valore

Un reset del progetto può azzerarla. Non usarla per stato persistente critico.

Checklist

Per ogni modulo chiediti: responsabilità chiara, nome chiaro, procedure Public necessarie, helper Private, Option Explicit, dipendenze documentate, riferimenti minimi, gestione errori e test. Compila prima di distribuire.

Per applicazioni multiutente verifica che tutti abbiano la stessa versione front-end e che i moduli non dipendano da percorsi personali.

FAQ

Dove metto una funzione usata da più maschere?

In un modulo standard Public.

Gli eventi vanno in modUtility?

No, gli eventi restano nei moduli delle maschere/report e possono chiamare utility.

Cos’è un class module?

Un modulo che definisce una classe con stato e comportamento, oppure il modulo associato a form/report.

Posso modificare moduli in Runtime?

Runtime è destinato all’esecuzione, non al normale sviluppo.

Perché compilare?

Per rilevare errori prima dell’esecuzione e prima della distribuzione.

Approfondimenti

Conclusione

Usare bene i moduli VBA in Access significa mettere il codice nel posto corretto e rendere esplicite responsabilità e dipendenze. Usa moduli standard per logica riutilizzabile, moduli form/report per eventi e class module personalizzati solo quando portano un vantaggio reale. Limita le procedure Public, attiva Option Explicit, compila spesso e isola dipendenze esterne. Questa organizzazione rende il database più semplice da distribuire, debuggare e aggiornare nel tempo.