Migrarea unei baze de date Access la SQL Server

Se aplică la

Access pentru Microsoft 365 Access 2024 Access 2021 Access 2019 Access 2016

Cu toții avem limite, iar o bază de date Access nu face excepție. De exemplu, o bază de date Access are o limită de dimensiune de 2 GB și nu poate accepta mai mult de 255 de utilizatori simultani. Așadar, atunci când este timpul ca baza de date Access să treacă la nivelul următor, puteți migra la SQL Server. SQL Server (local sau în cloud Azure) acceptă volume mai mari de date, mai mulți utilizatori simultani și are o capacitate mai mare decât motorul de baze de date JET/ACE. Acest ghid vă oferă un început fluid al parcursului SQL Server, vă ajută să păstrați soluțiile front-end Access pe care le-ați creat și, sperăm, vă motivează să utilizați Access pentru soluții viitoare de baze de date. Utilizați Asistentul de migrare Microsoft SQL Server (SSMA) pentru a migra cu succes, urmați aceste etape.

Etapele migrării bazelor de date în SQL Server

Înainte de a începe

Următoarele secțiuni oferă informații contextuale și alte informații pentru a vă ajuta să începeți.

Despre bazele de date scindate

Toate obiectele bazei de date Access se pot afla într-un singur fișier bază de date sau pot fi stocate în două fișiere bază de date: o bază de date front-end și o bază de date back-end. Acest lucru se numește scindarea bazei de date și este proiectat să faciliteze partajarea într-un mediu de rețea. Fișierul bază de date back-end trebuie să conțină numai tabele și relații. Fișierul front-end trebuie să conțină numai alte obiecte, inclusiv formulare, rapoarte, interogări, macrocomenzi, module VBA și tabele legate la baza de date back-end. Migrarea unei baze de date Access este similară cu o bază de date scindată, în sensul că SQL Server acționează ca un back-end nou pentru datele aflate acum pe un server.

În consecință, puteți păstra în continuare baza de date Access front-end cu tabelele legate la tabelele SQL Server. Efectiv, puteți obține avantajele dezvoltării rapide a aplicațiilor pe care le oferă o bază de date Access, împreună cu scalabilitatea SQL Server.

Avantajele SQL Server

Mai aveți nevoie de câteva convingeri 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, fie în incremente, fie în mod complet, ale bazei de date în timp ce este utilizată. În consecință, nu trebuie să impuneți utilizatorilor să închidă baza de date pentru a crea o copie backup a datelor.
Înaltă performanță și scalabilitate Baza de date SQL Server are de obicei performanțe mai bune decât o bază de date Access, mai ales cu o bază de date mare, de dimensiunea terabyților. De asemenea, SQL Server procesează interogările mult mai rapid și mai eficient, procesându-le î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 furniza un acces unic și integrat la rețea și la baza de date, utilizând cele mai bune sisteme de securitate. Acest lucru simplifică mult gestionarea schemelor complexe de securitate. SQL Server este spațiul de stocare ideal pentru informații sensibile, cum ar fi coduri numerice personale, date de carduri de credit și adrese confidențiale.
Recuperare imediată Dacă sistemul de operare se defectează sau se întrerupe curentul, SQL Server poate recupera automat baza de date la o stare consistentă în câteva minute și fără intervenția administratorului bazei de date.
Utilizarea VPN Access și rețelele particulare virtuale (VPN) nu se înțeleg. Dar cu SQL Server, utilizatorii de la distanță pot utiliza în continuare baza de date front-end Access pe un desktop și back-end-ul SQL Server situat în spatele firewallului VPN.
Azure SQL Server În plus față de beneficiile SQL Server, oferă scalabilitate dinamică fără timpi morți, optimizare inteligentă, scalabilitate și disponibilitate globală, eliminarea costurilor hardware și administrare redusă.

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

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

Bază de date unică/fonduri comune elastice Această opțiune are propriul set de resurse gestionate printr-un server de Bază de date SQL. O singură bază de date este ca o bază de date conținută î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, gestionat prin intermediul serverului de Bază de date SQL. Caracteristicile SQL Server cele mai utilizate sunt cele mai frecvent disponibile cu copii backup, corecții și recuperări încorporate. Dar nu există o perioadă exactă de întreținere garantată, iar migrarea de la SQL Server poate fi dificilă.
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 are o compatibilitate strictă cu SQL Server local. O instanță gestionată are încorporate copii backup, corecții, recuperări și este simplu 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ă o durată exactă de întreținere garantată.
Mașină virtuală Azure Această opțiune vă permite să rulați SQL Server în interiorul unei mașini virtuale din cloud Azure. Aveți control total asupra motorului 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 către Azure și Ce este Azure SQL?.

Primii pași

Există câteva probleme pe care le puteți rezolva de la început care pot ajuta la fluidizarea procesului 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 un tabel legat trebuie să aibă o cheie primară dacă tabelul poate fi actualizat.
Verificarea relațiilor cheia primară/cheie externă Asigurați-vă că aceste relații se bazează pe câmpuri cu tipuri de date și dimensiuni consistente. SQL Server nu acceptă coloane asociate cu tipuri de date și dimensiuni diferite în restricțiile de cheie externă.
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 actuali conectați la baza de date închid și ei baza de date.
Dacă baza de date este într- .mdb format de fișier, eliminați securitatea la nivel de utilizator.
Efectuați copii backup ale 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 Microsoft SQL Server Express Edition pe desktop, care acceptă până la 10 GB și este o modalitate gratuită și mai simplă de a parcurge și 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.

Rulați SSMA

Microsoft oferă Asistentul de migrare Microsoft SQL Server (SSMA) pentru a facilita migrarea. SSMA migrează în principal tabele și interogări de selectare 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, permițându-vă să revizuiți conținutul curent al ambelor baze de date. Aceste două conexiuni sunt salvate în fișierul de migrare în cazul în care 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 cantitatea 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 pe 32 sau pe 64 de biți potrivită pentru computerul dvs.
După ce instalați SSMA, deschideți-l pe desktop, preferabil de pe computerul cu fișierul bază de date Access.
De asemenea, îl 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ții 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ândInstrumente> de revizuireSetări> proiect General.
Câmpul rowversion vă ajută să evitați conflictele de înregistrări. Access utilizează acest câmp rowversion într-un tabel legat SQL Server pentru a determina când a fost actualizată ultima dată înregistrarea. De asemenea, dacă adăugați câmpul rowversion la o interogare, Access îl utilizează pentru a reselecta rândul după o operațiune de actualizare. Acest lucru îmbunătățește eficiența, ajutând la evitarea erorilor de conflict de scriere ș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 putea apărea cu tipurile de date număr în virgulă mobilă și declanșatoarele 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ă Nu confundați rowversion cu mărcile de timp. Deși marca de timp a cuvântului cheie este sinonim pentru rowversion în SQL Server, nu puteți utiliza rowversion ca modalitate de a marca temporal o intrare de date.
Pentru a seta tipurile de date precise, selectați Instrumente >revizuireSetări> proiectTipuri de mapare. De exemplu, dacă stocați numai text în limba engleză, puteți utiliza tipul de date varchar în loc de nvarchar .

Conversia obiectelor

SSMA efectuează conversia obiectelor Access la 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 baza de date SQL Server:

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

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

Conversia obiectelor bazei de date preia definițiile obiectelor din metadatele Access, le convertește în sintaxa 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 SQL Server sau Exploratorul de metadate 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 migrarea finală.

Legarea tabelelor

Luați în considerare instalarea celei mai recente versiuni de drivere SQL Server OLE DB și ODBC în loc să utilizați driverele SQL Server native livrate cu Windows. Nu doar că driverele mai noi sunt mai rapide, dar ele acceptă caracteristici noi în Azure SQL pe care driverele anterioare nu le oferă. Puteți instala driverele pe fiecare computer pe care este utilizată baza de date rezultată în urma conversiei. Pentru mai multe informații, consultați Driverul Microsoft OLE DB 18 pentru SQL Server și Driverul Microsoft ODBC 17 pentru SQL Server.

După ce migrați tabelele Access, vă puteți lega la tabelele din SQL Server, care găzduiește acum datele dvs. 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 SQL Server. Puteți să interogați și să editați datele legate în funcție de permisiunile configurate de administratorul bazei de date SQL Server.

Notă În cazul în care 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ă aplicația nouă sau utilizați programatic șirul de șir de conexiune stocat î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 în Access pentru a reîmprospăta și a relega tabele în mod convenabil. Pentru mai multe informații, consultați Gestionarea tabelelor legate.

Testare și revizuire

Secțiunile următoare descriu problemele uzuale care pot apărea în timpul migrării și cum să le rezolvați.

Interogări

Se convertește doar interogările de selectare; alte interogări nu sunt, inclusiv interogările de selectare care acceptă 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 cărora nu li se efectuează conversia, utilizând sintaxa T-SQL. Erorile de sintaxă pot necesita, de asemenea, conversia manuală a funcțiilor Access și a tipurilor de date în 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 numerele mari, dar necesită utilizarea formatului de fișier bază de date .accdb Access 16 (16.0.7812 sau mai recent) ș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ă Access Da/Nu se transformă într-un câmp de biți SQL Server. Pentru a evita blocarea înregistrărilor, asigurați-vă că ați setat câmpul bit să nu permită valorile NULL. În SSMA, puteți să selectați 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 privind data și ora:

Dacă nivelul de compatibilitate al bazei de date este 130 (SQL Server 2016) sau mai mare ș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 SQL-Server bază de date 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 dată/oră2 , care are un interval de date și ore mai mare. Pentru mai multe informații, consultați Utilizarea tipului de date extinse dată/oră.
Când interogați date în SQL Server, țineți cont atât de oră, cât și de dată. De exemplu:
- DateOrdered Between 1/1/19 and 1/31/19 poate să nu includă toate comenzile.
- DateOrdered Between 1/1/19 00:00:00 AM And 1/31/19 11:59:59 PM 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ă luați în considerare stocarea legăturilor la fișiere în baza de date SQL Server. Alternativ, puteți utiliza FILESTREAM, FileTables sau un depozit de BLOBURI la distanță (RBS) pentru a păstra atașările stocate în baza de date SQL Server.

Hyperlink Tabelele Access au coloane de hyperlink pe care SQL Server nu le acceptă. În mod implicit, aceste coloane vor fi transformate î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, aveți posibilitatea să utilizați î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 se transformă în SQL Server ca un câmp ntext, care conține setul de valori delimitat. Î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 tipurilor de date Access și SQL Server, consultați Compararea tipurilor de date.

Notă Câmpurile multi-valoare nu se convertesc.

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

Visual Basic

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

Funcțiile 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 fi rulate pe SQL Server, astfel că toate datele solicitate sunt transmise către Microsoft Access pentru procesare. În majoritatea cazurilor, aceste interogări ar trebui să fie transformate în interogări directe.

Funcții definite de utilizator în interogări Interogările Microsoft Access acceptă utilizarea funcțiilor definite în modulele VBA pentru a procesa datele care le sunt transmise. Interogările pot fi interogări independente, instrucțiuni SQL în surse de înregistrări formular/raport, surse de date de casete combo și casete listă în 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 efectuați conversia la proceduri stocate în SQL Server.

Optimizați performanța

De departe, cel mai important mod de a optimiza performanța cu noul dvs. 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 la SQL Server, treceți și de la un server de fișiere la un model de calcul al bazei de date client-server. Urmați aceste instrucțiuni generale:

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

Optimizarea performanței în modelul bazei de date server client Pentru mai multe informații, consultați Crearea unei interogări directe.

Mai jos aveți recomandări suplimentare, recomandate.

Puneț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 business, interogările complexe, validarea datelor și codul de integritate referențială pe server, nu pe client. Întrebați-vă, această interogare sau activitate poate fi efectuată pe server mai bine și mai rapid? În cele din urmă, 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 indexată SQL 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 datele decât după ce utilizatorul le cere. De exemplu, păstrați necompletată proprietatea sursă de înregistrări, cereți utilizatorilor să selecteze un filtru în formular, apoi populați proprietatea sursă de înregistrări cu filtrul dvs. Sau utilizați clauza where din DoCmd.OpenForm și DoCmd.OpenReport pentru a afișa înregistrările exacte de care are nevoie utilizatorul. Luați în considerare dezactivarea navigării în înregistrări.

Aveți grijă cu interogările eterogene Evitați rularea unei interogări care combină un tabel Access local și un tabel legat SQL Server, 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, dar nu rulează interogarea în SQL Server.

Când se utilizează tabele locale Luați în considerare utilizarea tabelelor locale pentru datele care se modifică rar, 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-ul Access.

Pentru mai multe informații, consultați Consultant pentru reglarea motorului bazei de date, Utilizarea Analizor de performanță pentru optimizarea unei baze de date Access și Optimizarea aplicațiilor Microsoft Office Access legate la SQL Server.