Eseguire la migrazione di un database di Access a SQL Server

Eseguire la migrazione di un database di Access a SQL Server

Tutti hanno dei limiti e un database di Access non fa eccezione. Ad esempio, un database di Access ha un limite di dimensioni di 2 GB e non può supportare più di 255 utenti simultanei. Quando è il momento di passare al livello successivo del database di Access, è quindi possibile eseguire la migrazione a SQL Server. SQL Server (in locale o nel cloud Azure) supporta grandi quantità di dati, più utenti simultanei e una capacità maggiore rispetto al motore di database JET/ACE. Questa guida consente di iniziare il percorso di SQL Server, di conservare le soluzioni front-end di Access create e, si spera, di motivare l'uso di Access per soluzioni di database future. L'Upsize guidato è stata rimossa da Access in Access 2013, quindi ora è possibile usare l'Assistente migrazione Microsoft SQL Server migrazione rapida (SSMA). Per eseguire correttamente la migrazione, seguire queste fasi.

Le fasi della migrazione dei database a SQL Server

Prima di iniziare

Le sezioni seguenti forniscono informazioni generali e altre informazioni utili per iniziare.

Informazioni sui database divisi

Tutti gli oggetti di database di Access possono essere contenuti in un unico file di database oppure possono essere archiviati in due file di database: un database front-end e un database back-end. Questa operazione è detta divisione del database ed è progettata per facilitare la condivisione in un ambiente di rete. Il file di database back-end deve contenere solo tabelle e relazioni. Il file front-end deve contenere solo tutti gli altri oggetti, inclusi maschere, report, query, macro, moduli VBA e tabelle collegate al database back-end. Quando si esegue la migrazione di un database di Access, è simile a un database diviso in questo SQL Server funge da nuovo back-end per i dati che ora si trovano in un server.

Di conseguenza, è comunque possibile mantenere il database front-end di Access con le tabelle collegate alle SQL Server tabella. In modo efficace, è possibile ricavare i vantaggi del rapido sviluppo di applicazioni fornito da un database di Access, insieme alla scalabilità SQL Server.

SQL Server vantaggi

La migrazione a un'SQL Server non è SQL Server? Ecco alcuni altri vantaggi da pensare:

  • Altri utenti simultanei    SQL Server possibile gestire molti più utenti simultanei rispetto ad Access e ridurre al minimo i requisiti di memoria quando vengono aggiunti più utenti.

  • Maggiore disponibilità    Con SQL Server, è possibile eseguire il backup dinamico del database, incrementale o completo, mentre è in uso. Di conseguenza, non è necessario imporre agli utenti di disconnettersi dal database per eseguire il backup dei dati.

  • Prestazioni e scalabilità elevate    Il SQL Server di solito offre prestazioni migliori rispetto a un database di Access, in particolare con un database di grandi dimensioni terabyte. Inoltre, SQL Server elabora le query in modo molto più rapido ed efficiente elaborando le query in parallelo, usando più thread nativi all'interno di un singolo processo per gestire le richieste degli utenti.

  • Maggiore sicurezza    Usando una connessione di tipo trusted, SQL Server si integra con la sicurezza del sistema Windows per offrire un unico accesso integrato alla rete e al database, avvalendo del meglio di entrambi i sistemi di sicurezza. In questo modo risulta molto più semplice amministrare schemi di sicurezza complessi. SQL Server rappresenta lo spazio di archiviazione ideale per informazioni riservate come numeri di previdenza sociale, dati della carta di credito e indirizzi riservati.

  • Reversibilità immediata     Se il sistema operativo si arresta in modo anomalo o l'alimentazione si arresta, SQL Server possibile ripristinare automaticamente lo stato coerente del database dopo pochi minuti e senza alcun intervento dell'amministratore del database.

  • Uso della RETE VPN    L'accesso e le reti private virtuali (VPN) non sono sempre d'accordo. Tuttavia, SQL Server, gli utenti remoti possono usare comunque il database front-end di Access su un desktop e il SQL Server back-end dietro il firewall VPN.

  • Azure SQL Server    Oltre ai vantaggi di SQL Server, offre scalabilità dinamica senza tempi di inattività, ottimizzazione intelligente, scalabilità e disponibilità globali, eliminazione dei costi hardware e amministrazione ridotta.

Scegliere l'opzione più adatta per SQL Server Azure

Se si esegue la migrazione ad Azure SQL Server, è possibile scegliere tra tre opzioni, ognuna con diversi vantaggi:

  • Pool di database singoli/elastici    Questa opzione ha un set di risorse personalizzato gestito tramite un server di SQL database. Un singolo database è simile a un database contenuto in SQL Server. È anche possibile aggiungere un pool flessibile, ovvero una raccolta di database con un set condiviso di risorse gestite tramite il server di SQL database. Le caratteristiche di SQL Server sono disponibili con backup incorporati, applicazione di patch e ripristino. Tuttavia, non esiste alcun tempo di manutenzione esatto garantito e la migrazione da SQL Server potrebbe essere difficile.

  • Istanza gestita    Questa opzione è una raccolta di database di sistema e utenti con un set di risorse condiviso. Un'istanza gestita è come un'istanza del database SQL Server che è altamente compatibile con SQL Server locale. Un'istanza gestita include backup incorporati, applicazione di patch, ripristino ed è facile eseguire la migrazione da SQL Server. Sono tuttavia disponibili un numero limitato di SQL Server caratteristiche non disponibili e non vengono garantiti tempi di manutenzione esatti garantiti.

  • Macchina virtuale di Azure    Questa opzione consente di eseguire SQL Server all'interno di una macchina virtuale nel cloud Azure. Si ha il controllo completo sul motore SQL Server e un percorso di migrazione semplice. Tuttavia, è necessario gestire i backup, le patch e il ripristino.

Per altre informazioni, vedere Scelta del percorso di migrazione del database in Azure e Scegliere l'opzione di migrazione SQL Server in Azure.

Primi passi

Esistono alcuni problemi che è possibile risolvere in anticipo per semplificare il processo di migrazione prima di eseguire SSMA:

  • Aggiungere indici di tabella e chiavi primarie    Verificare che ogni tabella di Access abbia un indice e una chiave primaria. SQL Server che a tutte le tabelle sia associato almeno un indice e che una tabella collegata abbia una chiave primaria, se può essere aggiornata.

  • Controllare le relazioni tra chiave primaria/chiave esterna    Verificare che queste relazioni siano basate su campi con dimensioni e tipi di dati coerenti. SQL Server non supporta le colonne unite con dimensioni e tipi di dati diversi nei vincoli di chiave esterna.

  • Rimuovere la colonna Allegato    SSMA non esegue la migrazione delle tabelle che contengono la colonna Allegato.

Prima di eseguire SSMA, procedere come segue.

  1. Chiudere il database di Access.

  2. Assicurarsi che gli utenti correnti connessi al database chiudono anche il database.

  3. Se il database è nel formato di file mdb,rimuovere la sicurezza a livello utente.

  4. Eseguire il backup del database. Per altre informazioni, vedere Proteggere i dati con i processi di backup e ripristino.

Suggerimento    È consigliabile installare Microsoft SQL Server Express Edition sul desktop che supporta fino a 10 GB ed è un modo gratuito e più semplice per eseguire e controllare la migrazione. Quando ci si connette, usare DatabaseB Locale come istanza del database.

Suggerimento    Se possibile, usare una versione autonoma di Access. Se è possibile usare solo Microsoft 365, usare il motore di database di Access 2010 per eseguire la migrazione del database di Access quando si usa SSMA. Per altre informazioni, vedere Microsoft Access Database Engine 2010 Redistributable.

Eseguire SSMA

Microsoft fornisce Microsoft SQL Server migrazione guidata per semplificare la migrazione. SSMA esegue principalmente la migrazione delle tabelle e delle query di selezione senza parametri. Maschere, report, macro e moduli VBA non vengono convertiti. La SQL Server Metadati esterni consente di visualizzare gli oggetti di database e gli SQL Server di Access, consentendo di esaminare il contenuto corrente di entrambi i database. Queste due connessioni vengono salvate nel file di migrazione se si decide di trasferire altri oggetti in futuro.

Nota    Il processo di migrazione può richiedere del tempo a seconda delle dimensioni degli oggetti di database e della quantità di dati che è necessario trasferire.

  1. Per eseguire la migrazione di un database con SSMA, scaricare e installare il software facendo doppio clic sul file MSI scaricato. Assicurarsi di installare la versione a 32 o 64 bit appropriata per il computer.

  2. Dopo aver installato SSMA, aprirlo sul desktop, preferibilmente dal computer con il file di database di Access.

    È anche possibile aprirlo in un computer che ha accesso al database di Access dalla rete in una cartella condivisa.

  3. Seguire le istruzioni di base in SSMA per fornire informazioni di base, ad esempio il percorso del SQL Server, il database e gli oggetti di Access di cui eseguire la migrazione, le informazioni di connessione e se si vogliono creare tabelle collegate.

  4. Se si esegue la migrazione a SQL Server 2016 o versione successiva e si vuole aggiornare una tabella collegata, aggiungere una colonna rowversion selezionando Strumenti di revisione > Impostazioni progetto >Generale.

    Il campo rowversion consente di evitare conflitti tra record. Access usa questo campo rowversion in una SQL Server collegata per determinare quando è stato aggiornato il record. Inoltre, se si aggiunge il campo rowversion a una query, Access lo usa per selezionare di nuovo la riga dopo un'operazione di aggiornamento. Questo migliora l'efficienza evitando errori di scrittura in conflitto ed scenari di eliminazione dei record che possono verificarsi quando Access rileva risultati diversi dall'invio originale, ad esempio potrebbero verificarsi con tipi di dati numerici a virgola mobile e trigger che modificano le colonne. Evitare tuttavia di usare il campo rowversion in maschere, report o codice VBA. Per altre informazioni, vedere rowversion.

    Nota    Evitare di confondere rowversion con timestamp. Anche se la parola chiave timestamp è un sinonimo di rowversion in SQL Server, non è possibile usare rowversion come indicatore di data e ora per un'immissione di dati.

  5. Per impostare tipi di dati precisi, selezionare Strumenti di revisione >Impostazioni progetto > mapping tipi. Ad esempio, se si archivia solo testo inglese, è possibile usare il tipo di dati varchar invece di nvarchar.

Convertire oggetti

SSMA converte gli oggetti di Access SQL Server oggetti personalizzati, ma non copia immediatamente gli oggetti. SSMA fornisce un elenco degli oggetti seguenti di cui eseguire la migrazione, in modo da decidere se spostarli nel SQL Server database:

  • Tabelle e colonne

  • Selezionare query senza parametri.

  • Chiavi primarie ed esterne

  • Indici e valori predefiniti

  • Vincoli check (proprietà colonna lunghezza zero, regola di convalida colonna, convalida tabella)

Come procedura consigliata, usare il report di valutazione SSMA, che mostra i risultati della conversione, inclusi errori, avvisi, messaggi informativi, stime del tempo per l'esecuzione della migrazione e singoli passaggi di correzione degli errori da eseguire prima di spostare effettivamente gli oggetti.

La conversione di oggetti di database accetta le definizioni degli oggetti dai metadati di Access, le converte in sintassi Transact-SQL (T-SQL)equivalente e quindi carica queste informazioni nel progetto. È quindi possibile visualizzare gli oggetti SQL Server o SQL Azure e le relative proprietà usando SQL Server metadati SQL Azure metadati.

Per convertire, caricare ed eseguire la migrazione di oggetti SQL Server, seguire questa guida.

Suggerimento    Dopo aver completato la migrazione del database di Access, salvare il file di progetto per un uso futuro, in modo da poter eseguire di nuovo la migrazione dei dati per il test o la migrazione finale.

Collegare tabelle

È consigliabile installare l'ultima versione del SQL Server driver OLE DB e ODBC invece di usare i driver SQL Server nativi forniti con Windows. Non solo i driver più recenti sono più veloci, ma supportano le nuove funzionalità di Azure SQL non lo sono invece i driver precedenti. È possibile installare i driver in ogni computer in cui viene usato il database convertito. Per altre informazioni, vedere Microsoft OLE DB Driver 18 for SQL Server e Microsoft ODBC Driver 17 per SQL Server.

Dopo aver eseguito la migrazione delle tabelle di Access, è possibile collegarsi alle tabelle di SQL Server che ora ospitano i dati. Il collegamento direttamente da Access consente inoltre di visualizzare i dati in modo più semplice, anziché usare quelli più complessi SQL Server gestione dati.  È possibile eseguire query e modificare i dati collegati in base alle autorizzazioni impostate dall'amministratore SQL Server database.

Nota    Se si crea un DSN ODBC quando si esegue il collegamento al database di SQL Server durante il processo di collegamento, creare lo stesso DSN in tutti i computer che usano la nuova applicazione oppure usare a livello di programmazione la stringa di connessione archiviata nel file DSN.

Per altre informazioni, vedere Collegare o importare dati da un database di Azure SQL Server e Importare o collegare dati in un database SQL Server.

Suggerimento   Non dimenticare di usare Gestione tabelle collegate in Access per aggiornare e ricollegare le tabelle in modo comodo. Per altre informazioni, vedere Gestire le tabelle collegate.

Testare e rivedere

Le sezioni seguenti descrivono i problemi comuni che possono verificarsi durante la migrazione e come trattarli.

Query

Vengono convertite solo le query di selezione; non lo sono altre query, incluse le query di selezione che accettano parametri. Alcune query potrebbero non essere completamente convertite e SSMA segnala gli errori di query durante il processo di conversione. È possibile modificare manualmente gli oggetti che non vengono convertiti usando la sintassi T-SQL testo. Gli errori di sintassi possono richiedere anche la conversione manuale di funzioni e tipi di dati specifici di Access SQL Server quelli predefiniti. Per ulteriori informazioni, vedere Confronto tra SQL per Access e T-SQL per SQL Server.

Tipi di dati

Access e SQL Server hanno tipi di dati simili, ma è necessario tenere presenti i potenziali problemi seguenti.

Numero grande    Il tipo di dati Numero grande archivia un valore numerico non monetario ed è compatibile con il SQL di dati bigint. È possibile usare questo tipo di dati per calcolare in modo efficiente i numeri grandi, ma è necessario usare il formato di file di database accdb di Access 16 (16.0.7812 o versioni successive) e ottenere prestazioni migliori con la versione a 64 bit di Access. Per altre informazioni, vedere Uso del tipo di dati Numero grande e Scegliere tra la versione a 64 bit o a 32 bit di Office.

Sì/No    Per impostazione predefinita, una colonna Sì/No di Access viene convertita in un SQL Server di bit. Per evitare il blocco dei record, assicurarsi che il campo di bit sia impostato in modo da non consentire i valori NULL. In SSMA è possibile selezionare la colonna di bit per impostare la proprietà Consenti valori Null su NO. In TSQL usare le istruzioni CREATE TABLE o ALTER TABLE.

Data e ora    Sono da tenere presenti diverse considerazioni relative a data e ora:

  • Se il livello di compatibilità del database è 130 (SQL Server 2016) o versione successiva e una tabella collegata contiene una o più colonne datetime o datetime2, la tabella potrebbe restituire il messaggio #deleted nei risultati. Per altre informazioni, vedere la tabella collegata di Access SQL-Server database restituisce #deleted.

  • Usare il tipo di dati Data/ora di Access per eseguire il mapping al tipo di dati datetime. Usare il tipo di dati Data/ora estesa di Access per eseguire il mapping al tipo di dati datetime2, che ha un intervallo di date e ore più esteso. Per altre informazioni, vedere Uso del tipo di dati Data/ora estesa.

  • Quando si esegue una query per SQL Server data, prendere in considerazione l'ora e la data. Ad esempio:

    • DateOrdered Between 1/1/19 and 31/1/19 may not include all orders.

    • DateOrdered Between 1/1/19 00:00:00 AM And 31/1/19 11:59:59 PM does include all orders.

Allegato   Il tipo di dati Allegato archivia un file in un database di Access. In SQL Server, sono disponibili diverse opzioni. È possibile estrarre i file dal database di Access e quindi archiviare i collegamenti ai file nel database SQL Server database. In alternativa, è possibile usare FILESTREAM, FileTable o RBS (Remote BLOB Store) per mantenere gli allegati archiviati nel SQL Server database.

Collegamento ipertestuale    Le tabelle di Access hanno colonne di collegamenti ipertestuali SQL Server non supportano. Per impostazione predefinita, queste colonne verranno convertite in colonne nvarchar(max) in SQL Server, ma è possibile personalizzare il mapping per scegliere un tipo di dati più piccolo. Nella soluzione di Access è comunque possibile usare il comportamento del collegamento ipertestuale nelle maschere e nei report se si imposta la proprietà Collegamento ipertestuale per il controllo su true.

Multivalore    Il campo multivalore di Access viene convertito in un SQL Server come campo ntext che contiene il set di valori delimitato. Poiché SQL Server non supporta un tipo di dati multivalore che dà corpo a una relazione molti-a-molti, potrebbero essere necessarie operazioni aggiuntive di progettazione e conversione.

Per altre informazioni sul mapping dei tipi di dati di Access SQL Server dati personalizzati, vedere Confrontare i tipi di dati.

Nota    I campi multivalore non vengono convertiti e non sono più disponibili in Access 2010.

Per altre informazioni, vedere i tipi di data e ora,i tipi stringa e binarioe i tipi numerici.

Visual Basic

Anche se VBA non è supportato SQL Server, tenere presente i possibili problemi seguenti:

Funzioni VBA nelle query    Le query di Access supportano le funzioni VBA sui dati in una colonna di query. Tuttavia, le query di Access che usano funzioni VBA non possono essere eseguite SQL Server, quindi tutti i dati richiesti vengono passati a Microsoft Access per l'elaborazione. Nella maggior parte dei casi, queste query devono essere convertite in query pass-through.

Funzioni definite dall'utente nelle query    Le query di Microsoft Access supportano l'uso di funzioni definite nei moduli VBA per elaborare i dati passati. Le query possono essere query autonome, SQL nelle origini record di maschere/report, origini dati di caselle combinate e caselle di riepilogo in maschere, report e campi di tabella e espressioni di regole di convalida o predefinite. SQL Server possibile eseguire queste funzioni definite dall'utente. Potrebbe essere necessario riprogettare manualmente queste funzioni e convertirle in stored procedure in SQL Server.

Ottimizzare le prestazioni

Il modo più importante per ottimizzare le prestazioni con i nuovi SQL Server back-end è decidere quando usare le query locali o remote. Quando si esegue la migrazione dei dati a SQL Server, si sta anche passando da un file server a un modello di database client-server di computer. Seguire queste linee guida generali:

  • Esegui piccole query di sola lettura nel client per accedervi più rapidamente.

  • Eseguire query lunghe e di lettura/scrittura nel server per sfruttare una maggiore potenza di elaborazione.

  • Ridurre al minimo il traffico di rete con filtri e aggregazione per trasferire solo i dati necessari.

Ottimizzare le prestazioni nel modello di database del server client

Per altre informazioni, vedere Creare una query pass-through.

Di seguito sono riportate altre linee guida consigliate.

Inserire la logica nel server     L'applicazione può anche usare visualizzazioni, funzioni definite dall'utente, stored procedure, campi calcolati e trigger per centralizzare e condividere logica dell'applicazione, regole e criteri di business, query complesse, convalida dei dati e codice di integrità referenziale sul server, invece che sul client. Ci si può chiedere se questa query o attività può essere eseguita nel server in modo migliore e veloce? Infine, testare ogni query per garantire prestazioni ottimali.

Usare le visualizzazioni in maschere e report    In Access eseguire le operazioni seguenti:

  • Per le maschere, usare una SQL di lettura per una maschera di sola lettura e una visualizzazione indicizzata di SQL per una maschera di lettura/scrittura come origine record.

  • Per i report, usare una SQL report come origine record. Tuttavia, creare una visualizzazione separata per ogni report, in modo da aggiornare più facilmente un report specifico, senza influire sugli altri report.

Ridurre al minimo il caricamento dei dati in una maschera o un report    Non visualizzare i dati finché l'utente non lo richiede. Ad esempio, mantenere vuota la proprietà origine record, fare in modo che gli utenti controllino un filtro nella maschera e quindi popolano la proprietà origine record con il filtro. In caso contrario, usare la clausola where di DoCmd.OpenForm e DoCmd.OpenReport per visualizzare i record esatti necessari all'utente. È consigliabile disattivare lo spostamento tra record.

Prestare attenzione alle query eterogene   Evitare di eseguire una query che combina una tabella di Access locale SQL Server collegata, detta anche query ibrida. Questo tipo di query richiede comunque ad Access di scaricare tutti i dati di SQL Server nel computer locale e quindi eseguire la query, ma non esegue la query in SQL Server.

Quando usare le tabelle locali    È consigliabile usare tabelle locali per i dati che vengono modificati raramente, ad esempio l'elenco di stati o province di un paese o di un'area geografica. Le tabelle statiche vengono spesso usate per filtrare i dati e possono avere prestazioni migliori sul front-end di Access.

Per altre informazioni, vedere Ottimizzazione guidata motore di database, Usare Analizzatore prestazioni per ottimizzare un database di Accesse Ottimizzare Microsoft Office applicazioni access collegate a SQL Server.

Vedere anche

Guida alla migrazione dei database di Azure

Blog sulla migrazione dei dati Microsoft

Microsoft Access per SQL Server migrazione, conversione e upsize

Metodi per condividere un database desktop utilizzando SharePoint

Serve aiuto?

Amplia le tue competenze su Office
Esplora i corsi di formazione
Ottieni in anticipo le nuove caratteristiche
Partecipa al programma Office Insider

Queste informazioni sono risultate utili?

×