Eseguire la migrazione di un database di Access a SQL Server

Eseguire la migrazione di un database di Access a SQL Server

Tutti abbiamo 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. Quindi, quando è il momento per il database di Access di passare al livello successivo, è possibile eseguire la migrazione a SQL Server. SQL Server (sia in locale che in Azure cloud) supporta più grandi quantità di dati, più utenti simultanei e ha una maggiore capacità rispetto al motore di database JET/ACE. Questa guida offre un buon inizio per il viaggio in SQL Server, consente di mantenere le soluzioni di Access front-end create e, auspicabilmente, motiva l'uso di Access per future soluzioni di database. L'Upsize guidato è stato rimosso da Access in Access 2013, quindi ora è possibile usare l'assistente per la migrazione a Microsoft SQL Server (SSMA). Per eseguire correttamente la migrazione, seguire queste fasi.

Fasi della migrazione del database a SQL Server

Prima di iniziare

Nelle sezioni seguenti sono disponibili informazioni sullo sfondo e altre indicazioni utili per iniziare.

Informazioni sui database divisi

Tutti gli oggetti di database di Access possono trovarsi 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 si chiama suddivisione 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 moduli, report, query, macro, moduli VBA e tabelle collegate nel database back-end. Quando si esegue la migrazione di un database di Access, è simile a un database diviso in quanto SQL Server funge da nuovo back-end per i dati che ora si trovano in un server.

Di conseguenza, è comunque possibile gestire il database di Access front-end con le tabelle collegate alle tabelle di SQL Server. In effetti, puoi derivare i vantaggi dello sviluppo rapido delle applicazioni che un database di Access offre, insieme alla scalabilità di SQL Server.

Vantaggi per SQL Server

È ancora necessario qualche convincente per eseguire la migrazione a SQL Server? Ecco alcuni vantaggi aggiuntivi da considerare:

  • Altri utenti simultanei    SQL Server è in grado di gestire molti più utenti simultanei di Access e minimizza i requisiti di memoria quando vengono aggiunti altri utenti.

  • Maggiore disponibilità    Con SQL Server è possibile eseguire il backup dinamico, incrementale o completo, del database 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 database di SQL Server in genere viene eseguito meglio rispetto a un database di Access, in particolare con un database di dimensioni terabyte. Inoltre, SQL Server elabora le query in modo molto più rapido ed efficiente elaborando query in parallelo, usando più thread nativi all'interno di un singolo processo per gestire le richieste degli utenti.

  • Sicurezza migliorata    Usando una connessione attendibile, SQL Server si integra con la sicurezza del sistema Windows per garantire un singolo accesso integrato alla rete e al database, sfruttando al meglio entrambi i sistemi di sicurezza. In questo modo è molto più semplice amministrare schemi di sicurezza complessi. SQL Server è lo spazio di archiviazione ideale per informazioni riservate, ad esempio numeri di previdenza sociale, dati della carta di credito e indirizzi riservati.

  • Recupero immediato    Se il sistema operativo si arresta in modo anomalo o si spegne l'alimentazione, SQL Server può recuperare automaticamente il database in uno stato coerente in pochi minuti e senza alcun intervento di amministratore del database.

  • Uso della VPN    Accesso e reti private virtuali (VPN) non andare d'accordo. Ma con SQL Server, gli utenti remoti possono usare ancora il database front-end di Access su un desktop e il back-end di SQL Server situato dietro il firewall VPN.

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

Scegliere l'opzione di SQL Server di Azure migliore

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

  • Database singolo/pool elastici    Questa opzione include un set di risorse personalizzato gestito tramite un server di database SQL. Un singolo database è simile a un database indipendente in SQL Server. È anche possibile aggiungere un pool elastico, ovvero una raccolta di database con un insieme condiviso di risorse gestite tramite il server di database SQL. Le funzionalità di SQL Server usate più di frequente sono disponibili con backup predefiniti, patch e ripristino. Ma non è garantito il tempo di manutenzione esatto 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 è simile a un'istanza del database di SQL Server che è altamente compatibile con SQL Server locale. Un'istanza gestita include backup predefiniti, patch, ripristino ed è facile da eseguire la migrazione da SQL Server. Esiste tuttavia un numero limitato di funzionalità di SQL Server che non sono disponibili e non garantiscono un tempo di manutenzione esatto.

  • Macchina virtuale di Azure    Questa opzione consente di eseguire SQL Server all'interno di una macchina virtuale in Azure cloud. Si ha il controllo completo sul motore di SQL Server e su un percorso di migrazione semplice. Ma devi 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 SQL Server appropriata in Azure.

Primi passaggi

Ci sono alcuni problemi che possono essere affrontati 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 richiede a tutte le tabelle di avere almeno un indice e richiede una tabella collegata per avere una chiave primaria, se la tabella può essere aggiornata.

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

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

Prima di eseguire SSMA, seguire i primi passaggi seguenti.

  1. Chiudere il database di Access.

  2. Verificare che gli utenti correnti connessi al database chiudano anche il database.

  3. Se il database è in formato di file mdb, rimuovere la sicurezza a livello di 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 semplice e gratuito per l'esecuzione e la verifica della migrazione. Quando ci si connette, usare il database locale come istanza

Suggerimento    Se possibile, usare una versione autonoma di Access. Se è possibile usare solo Office 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 motore di database di Microsoft Access 2010ridistribuibile.

Eseguire SSMA

Microsoft fornisce l'assistente per la migrazione a Microsoft SQL Server (SSMA) per semplificare la migrazione. SSMA esegue principalmente la migrazione delle tabelle e seleziona query senza parametri. Le maschere, i report, le macro e i moduli VBA non vengono convertiti. SQL Server Metadata Explorer visualizza gli oggetti di database di Access e gli oggetti di SQL Server che consentono 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 deve essere trasferita.

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

  2. Dopo l'installazione di SSMA, aprirlo sul desktop, preferibilmente dal computer con il file di database di Access.

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

  3. Seguire le istruzioni per l'inizio in SSMA per ottenere informazioni di base, ad esempio la posizione di SQL Server, il database di Access e gli oggetti da migrare, 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 revisione > Impostazioni progetto > generale.

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

    Nota    Evitare di confondere rowversion con timestamp. Anche se la parola chiave timestamp è sinonimo di rowversion in SQL Server, non è possibile usare rowversion come metodo per l'immissione di dati timestamp.

  5. Per impostare tipi di dati precisi, selezionare strumenti revisione > Impostazioni progetto > Mapping tipi. Ad esempio, se memorizzi solo il testo in inglese, puoi usare il tipo di dati varchar invece di nvarchar .

Convertire oggetti

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

  • Tabelle e colonne

  • Selezionare query senza parametri.

  • Chiavi primarie ed esterne

  • Indici e valori predefiniti

  • Vincoli check (Consenti proprietà colonna a lunghezza zero, regola di convalida delle colonne, convalida tabella)

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

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

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

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

Collegare tabelle

È consigliabile installare la versione più recente dei driver OLE DB e ODBC di SQL Server invece di usare i driver di SQL Server nativi forniti con Windows. I driver più recenti non solo sono più veloci, ma supportano le nuove funzionalità di Azure SQL che i driver precedenti non hanno. È possibile installare i driver in ogni computer in cui viene usato il database convertito. Per altre informazioni, vedere driver Microsoft OLE DB 18 per SQL Server e Microsoft ODBC driver 17 per SQL Server.

Dopo la migrazione delle tabelle di Access, è possibile creare un collegamento alle tabelle in SQL Server che ora ospitano i dati. Il collegamento direttamente da Access offre anche un modo più semplice per visualizzare i dati, invece di usare gli strumenti di gestione di SQL Server più complessi.  È possibile eseguire query e modificare dati collegati a seconda delle autorizzazioni configurate dall'amministratore di database di SQL Server.

Nota    Se si crea un DSN ODBC quando si collega al database di SQL Server durante il processo di collegamento, creare lo stesso DSN in tutti i computer che usano la nuova applicazione o usare a livello di codice 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 di SQL Server.

Suggerimento   Non dimenticare di usare la gestione tabelle collegate in Access per aggiornare e riconnettere le tabelle in modo conveniente. Per altre informazioni, vedere gestire le tabelle collegate.

Testare e rivedere

Nelle sezioni seguenti vengono descritti i problemi comuni che possono verificarsi durante la migrazione e come gestirli.

Query

Solo le query di selezione vengono convertite; altre query non sono, 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. Puoi modificare manualmente gli oggetti che non vengono convertiti usando la sintassi T-SQL. Gli errori di sintassi possono anche richiedere la conversione manuale di funzioni e tipi di dati specifici di Access in SQL Server. Per altre informazioni, vedere confronto tra SQL di Access e SQL Server TSQL.

Tipi di dati

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

Numero grande    Il tipo di dati numero grande archivia un valore numerico non monetario ed è compatibile con il tipo di dati bigint SQL. Puoi usare questo tipo di dati per calcolare in modo efficiente i numeri grandi, ma richiede l'uso del formato di file di database ACCDB di Access 16 (16.0.7812 o versione successiva) e le 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 di Office 64 bit o 32 bit.

Sì/No    Per impostazione predefinita, una colonna di Access Sì/No viene convertita in un campo di bit di SQL Server. Per evitare il blocco del record, Verificare che il campo bit sia impostato su non consentire valori NULL. IN SSMA è possibile selezionare la colonna bit per impostare la proprietà Consenti valori null su No. In TSQL usare le istruzioni Create Table o ALTER TABLE .

Data e ora    Sono disponibili diverse considerazioni su 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 per il database SQL-Server restituisce #deleted.

  • Usa il tipo di dati datetime2 che ha un intervallo di date più grande rispetto a DateTime.

  • Quando si esegue una query per date in SQL Server, tenere conto del tempo e della data. Ad esempio:

    • DateOrdered tra 1/1/19 e 1/31/19 potrebbe non includere tutti gli ordini.

    • DateOrdered tra 1/1/19 00:00:00 AM e 1/31/19 11:59:59 PM include tutti gli ordini.

Allegato   Il tipo di dati allegato archivia un file nel database di Access. In SQL Server sono disponibili diverse opzioni da prendere in considerazione. È possibile estrarre i file dal database di Access e quindi considerare l'archiviazione dei collegamenti ai file del database di SQL Server. In alternativa, è possibile usare FILESTREAM, DataTable o archiviazione BLOB remoti per conservare gli allegati archiviati nel database di SQL Server.

Collegamento ipertestuale    Le tabelle di Access presentano colonne hyperlink non supportate da SQL Server. 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 dei collegamenti ipertestuali nelle maschere e nei report se si imposta la proprietà Hyperlink per il controllo su true.

Campo multivalore    Il campo multivalore di Access viene convertito in 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 e SQL Server, vedere confrontare tipi di dati.

Nota    I campi multivalore non vengono convertiti e sono stati interrotti in Access 2010.

Per altre informazioni, Vedi tipi di data e ora, tipi di stringa e binarie tipi numerici.

Visual Basic

Sebbene VBA non sia supportato da 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 in 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 delle funzioni definite nei moduli VBA per l'elaborazione dei dati passati. Le query possono essere query autonome, istruzioni SQL nelle origini record di maschere/report, origini dati di caselle combinate e caselle di riepilogo su maschere, report e campi di tabella e espressioni di regole predefinite o di convalida. SQL Server non può eseguire queste funzioni definite dall'utente. Potrebbe essere necessario riprogettare manualmente queste funzioni e convertirle in stored procedure in SQL Server.

Ottimizzare le prestazioni

Di gran lunga, il modo più importante per ottimizzare le prestazioni con il nuovo SQL Server back-end consiste nel decidere quando usare le query locali o remote. Quando si esegue la migrazione dei dati in SQL Server, si passa anche da un file server a un modello di database client-server di calcolo. Seguire queste linee guida generali:

  • Eseguire piccole query di sola lettura sul client per l'accesso più rapido.

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

  • Ridurre al minimo il traffico di rete con filtri e aggregazioni 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 le linee guida aggiuntive consigliate.

Inserire la logica nel server    L'applicazione può anche usare le visualizzazioni, le funzioni definite dall'utente, le stored procedure, i campi calcolati e i trigger per centralizzare e condividere la logica dell'applicazione, le regole e i criteri aziendali, le query complesse, la convalida dei dati e il codice di integrità referenziale nella Server, invece che nel client. Chiedersi, è possibile eseguire questa query o un'attività sul server in modo migliore e veloce? Infine, prova ogni query per garantire prestazioni ottimali.

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

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

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

Ridurre a icona il caricamento dei dati in una maschera o in un report    Non visualizzare i dati fino a quando l'utente non lo richiede. Ad esempio, Mantieni vuota la proprietà origine record, imposta gli utenti nel modulo per selezionare un filtro e quindi popola la proprietà origine record con il filtro. In alternativa, usare la clausola WHERE di DoCmd. ApriMaschera e DoCmd. ApriReport per visualizzare i record esatti necessari per l'utente. Valutare la possibilità di disattivare la struttura di spostamento record.

Prestare attenzione alle query eterogenee   Evitare di eseguire una query che combina una tabella di Access locale e una tabella collegata di SQL Server, talvolta denominata query ibrida. Questo tipo di query richiede ancora l'accesso per 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 le tabelle locali per i dati raramente modificati, ad esempio l'elenco di Stati o province in un paese o in un'area geografica. Le tabelle statiche vengono spesso usate per filtrare e possono essere migliorate per il front-end di Access.

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

Vedere anche

Guida alla migrazione a database di Azure

Blog di migrazione dati Microsoft

Microsoft Access alla migrazione, alla conversione e al ridimensionamento di SQL Server

Metodi per condividere un database desktop utilizzando SharePoint

Nota:  Questa pagina è stata tradotta automaticamente e potrebbe contenere errori di grammatica o imprecisioni. L'intento è quello di rendere fruibile il contenuto. Queste informazioni sono risultate utili' Questo è l'articolo in inglese per riferimento.

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?

Grazie per il feedback!

Grazie per il tuo feedback! Potrebbe essere utile metterti in contatto con uno dei nostri operatori del supporto di Office.

×