Migrarea unei baze de date Access la SQL Server

Înainte de a începe

Secțiunile următoare oferă informații de bază și alte informații pentru a vă ajuta să începeți lucrul.

Despre bazele de date scindate

Toate obiectele bazei de date Access se pot afla fie într-un singur fișier bază de date, fie pot fi stocate în două fișiere bază de date: o bază de date front-end și o bază de date back-end. Aceasta se numește scindarea bazei de date și este proiectată pentru a facilita partajarea într-un mediu de rețea. Fișierul bază de date back-end trebuie să conțină doar tabele și relații. Fișierul front-end trebuie să conțină doar toate celelalte obiecte, inclusiv formulare, rapoarte, interogări, macrocomenzi, module VBA și tabele legate la baza de date back-end. Atunci când migrați o bază de date Access, aceasta este similară cu o bază de date scindată din acel SQL Server acționează ca un nou back-end pentru datele aflate acum pe un server.

Prin urmare, puteți menține baza de date Access front-end cu tabele legate la tabelele SQL Server. Practic, puteți obține avantajele dezvoltării rapide a aplicațiilor oferite de o bază de date Access, împreună cu scalabilitatea SQL Server.

SQL Server beneficii

Încă aveți nevoie de ceva convingător pentru a migra la SQL Server? Iată câteva beneficii suplimentare la care să vă gândiți:

Mai mulți utilizatori simultani SQL Server poate gestiona mult mai mulți utilizatori simultani decât Access și reduce la minimum cerințele de memorie atunci când sunt adăugați mai mulți utilizatori.
Disponibilitate crescută Cu SQL Server, puteți face backup dinamic, incremental sau complet, bazei de date în timp ce este în uz. În consecință, nu trebuie să impuneți utilizatorilor să închidă baza de date pentru a crea o copie backup a datelor.
Performanță și scalabilitate ridicate Baza de date SQL Server funcționează de obicei mai bine decât o bază de date Access, mai ales cu o bază de date mare, de dimensiunea terabyte. De asemenea, SQL Server procesează interogări mult mai rapid și mai eficient prin procesarea interogărilor în paralel, utilizând mai multe fire native într-un singur proces pentru a gestiona solicitările utilizatorilor.
Securitate îmbunătățită Utilizând o conexiune de încredere, SQL Server se integrează cu securitatea sistemului Windows pentru a oferi un acces unic integrat la rețea și la baza de date, utilizând cele mai bune sisteme de securitate. Acest lucru facilitează mult administrarea schemelor de securitate complexe. SQL Server este spațiul de stocare ideal pentru informații sensibile, cum ar fi codurile numerice personale, datele cardului de credit și adresele confidențiale.
Recuperabilitate imediată Dacă sistemul de operare se defectează sau se stinge curentul, SQL Server poate recupera automat baza de date la o stare unitară în câteva minute și fără intervenția administratorului bazei de date.
Utilizarea VPN Accesul și rețelele virtuale private (VPN) nu se descurcă. Dar, cu SQL Server, utilizatorii de la distanță pot utiliza în continuare baza de date front-end Access pe un desktop și SQL Server back-end aflat în spatele firewallului VPN.
SQL Server Azure În plus față de avantajele SQL Server, oferă scalabilitate dinamică, fără întreruperi, optimizare inteligentă, scalabilitate și disponibilitate la nivel global, eliminarea costurilor hardware și administrare redusă.

Alegeți cea mai bună opțiune de SQL Server Azure

Dacă efectuați migrarea la Azure SQL Server, există trei opțiuni din care să alegeți, fiecare cu beneficii diferite:

Bază de date unică/fonduri comune elastice Această opțiune are propriul set de resurse gestionate printr-un server Bază de date SQL. O singură bază de date este similară unei baze de date conținute în SQL Server. De asemenea, puteți adăuga un fond comun elastic, care este o colecție de baze de date cu un set partajat de resurse gestionate prin serverul Bază de date SQL. Caracteristicile de SQL Server utilizate cel mai frecvent sunt disponibile cu copiile backup, corecțiile și recuperarea încorporate. Dar nu există nici un timp garantat exactă de întreținere și de migrare de la SQL Server ar putea fi greu.
Instanță gestionată Această opțiune este o colecție de baze de date de sistem și de utilizator cu un set partajat de resurse. O instanță gestionată este ca o instanță a bazei de date SQL Server care este foarte compatibilă cu SQL Server local. O instanță gestionată are încorporate copii backup, corecții, recuperare și este ușor de migrat de la SQL Server. Cu toate acestea, există un număr mic de caracteristici SQL Server care nu sunt disponibile și nu există un timp de întreținere exact garantat.
Mașină virtuală Azure Această opțiune vă permite să rulați SQL Server în interiorul unei mașini virtuale în cloud Azure. Aveți control total asupra motorului de SQL Server și o cale de migrare simplă. Dar trebuie să gestionați copiile backup, corecțiile și recuperarea.

Pentru mai multe informații, consultați Alegerea căii de migrare a bazei de date la Azure și Ce este Azure SQL?.

Primii pași

Există câteva probleme pe care le puteți rezolva în prealabil, care vă pot ajuta să simplificați procesul de migrare înainte de a rula SSMA:

Adăugarea indexurilor de tabel și a cheilor primare Asigurați-vă că fiecare tabel Access are un index și o cheie primară. SQL Server necesită ca toate tabelele să aibă cel puțin un index și necesită ca un tabel legat să aibă o cheie primară, dacă tabelul poate fi actualizat.
Verificarea relațiilor cheie primară/străină Asigurați-vă că aceste relații se bazează pe câmpuri cu tipuri și dimensiuni de date unitare. SQL Server nu acceptă coloane asociate cu tipuri și dimensiuni de date diferite în restricții cheie străină.
Eliminarea coloanei Atașare SSMA nu migrează tabelele care conțin coloana Atașare.

Înainte de a rula SSMA, urmați acești pași.

Închideți baza de date Access.
Asigurați-vă că utilizatorii curenți conectați la baza de date închid și baza de date.
Dacă baza de date este în .mdb format de fișier, eliminați securitatea la nivel de utilizator.
Faceți backup bazei de date. Pentru mai multe informații, consultați Protejarea datelor cu ajutorul proceselor de backup și restaurare.

Sfat Luați în considerare instalarea ediției Microsoft SQL Server Express pe desktop, care acceptă până la 10 GB și este o modalitate gratuită și mai simplă de a trece prin și a verifica migrarea. Atunci când vă conectați, utilizați LocalDB ca instanță a bazei de date.

Sfat Dacă este posibil, utilizați o versiune independentă de Access. Dacă puteți utiliza doar Microsoft 365, utilizați motorul de baze de date Access 2010 pentru a migra baza de date Access atunci când utilizați SSMA. Pentru mai multe informații, consultați Redistributable Microsoft Access Database Engine 2010.

Rulare SSMA

Microsoft oferă Microsoft SQL Server Migration Assistant (SSMA) pentru a facilita migrarea. SSMA migrează în principal tabele și selectează interogări fără parametri. Formularelor, rapoartelor, macrocomenzilor și modulelor VBA nu li se efectuează conversia. Exploratorul de metadate SQL Server afișează obiectele bazei de date Access și obiectele SQL Server care vă permit să revizuiți conținutul curent al ambelor baze de date. Aceste două conexiuni sunt salvate în fișierul de migrare dacă decideți să transferați obiecte suplimentare în viitor.

Notă Procesul de migrare poate dura un timp, în funcție de dimensiunea obiectelor bazei de date și de volumul de date care trebuie transferate.

Pentru a migra o bază de date utilizând SSMA, mai întâi descărcați și instalați software-ul făcând dublu clic pe fișierul MSI descărcat. Asigurați-vă că instalați versiunea corespunzătoare pe 32 sau pe 64 de biți pentru computerul dvs.
După instalarea SSMA, deschideți-l pe desktop, preferabil de pe computerul cu fișierul bază de date Access.

De asemenea, o puteți deschide pe un computer care are acces la baza de date Access din rețea într-un folder partajat.
Urmați instrucțiunile de început din SSMA pentru a furniza informații de bază, cum ar fi locația SQL Server, baza de date access și obiectele de migrat, informațiile de conexiune și dacă doriți să creați tabele legate.
Dacă migrați la SQL Server 2016 sau o versiune mai recentă și doriți să actualizați un tabel legat, adăugați o coloană rowversion selectând Instrumente revizuire > Setări proiect > General.

Câmpul rowversion vă ajută să evitați conflictele de înregistrări. Access utilizează acest câmp rowversion într-un SQL Server tabel legat pentru a determina când s-a actualizat ultima dată înregistrarea. De asemenea, dacă adăugați câmpul rowversion la o interogare, Access îl utilizează pentru a selecta din nou rândul după o operațiune de actualizare. Acest lucru îmbunătățește eficiența, ajutând la evitarea erorilor de scriere în conflict și a scenariilor de ștergere a înregistrărilor, care pot apărea atunci când Access detectează rezultate diferite față de remiterea inițială, cum ar fi tipurile de date cu numere în virgulă mobilă și triggerele care modifică coloane. Totuși, evitați utilizarea câmpului rowversion în formulare, rapoarte sau cod VBA. Pentru mai multe informații, consultați Rowversion.

Notă Evitați confuzia rowversion cu marcaje de timp. Deși marca de timp pentru cuvinte cheie este un sinonim pentru rowversion în SQL Server, nu puteți utiliza rowversion ca modalitate de a marca temporal o intrare de date.
Pentru a seta tipuri de date precise, selectați Revizuire instrumente > Setări proiect > Mapare tip. De exemplu, dacă stocați doar text în limba engleză, puteți utiliza tipul de date varchar în loc de nvarchar .

Conversie obiecte

SSMA face conversia obiectelor Access în obiecte SQL Server, dar nu copiază obiectele imediat. SSMA furnizează o listă cu următoarele obiecte de migrat, astfel încât să decideți dacă doriți să le mutați în SQL Server bază de date:

Tabele și coloane
Selectați Interogări fără parametri.
Chei primare și externe
Indexuri și valori implicite
Verificați restricțiile (permiteți proprietatea coloanei de lungime zero, regula de validare a coloanelor, validarea tabelului)

Ca exemplu de bună practică, utilizați raportul de evaluare SSMA, care afișează rezultatele conversiei, inclusiv erorile, avertismentele, mesajele informative, estimările de timp pentru efectuarea migrării și pașii individuali de corectare a erorilor de parcurs înainte de a muta efectiv obiectele.

Conversia obiectelor bazei de date preia definițiile obiectelor din metadatele Access, le transformă în sintaxă Transact-SQL (T-SQL) echivalentă, apoi încarcă aceste informații în proiect. Apoi puteți vizualiza obiectele SQL Server sau SQL Azure și proprietățile lor utilizând Explorator metadate SQL Server sau SQL Azure.

Pentru a efectua conversia, încărcarea și migrarea obiectelor în SQL Server, urmați acest ghid.

Sfat După ce ați migrat cu succes baza de date Access, salvați fișierul de proiect pentru utilizare ulterioară, astfel încât să puteți migra datele din nou pentru testare sau migrare finală.

Legarea tabelelor

Luați în considerare instalarea celei mai recente versiuni a driverelor SQL Server OLE DB și ODBC în loc să utilizați driverele SQL Server native care se livrează cu Windows. Nu doar că driverele mai noi sunt mai rapide, dar acceptă noile caracteristici din Azure SQL pe care driverele anterioare nu le acceptă. Puteți instala driverele pe fiecare computer pe care se utilizează baza de date convertită. Pentru mai multe informații, consultați Microsoft OLE DB Driver 18 pentru SQL Server și Microsoft ODBC Driver 17 pentru SQL Server.

După ce efectuați migrarea tabelelor Access, puteți crea o legătură la tabelele din SQL Server care găzduiește acum datele. Legarea direct din Access vă oferă, de asemenea, o modalitate mai simplă de a vizualiza datele, în loc să utilizați instrumentele mai complexe de gestionare a SQL Server. Puteți interoga și edita datele legate în funcție de permisiunile configurate de administratorul bazei de date SQL Server.

Notă Dacă creați un DSN ODBC atunci când vă legați la baza de date SQL Server în timpul procesului de legare, creați același DSN pe toate computerele care utilizează noua aplicație sau utilizați prin programare șir de conexiune stocate în fișierul DSN.

Pentru mai multe informații, consultați Legarea sau importul datelor dintr-o bază de date Azure SQL Server și Importul sau legarea la datele dintr-o bază de date SQL Server.

Sfat Nu uitați să utilizați Managerul de tabele legate din Access pentru a reîmprospăta și a lega din nou tabelele în mod convenabil. Pentru mai multe informații, consultați Gestionarea tabelelor legate.

Testarea și revizuirea

Secțiunile următoare descriu problemele comune pe care le puteți întâmpina în timpul migrării și cum să le rezolvați.

Interogări

Se face conversia numai interogărilor de selectare; alte interogări nu sunt, inclusiv Interogări de selectare care preiau parametri. Este posibil ca unele interogări să nu efectueze conversia completă, iar SSMA raportează erori de interogare în timpul procesului de conversie. Puteți edita manual obiectele care nu se convertesc utilizând sintaxa T-SQL. Erorile de sintaxă pot necesita, de asemenea, conversia manuală a funcțiilor și tipurilor de date specifice Access la unele SQL Server. Pentru mai multe informații, consultați Compararea Access SQL cu SQL Server TSQL.

Tipuri de date

Access și SQL Server au tipuri de date similare, dar rețineți următoarele probleme potențiale.

Număr mare Tipul de date Număr mare stochează o valoare numerică non-monetară și este compatibil cu tipul de date bigint SQL. Puteți utiliza acest tip de date pentru a calcula eficient numere mari, dar necesită utilizarea formatului de fișier bază de date Access 16 (16.0.7812 sau mai recent) .accdb și funcționează mai bine cu versiunea de Access pe 64 de biți. Pentru mai multe informații, consultați Utilizarea tipului de date Număr mare și Alegeți între versiunea de Office pe 64 de biți sau pe 32 de biți.

Da/Nu În mod implicit, o coloană Acces Da/Nu se transformă într-un câmp SQL Server biți. Pentru a evita blocarea înregistrărilor, asigurați-vă că este setat câmpul bit pentru a nu permite valori NULL. ÎN SSMA, puteți selecta coloana de biți pentru a seta proprietatea Allow Nulls la NO. În TSQL, utilizați instrucțiunile CREATE TABLE sau ALTER TABLE .

Data și ora Există mai multe considerații legate de dată și oră:

Dacă nivelul de compatibilitate al bazei de date este 130 (SQL Server 2016) sau mai recent și un tabel legat conține una sau mai multe coloane dată-oră sau dată-oră2, tabelul poate returna mesajul #deleted în rezultate. Pentru mai multe informații, consultați Tabelul legat Access la baza de date SQL-Server returnează #deleted.
Utilizați tipul de date Dată/Oră Access pentru a mapa la tipul de date dată-oră. Utilizați tipul de date Dată/Oră extins Access pentru a mapa la tipul de date datetime2 care are o dată și un interval de timp mai mari. Pentru mai multe informații, consultați Utilizarea tipului de date Extins pentru dată/oră.
Atunci când interogați date în SQL Server, luați în considerare ora și data. De exemplu:
- DateOrdered Between 01.01.2019 și 31.01.2019 poate să nu includă toate comenzile.
- DateOrdered Between 01.01.19 00:00:00 And 31.01.19 11:59:59 PM nu include toate comenzile.

Atașare Tipul de date Atașare stochează un fișier în baza de date Access. În SQL Server, aveți mai multe opțiuni de luat în considerare. Puteți să extrageți fișierele din baza de date Access, apoi să stocați linkuri la fișierele din baza de date SQL Server. Alternativ, puteți utiliza FILESTREAM, FileTables sau Remote BLOB store (RBS) pentru a păstra atașările stocate în baza de date SQL Server.

Hyperlink Tabelele Access au coloane de hyperlinkuri pe care SQL Server nu le acceptă. În mod implicit, aceste coloane vor fi convertite în coloane nvarchar(max) în SQL Server, dar puteți particulariza maparea pentru a alege un tip de date mai mic. În soluția Access, puteți utiliza în continuare comportamentul hyperlinkului în formulare și rapoarte dacă setați proprietatea Hyperlink pentru control la adevărat.

Câmp multi-valoare Câmpul multi-valoare Access este convertit în SQL Server ca un câmp ntext care conține setul delimitat de valori. Întrucât SQL Server nu acceptă un tip de date multi-valoare care modelează o relație mai mulți-la-mai-mulți, poate fi necesară muncă de proiectare și de conversie suplimentară.

Pentru mai multe informații despre maparea access și a tipurilor de date SQL Server, consultați Compararea tipurilor de date.

Notă Câmpurilor multi-valoare nu li se efectuează conversia.

Pentru mai multe informații, consultați Tipuri de dată și oră, tipuri de șiruri și binare și tipuri numerice.

Visual Basic

Deși VBA nu este acceptat de SQL Server, rețineți următoarele probleme posibile:

Funcții VBA în interogări Interogările Access acceptă funcții VBA pentru datele dintr-o coloană de interogare. Dar interogările Access care utilizează funcții VBA nu pot rula pe SQL Server, astfel că toate datele solicitate sunt transmise către Microsoft Access pentru procesare. În majoritatea cazurilor, acestor interogări ar trebui să li se efectueze conversia la interogări directe.

Funcții definite de utilizator în interogări Interogările Microsoft Access acceptă utilizarea funcțiilor definite în module VBA pentru a procesa datele care le-au fost transmise. Interogările pot fi interogări independente, instrucțiuni SQL din surse de înregistrări formular/raport, surse de date ale casetelor combo și casete listă din formulare, rapoarte și câmpuri de tabel și expresii implicite sau de reguli de validare. SQL Server nu poate rula aceste funcții definite de utilizator. Poate fi necesar să reproiectați manual aceste funcții și să le transformați în proceduri stocate pe SQL Server.

Optimizați performanța

De departe, cel mai important mod de a optimiza performanța cu noua SQL Server back-end este să decideți când să utilizați interogări locale sau la distanță. Atunci când migrați datele în SQL Server, treceți de asemenea de la un server de fișiere la un model de bază de date client-server de calcul. Urmați aceste indicații generale:

Rulați interogări mici, doar în citire în client, pentru acces cât mai rapid.
Rulați interogări lungi, în citire/scriere pe server, pentru a profita de puterea de procesare mai mare.
Minimizați traficul de rețea cu filtre și agregare pentru a transfera doar datele de care aveți nevoie.

Optimizarea performanței în modelul de bază de date server client

Pentru mai multe informații, consultați Crearea unei interogări directe.

Următoarele sunt instrucțiuni suplimentare, recomandate.

Plasați logica pe server Aplicația poate utiliza, de asemenea, vizualizări, funcții definite de utilizator, proceduri stocate, câmpuri calculate și triggere pentru a centraliza și a partaja logica aplicației, regulile și politicile de afaceri, interogările complexe, validarea datelor și codul de integritate referențială de pe server, nu pe client. Întrebați-vă dacă această interogare sau activitate se poate efectua pe server mai bine și mai rapid? În sfârșit, testați fiecare interogare pentru a asigura o performanță optimă.

Utilizarea vizualizărilor în formulare și rapoarte În Access, procedați astfel:

Pentru formulare, utilizați o vizualizare SQL pentru un formular doar în citire și o vizualizare SQL indexată pentru un formular în citire/scriere ca sursă de înregistrări.
Pentru rapoarte, utilizați o vizualizare SQL ca sursă de înregistrări. Totuși, creați o vizualizare separată pentru fiecare raport, astfel încât să puteți actualiza mai ușor un anumit raport, fără a afecta alte rapoarte.

Minimizarea încărcării datelor într-un formular sau raport Nu afișați date decât după ce utilizatorul solicită acest lucru. De exemplu, păstrați necompletată proprietatea sursei de înregistrări, faceți ca utilizatorii să selecteze un filtru în formular, apoi să populeze proprietatea sursei de înregistrări cu filtrul dvs. Sau utilizați clauza where din DoCmd.OpenForm și DoCmd.OpenReport pentru a afișa înregistrările exacte necesare utilizatorului. Vă recomandăm să dezactivați navigarea prin înregistrări.

Fiți atent cu interogările eterogene Evitați rularea unei interogări care combină un tabel Access local și SQL Server tabel legat, denumit uneori interogare hibridă. Acest tip de interogare necesită în continuare Ca Access să descarce toate datele SQL Server pe computerul local, apoi să ruleze interogarea, nu să ruleze interogarea în SQL Server.

Când se utilizează tabelele locale Luați în considerare utilizarea tabelelor locale pentru date care se modifică rareori, cum ar fi lista de state sau provincii dintr-o țară sau regiune. Tabelele statice sunt utilizate adesea pentru filtrare și pot funcționa mai bine pe front-end Access.

Pentru mai multe informații, consultați Consultant pentru reglarea motorului bazei de date Utilizați Analizor de performanță pentru a optimiza o bază de date Access și Optimizarea aplicațiilor Microsoft Office Access legate la SQL Server.