Maschera Access: se una maschera Access non salva i dati, le cause più frequenti sono un’Origine record non aggiornabile, controlli non associati ai campi, proprietà della maschera che vietano modifiche o aggiunte, validazioni che annullano il salvataggio, errori di integrità o codice VBA che esegue Undo o Requery nel momento sbagliato.
Prima distinzione: il dato non viene mai salvato o scompare?
Prima di modificare la maschera devi capire il sintomo esatto. Se digiti un valore e il controllo non accetta modifiche, il problema è diverso dal caso in cui il valore sembra accettato ma scompare quando cambi record. Ancora diverso è il caso in cui Access mostra un messaggio di errore durante il salvataggio.
Apri direttamente la tabella o la query di origine dopo il tentativo. Se il valore è presente nei dati ma non appare nella maschera, il problema è di visualizzazione o Requery. Se il valore non è presente, concentrati su associazione del controllo, aggiornabilità e ciclo di salvataggio.
Controlla l’Origine record
Apri la maschera in Visualizzazione Struttura, premi F4 e seleziona la maschera. Nella scheda Dati verifica Origine record. Può essere una tabella, una query o SQL. Se è una query, aprila separatamente in Visualizzazione Foglio dati e prova a modificare un campo.
Microsoft Support chiarisce che alcune query non permettono l’aggiornamento: crosstab, SQL-specifiche, query con GROUP BY e vari altri scenari. Una maschera basata su una query non aggiornabile può mostrare perfettamente i dati ma non può salvarne le modifiche.
Query con più tabelle
Una query multi-tabella non è automaticamente non aggiornabile. Molte query con join corretti restano modificabili, ma l’aggiornabilità dipende dalle relazioni, dalle chiavi e dai campi selezionati. Se Access non riesce a determinare quale riga della tabella debba essere aggiornata, blocca la modifica.
Verifica che le tabelle abbiano chiavi primarie, che i join siano coerenti e che il recordset non contenga aggregazioni o DISTINCT non necessari. Se la maschera serve a modificare una sola entità, considera un’origine record più semplice e usa sottomaschere per i dati correlati.
Controlli associati e non associati
Se un controllo ha Origine controllo vuota, è non associato e il valore digitato non viene memorizzato in un campo del record. Se Origine controllo contiene un’espressione che inizia con =, il controllo è calcolato. Per salvare un dato, l’Origine controllo deve puntare a un campo aggiornabile dell’Origine record.
È comune creare una casella di testo per un filtro o un calcolo e poi aspettarsi che venga salvata. Controlla ogni campo problematico: Nome del controllo e Origine controllo sono due proprietà diverse.
AllowEdits, AllowAdditions e DataEntry
La maschera dispone di proprietà che determinano cosa può fare l’utente. Se AllowEdits è No, i record esistenti non possono essere modificati. Se AllowAdditions è No, non puoi inserire nuovi record. DataEntry=Sì fa aprire la maschera mostrando soltanto il record nuovo e ha effetto sull’inserimento quando AllowAdditions è Sì.
Microsoft documenta DataEntry e chiarisce che non è la proprietà che da sola consente aggiunte. Controlla quindi l’insieme delle proprietà invece di cambiare un solo valore a caso.
Locked ed Enabled sui controlli
Un singolo controllo può essere Locked=Yes e quindi non modificabile anche quando la maschera consente modifiche. Enabled=No impedisce normalmente di ricevere il focus. Queste proprietà sono utili per campi calcolati o protetti, ma possono essere impostate accidentalmente.
Controlla inoltre se un evento Current modifica dinamicamente Locked o Enabled in base allo stato del record. Un campo potrebbe essere modificabile su alcuni record e bloccato su altri.
BeforeUpdate che annulla il salvataggio
L’evento BeforeUpdate della maschera può impostare Cancel=True. È il comportamento corretto quando una validazione fallisce, ma se la condizione è scritta male può bloccare ogni record. Controlla macro e VBA associati a BeforeUpdate.
Assicurati che l’utente riceva un messaggio chiaro. Se il codice annulla il salvataggio senza spiegazione, sembra che la maschera non salvi. Prova temporaneamente a registrare la condizione o eseguire il codice passo passo.
Regole di convalida
Una Validation Rule a livello di campo o tabella può impedire il salvataggio. Controlla Validation Rule e Validation Text. Un esempio corretto è impedire DataFine precedente a DataInizio; se la regola non gestisce Null come previsto, può bloccare record che pensavi validi.
Non eliminare la regola solo per far salvare. Prima verifica il requisito di business e correggi la regola o il dato. Le validazioni proteggono l’integrità del database.
Campo Required
Se un campo della tabella è Required e la maschera non lo mostra o non lo valorizza, il salvataggio può fallire. Controlla la struttura della tabella e i campi obbligatori. Una maschera di inserimento deve fornire tutti i valori richiesti o assegnare valori predefiniti validi.
Questo succede spesso quando una tabella evolve: viene aggiunto un nuovo campo obbligatorio ma una vecchia maschera non viene aggiornata. Il riquadro Dipendenze oggetti aiuta a capire quali oggetti dipendono dalla tabella.
Indice univoco e duplicati
Un indice univoco impedisce duplicati. Se l’utente tenta di salvare un codice già esistente, Access rifiuta il record. La soluzione non è rimuovere l’indice se l’unicità è necessaria, ma mostrare un messaggio più chiaro e permettere all’utente di correggere il codice.
In Form_Error puoi intercettare errori dati noti e tradurli in testi comprensibili. In ambiente multiutente l’indice resta la protezione definitiva, anche se fai un controllo preventivo con DCount.
Integrità referenziale
Se un ordine contiene un IDCliente che non esiste nella tabella Clienti e la relazione applica integrità referenziale, il salvataggio viene rifiutato. È un comportamento corretto. La maschera dovrebbe usare una combo che permette di selezionare solo clienti validi.
Non disattivare l’integrità per aggirare l’errore. Correggi la chiave esterna, la combo o il flusso di inserimento. I record orfani sono molto più difficili da riparare dopo.
Chiave primaria mancante
Una tabella senza chiave primaria può funzionare in casi semplici, ma rende difficile identificare in modo univoco i record e può contribuire a query non aggiornabili. Ogni entità importante dovrebbe avere una chiave primaria adeguata.
Se il back-end è SQL Server, verifica che Access riconosca correttamente la chiave univoca della tabella collegata. Senza identificatore univoco, alcune tabelle ODBC possono risultare di sola lettura.
Maschera basata su query Totali
Query con GROUP BY, Sum, Count e altre aggregazioni sono pensate per riepilogare dati, non per modificare le righe sorgenti. Una maschera basata su una query Totali deve essere considerata di consultazione.
Se devi modificare i dati, apri una maschera di dettaglio basata su una tabella o query aggiornabile. Non tentare di rendere editabile il riepilogo forzando proprietà della maschera.
Query DISTINCT, UNION e crosstab
Anche queste query possono non essere aggiornabili. Microsoft elenca varie situazioni in cui i dati di una query non possono essere modificati. Se il tuo RecordSource usa DISTINCT perché stai cercando di nascondere duplicati creati da un join sbagliato, correggi prima il modello della query.
UNION e crosstab sono strumenti eccellenti per analisi e presentazione, ma non per una maschera di editing tradizionale.
RecordsetType
La proprietà RecordsetType della maschera può influenzare l’aggiornabilità in query multi-tabella. Microsoft Support segnala l’opzione Dynaset (Inconsistent Updates) in specifici scenari. Non impostarla automaticamente: comprendi prima le relazioni e verifica gli effetti.
Se una query semplice a tabella singola non salva, RecordsetType raramente è la prima cosa da cambiare. Parti da Origine record, controlli e proprietà di modifica.
Il record è Dirty?
La proprietà Dirty indica se il record corrente contiene modifiche non salvate. Se Me.Dirty è False dopo che credi di aver modificato un campo, potrebbe essere un controllo non associato. Se è True, Access tenterà di salvare quando cambi record o imposti Dirty=False.
Usa questa proprietà nel debug per capire se la modifica fa parte del record. Non forzare continuamente Dirty=False in eventi come Change: provocheresti salvataggi troppo frequenti.
Pulsante Salva che non funziona
Controlla l’evento Su clic. Se usi DoCmd.RunCommand acCmdSaveRecord o Me.Dirty=False, BeforeUpdate può comunque annullare il salvataggio. Un errore può quindi essere nella validazione, non nel pulsante.
Compila il progetto VBA e controlla eventuali errori di sintassi o riferimenti mancanti. Se il pulsante usa una macro, verifica ogni azione e condizione.
Requery nel momento sbagliato
Un Requery riesegue l’origine record e può causare perdita delle modifiche non salvate o spostare il record corrente se usato male. Evita Requery prima di assicurarti che il record sia stato salvato.
Se vuoi aggiornare una combo, fai Requery della combo. Se vuoi visualizzare modifiche già presenti, valuta Refresh. Non usare Requery dell’intera maschera come soluzione universale.
Undo involontario
Controlla pulsanti Annulla, eventi Exit/Unload e routine di errore. Un Me.Undo eseguito automaticamente può far scomparire le modifiche senza che l’utente capisca perché.
Undo deve essere associato a una scelta esplicita o a una situazione ben documentata. Se viene usato durante la chiusura, chiedi conferma soltanto quando Me.Dirty è True.
Evento Unload e chiusura
Microsoft Learn documenta che Unload può essere annullato. Se il salvataggio fallisce durante la chiusura, assicurati che la maschera rimanga aperta e dia all’utente la possibilità di correggere. Non chiudere forzatamente dopo una validazione fallita.
Prova la chiusura dalla X, dal pulsante Chiudi e tramite eventuali macro. Tutti i percorsi devono comportarsi in modo coerente.
Campi calcolati
Un controllo con Origine controllo come =[Quantita]*[Prezzo] calcola un risultato ma non salva necessariamente quel valore in un campo. Spesso è corretto: i totali derivati possono essere calcolati quando servono invece di duplicare dati.
Se vuoi davvero memorizzare un valore calcolato, valuta attentamente il modello. Salvare risultati derivati può creare incoerenze se i valori sorgente cambiano.
Autonumerazione
Un campo Autonumerazione viene gestito da Access e non deve essere impostato manualmente nei nuovi record. Se un controllo associato alla chiave Autonumerazione è bloccato, è normale.
Usa la chiave dopo che Access l’ha generata. Per creare record correlati in sottomaschere, i collegamenti master/child gestiscono normalmente la chiave esterna.
Back-end Access in rete
In un database condiviso è buona pratica separare front-end e back-end, con una copia locale del front-end per ogni utente. Problemi di permessi sulla cartella, file bloccato in sola lettura o connessioni instabili possono impedire modifiche.
Verifica che gli utenti abbiano i permessi necessari nella cartella del back-end e che il file non sia aperto in modalità esclusiva da un altro processo.
SQL Server e ODBC
Se le tabelle sono collegate via ODBC, Access deve identificare una chiave univoca per aggiornare i record. Controlla chiavi primarie lato server, collegamenti e driver. Una vista SQL Server senza chiave identificabile può risultare non aggiornabile.
Non risolvere problemi di aggiornabilità trasferendo intere tabelle in locale senza valutare sicurezza e consistenza. Correggi il modello server e il collegamento.
Microsoft 365, Access 2024 e Runtime
Le proprietà e gli eventi descritti valgono per Access desktop per Windows nelle versioni correnti, incluse Microsoft 365 e Access 2024. Runtime esegue maschere e VBA già predisposti ma non è un ambiente completo di progettazione.
In Runtime devi gestire bene gli errori, perché l’utente non può entrare facilmente in Struttura o nell’Editor VBA. Mostra messaggi utili e registra dettagli tecnici se l’applicazione è importante.
Access non ha un equivalente desktop nativo per macOS. Queste procedure non sono funzioni Web.
32/64 bit
La capacità di salvare normali record non dipende dall’architettura 32/64 bit. Se però il salvataggio attiva codice che chiama API, controlli ActiveX o librerie esterne, una incompatibilità può interrompere la routine.
Compila il progetto e verifica riferimenti. Per API Windows usa dichiarazioni compatibili con VBA7 quando necessario.
Metodo diagnostico rapido
Primo: verifica se il controllo è associato. Secondo: apri l’Origine record e prova a modificare. Terzo: controlla AllowEdits/AllowAdditions. Quarto: controlla Locked. Quinto: controlla BeforeUpdate e Validation Rule. Sesto: controlla chiavi, indici e integrità. Settimo: verifica VBA e macro. Ottavo: cerca Requery/Undo. Nono: prova direttamente nella tabella. Decimo: testa con una copia semplice.
Questo ordine copre la maggior parte dei casi senza cambiare proprietà inutilmente.
Scenario: nuovo cliente non viene salvato
frmClienti è basata su tblClienti. cboProvincia è associata correttamente ma txtCodiceCliente è obbligatorio e ha indice univoco. Se il codice è vuoto o duplicato, il salvataggio fallisce. La soluzione è validare il campo e mostrare un messaggio, non rimuovere Required o l’indice.
Se tutti i campi sono validi ma il record scompare, verifica che un evento AfterUpdate non esegua Requery e che il filtro corrente non escluda il nuovo cliente.
Scenario: modifica ordine non resta
frmOrdine è basata su una query con GROUP BY per mostrare totali. La query non è aggiornabile. La soluzione è usare una query aggiornata per i campi dell’ordine e calcolare i totali con una sottomaschera o controlli calcolati, oppure aprire una maschera di dettaglio separata.
La visualizzazione e la modifica non devono per forza usare la stessa query.
Link interni
Approfondisci con validazione dati in maschera, errori nei controlli, VBA nelle maschere, maschera sola lettura e la categoria Guide Access.
Fonti Microsoft
Per aggiornabilità delle query e origini record consulta Microsoft Support. Per DataEntry consulta Microsoft Support: DataEntry. Per l’evento di chiusura consulta Microsoft Learn: Form.Unload.
FAQ
Perché posso vedere ma non modificare i dati? Spesso la query di origine non è aggiornabile oppure AllowEdits è No.
Perché un controllo non salva? Potrebbe essere non associato o calcolato.
Perché il record sparisce dopo il salvataggio? Potrebbe essere escluso da un filtro o da un Requery; verifica prima se esiste nella tabella.
DataEntry=Sì basta per inserire? No, AllowAdditions deve consentire l’aggiunta.
Runtime può salvare dati? Sì, se la maschera e l’origine sono aggiornabili e i permessi lo consentono.
Conclusione
Quando una maschera Access non salva i dati, la soluzione nasce da una diagnosi ordinata. Controlla prima associazione dei controlli e aggiornabilità dell’Origine record, poi proprietà di modifica, validazioni, chiavi e integrità, infine eventi, macro e VBA.
Non disattivare vincoli importanti solo per far scomparire l’errore. Una maschera affidabile deve salvare soltanto record coerenti, spiegare chiaramente cosa impedisce il salvataggio e mantenere separati i problemi dell’interfaccia dai vincoli del database.