Collegare Azure Access significa, in pratica, usare Microsoft Access come front-end Windows per un database Azure SQL attraverso ODBC. I dati restano nel servizio Azure SQL, mentre Access può visualizzare tabelle e viste collegate, usarle in query, maschere e report e, quando permessi e struttura lo consentono, aggiornare i record.
Questa architettura è utile quando vuoi portare il back-end di un’applicazione Access nel cloud mantenendo il front-end esistente. Microsoft documenta specificamente la procedura nella pagina Link to or import data from an Azure SQL Server Database. La guida seguente copre configurazione, firewall, driver, autenticazione, prestazioni, sicurezza e differenze rispetto a SQL Server locale.
Indice
- Access e Azure SQL: come funziona
- Prerequisiti Azure
- Firewall e rete
- Driver ODBC
- Autenticazione
- Procedura passo passo
- Chiavi e aggiornabilità
- Linked Table Manager
- Prestazioni e latenza
- VBA e DSN-less
- Sicurezza
- Troubleshooting
- Microsoft 365, Access 2024 e Runtime
- FAQ
Perché usare Azure SQL con Access
Un back-end Access tradizionale vive in un file .accdb, spesso su una condivisione di rete. Azure SQL è invece un servizio database gestito nel cloud. Spostare i dati su Azure SQL può migliorare disponibilità, gestione centralizzata, backup, sicurezza e accesso da sedi diverse, ma introduce latenza di rete e richiede una progettazione più attenta delle query.
Access resta installato sui PC Windows e comunica con Azure SQL tramite un driver ODBC. Per l’utente finale una tabella collegata può apparire simile a una tabella Access, ma dietro le quinte ogni lettura e scrittura attraversa la rete verso Azure.
Se lavori con SQL Server locale, consulta anche come collegare Access a SQL Server. Tutti gli approfondimenti sono nella categoria Guide Access.
Azure SQL Database o SQL Server su macchina virtuale?
Azure SQL Database è un servizio PaaS gestito. SQL Server installato su una VM Azure è più simile a un server SQL tradizionale che gestisci direttamente. Dal punto di vista Access entrambi possono essere raggiunti via ODBC, ma autenticazione, rete e amministrazione possono differire.
Questa guida si concentra soprattutto su Azure SQL Database. Se l’ambiente usa Managed Instance o una VM, verifica la documentazione specifica del servizio e la configurazione di rete.
Prerequisiti
Devi conoscere nome del server Azure SQL, nome del database, metodo di autenticazione e credenziali autorizzate. Sul PC serve un Microsoft ODBC Driver for SQL Server aggiornato e compatibile con l’architettura di Office.
Il server Azure SQL deve accettare la connessione dal client. In molti casi bisogna configurare le regole firewall del server per consentire l’indirizzo IP pubblico da cui si connette il PC o la rete aziendale. In ambienti più avanzati si possono usare private endpoint, VPN o reti integrate.
Firewall Azure SQL
Uno degli errori più comuni è avere credenziali corrette ma accesso di rete bloccato. Nel portale Azure controlla la sezione Networking del server logico e le regole firewall. Se usi un indirizzo IP pubblico dinamico, una regola che funziona oggi può non funzionare in futuro.
In azienda è preferibile una configurazione di rete stabile e gestita. Evita di aprire intervalli IP troppo ampi soltanto per far funzionare Access. Il principio deve essere concedere il minimo accesso necessario.
ODBC Driver for SQL Server
Usa una versione supportata del driver Microsoft ODBC. I driver recenti, come ODBC Driver 18, adottano impostazioni di crittografia moderne e possono richiedere certificati corretti. Non confondere l’architettura di Windows con quella di Office: un Windows 64 bit può avere Access 32 bit.
Se Access non vede un DSN o un driver, controlla l’architettura. Un DSN creato nell’amministratore ODBC 64 bit non è automaticamente disponibile a un Access 32 bit.
Autenticazione
Azure SQL può usare autenticazione SQL e modalità basate su Microsoft Entra ID, a seconda della configurazione e del driver. L’autenticazione SQL usa login/password definiti per il database/server. Le modalità Entra possono offrire una gestione più moderna delle identità e ridurre l’uso di password statiche, ma richiedono configurazione coerente.
Non inserire credenziali sensibili direttamente in codice VBA leggibile se puoi evitarlo. In un front-end distribuito considera sempre che gli utenti possono ispezionare il file in misura maggiore rispetto a un’applicazione server.
Come collegare Access ad Azure SQL passo passo
Apri Access e il database front-end. Vai su Dati esterni > Nuova origine dati > Da altre origini > Database ODBC. Scegli Collega all’origine dati creando una tabella collegata e conferma.
Nella finestra ODBC seleziona un DSN configurato per Azure SQL oppure creane uno. Inserisci il server nel formato previsto dal servizio, seleziona il database, configura autenticazione e crittografia e testa la connessione.
Quando Access ottiene l’elenco degli oggetti seleziona tabelle e viste da collegare. Conferma. Le tabelle collegate appariranno nel riquadro di spostamento, spesso con nomi derivati da schema e tabella, per esempio dbo_Clienti.
Importare invece di collegare
Il wizard permette anche di importare. In quel caso Access crea tabelle locali e i dati non restano sincronizzati. L’importazione è utile per snapshot, test o archivi, ma se Access deve essere il front-end operativo del database cloud usa il collegamento.
Chiave primaria e record aggiornabili
Access deve identificare univocamente le righe per poterle aggiornare. Le tabelle Azure SQL dovrebbero avere una primary key. Per una vista, Access può chiedere quali campi costituiscono una chiave univoca. Se non esiste una combinazione realmente univoca, non inventarla: modifica la vista o tratta il risultato come sola lettura.
Una vista con aggregazioni, GROUP BY o join complessi può essere non aggiornabile anche se contiene un campo univoco. Per maschere di inserimento usa tabelle o viste progettate specificamente per essere aggiornabili.
Linked Table Manager
Dopo una modifica di schema o cambio connessione usa Gestione tabelle collegate per aggiornare le tabelle. Microsoft segnala che la struttura di una tabella collegata non si modifica dal front-end: se devi aggiungere o cambiare colonne, fallo su Azure SQL e poi aggiorna il collegamento.
Lo stesso vale per tipi dati. Access mostra una rappresentazione compatibile, ma la definizione autorevole è sul server.
Prestazioni: la latenza conta
Con Azure SQL ogni query attraversa Internet o la rete privata. Una maschera progettata per un back-end .accdb locale può diventare lenta se apre migliaia di record. Il principio fondamentale è ridurre round-trip e volume dei dati.
Apri maschere già filtrate, usa WHERE su campi indicizzati, evita di caricare intere tabelle nelle combo, limita colonne e record. Se una query complessa può essere eseguita sul server, valuta viste o pass-through query.
Esempio: aprire solo gli ordini recenti
Invece di una query che restituisce tutti gli ordini, limita il periodo:
SELECT IDOrdine, IDCliente, DataOrdine, Totale FROM Ordini WHERE DataOrdine >= DateAdd("m",-3,Date());Access può tentare di tradurre il criterio verso ODBC, ma per massimo controllo puoi creare una vista server che filtra o usare T-SQL in una pass-through.
Query pass-through con Azure SQL
Una pass-through invia direttamente SQL al database Azure. È efficace per aggregazioni e stored procedure. Esempio T-SQL:
SELECT TOP (100) IDOrdine, DataOrdine, Totale FROM dbo.Ordini ORDER BY DataOrdine DESC;Access non interpreta la sintassi; il server esegue il comando. Questo riduce elaborazione locale e può migliorare molto le prestazioni.
Stored procedure
Se il progetto richiede logica complessa, puoi spostare elaborazioni sul server in stored procedure. Access può chiamarle tramite pass-through o ADO. Questa architettura è più robusta per aggiornamenti massivi rispetto a loop VBA che inviano un comando per ogni record.
Transazioni
Per operazioni critiche valuta transazioni lato server. SQL Server/Azure SQL garantisce proprietà transazionali, ma il front-end deve gestire errori e timeout. Non presumere che una serie di query Access separate sia automaticamente atomica sul server.
Sicurezza: non salvare password in chiaro
Microsoft avverte che il salvataggio di password nelle tabelle collegate può esporle nel database Access. Se usi autenticazione SQL, limita i privilegi e valuta meccanismi di autenticazione più sicuri. Un ACCDE protegge il design meglio di un ACCDB, ma non trasforma il front-end in un vault di segreti.
Encrypt e certificati
Azure SQL usa connessioni cifrate. Con driver recenti la verifica del certificato è una parte normale della sicurezza. Se ricevi errori, usa il nome server corretto e un driver aggiornato. Non impostare opzioni che bypassano la validazione senza comprenderne il rischio.
Timeout
Query lente possono generare timeout ODBC. Aumentare il timeout può essere utile per operazioni legittimamente lunghe, ma non deve sostituire l’ottimizzazione. Prima controlla indici, filtri e piano di esecuzione sul server.
VBA e connessioni DSN-less
In un’applicazione distribuita puoi aggiornare la proprietà Connect dei TableDef con una stringa ODBC e chiamare RefreshLink.
Dim tdf As DAO.TableDef: For Each tdf In CurrentDb.TableDefs: If Left$(tdf.Connect,5)="ODBC;" Then tdf.Connect=strAzure: tdf.RefreshLink: Next tdfLa stringa deve includere parametri corretti per driver, server, database e autenticazione. Non inserire password statiche nel codice se non strettamente necessario.
Gestire ambienti test e produzione
Non hard-code il server di produzione in decine di oggetti. Salva la configurazione in un punto centralizzato e crea una routine che ricollega tutte le tabelle in base all’ambiente. In sviluppo puoi usare un database Azure SQL di test con dati anonimi; in produzione usa il database reale.
Problema: Cannot open server requested by the login
Verifica che il login abbia accesso al database selezionato e che il nome database sia corretto. Se l’account esiste ma non è mappato correttamente, l’amministratore deve correggere utenti/ruoli.
Problema: client IP address is not allowed
È tipicamente un problema firewall Azure SQL. Aggiungi l’IP corretto secondo la policy aziendale o usa la rete privata prevista. Se l’IP cambia frequentemente, valuta una soluzione di rete stabile.
Problema: certificato non attendibile
Aggiorna il driver e verifica la configurazione TLS. Usa il nome DNS ufficiale del server. Non disattivare la validazione come prima soluzione.
Problema: tabella in sola lettura
Controlla primary key, permessi e tipo di oggetto. Una vista complessa può essere non aggiornabile. Prova direttamente una tabella semplice per distinguere un problema di permessi da uno di struttura.
Problema: Access è molto lento
Misura quante righe scarichi. Riduci RecordSource delle maschere, usa criteri sul server, crea viste, evita DLookup ripetuti su tabelle remote e sostituisci elaborazioni record-by-record con query set-based.
Microsoft 365 e Access 2024
Microsoft include Access per Microsoft 365 e Access 2024 nella documentazione della funzione Azure SQL. Il front-end resta un’applicazione Windows. Microsoft 365 riceve aggiornamenti frequenti, mentre Access 2024 segue il ciclo della versione perpetua; in entrambi i casi il driver ODBC è un componente esterno da mantenere aggiornato.
Access Runtime
Runtime può eseguire un front-end che usa Azure SQL. Assicurati però che il driver ODBC sia installato, che le tabelle vengano ricollegate automaticamente e che gli errori di rete siano gestiti. Un utente Runtime non dovrebbe dover configurare manualmente DSN o proprietà avanzate.
32/64 bit
Distribuisci driver coerenti con Office. Se l’azienda usa un mix di Access 32 e 64 bit, documenta chiaramente i prerequisiti o standardizza l’architettura per ridurre problemi.
Access non è una web app
Collegare il back-end ad Azure SQL non trasforma Access in un’applicazione Web. Le maschere e il codice Access continuano a girare sul PC Windows. Se serve un’interfaccia browser o mobile, occorre sviluppare un’applicazione separata che acceda allo stesso database con le opportune API e regole di sicurezza.
Checklist
Controlla: server e database corretti, firewall, driver ODBC, architettura Office, metodo di autenticazione, crittografia, permessi, primary key, aggiornabilità delle viste, indici, latenza, filtri nelle maschere, timeout, gestione errori e strategia di ricollegamento.
FAQ
Access può collegarsi direttamente ad Azure SQL?
Sì, tramite ODBC e le modalità di autenticazione supportate dal driver e dalla configurazione Azure SQL.
I dati vengono copiati in Access?
Non con il collegamento. Restano in Azure SQL. Se scegli Importa, invece, viene creata una copia locale.
Serve un IP nel firewall?
In una configurazione con endpoint pubblico, normalmente il server deve consentire la rete/IP del client. Con private endpoint la logica di rete è differente.
Posso usare Microsoft Entra ID?
Sì in configurazioni compatibili, usando driver e modalità di autenticazione supportate. Verifica le policy dell’ambiente.
Le maschere Access funzionano?
Sì, possono usare tabelle e query basate su Azure SQL, ma devono essere progettate per limitare il traffico e gestire latenza/errori.
Access Runtime funziona?
Sì, se il front-end è stato progettato e distribuito con driver, connessioni e gestione errori corretti.
Posso usare Access su Mac?
Non nativamente. Microsoft Access desktop è disponibile per Windows; un utente Mac deve usare un ambiente Windows remoto o virtuale.
Conclusione
Collegare Azure SQL ad Access consente di modernizzare il back-end mantenendo il front-end Access, ma richiede più attenzione rispetto a un semplice file .accdb condiviso. Firewall, autenticazione, driver, certificati, chiavi e performance devono essere progettati come parti della stessa soluzione. Se filtri i dati sul server, mantieni driver aggiornati e centralizzi il ricollegamento, Access può essere un front-end efficace anche con un database Azure SQL.
Approfondisci con come collegare Access a SQL Server, come importare dati da SQL Server in Access e la categoria Guide Access.