Migrera en Access-databas till SQL Server

Gäller för

Access för Microsoft 365 Access 2024 Access 2021 Access 2019 Access 2016

Vi har alla sina begränsningar, och en Access-databas är inget undantag. En Access-databas har till exempel en storleksgräns på 2 GB och har inte stöd för fler än 255 samtidiga användare. Så när det är dags för din Access-databas att gå till nästa nivå kan du migrera till SQL Server. SQL Server (lokalt eller i Azure molnet) stöder större mängder data, fler samtidiga användare och har större kapacitet än JET/ACE-databasmotorn. Den här guiden ger dig en smidig start på din SQL Server resa, hjälper till att bevara Access front-end-lösningar du skapade och motiverar dig förhoppningsvis att använda Access för framtida databaslösningar. Använd Microsoft SQL Server Migration Assistant (SSMA) för att migrera, följ dessa steg.

Stegen i databasmigrering till SQL Server

Innan du börjar

Följande avsnitt innehåller bakgrundsinformation och annan information som hjälper dig att komma igång.

Om delade databaser

Alla Access-databasobjekt kan antingen finnas i en databasfil eller så kan de lagras i två databasfiler: en frontend-databas och en backend-databas. Det kallas för att dela upp databasen och är utformat för att underlätta delning i en nätverksmiljö. Backend-databasfilen får bara innehålla tabeller och relationer. Frontend-filen får endast innehålla alla andra objekt, inklusive formulär, rapporter, frågor, makron, VBA-moduler och länkade tabeller till backend-databasen. När du migrerar en Access-databas liknar den en delad databas på så sätt att SQL Server fungerar som en ny serverdel för de data som nu finns på en server.

Därför kan du fortfarande underhålla Access-klientdelen med länkade tabeller till SQL Server tabeller. På ett effektivt sätt kan du dra nytta av fördelarna med snabb programutveckling som en Access-databas ger, tillsammans med skalbarheten hos SQL Server.

Fördelar med SQL Server

Behöver du fortfarande lite övertalning för att migrera till SQL Server? Här är några ytterligare fördelar att tänka på:

Fler samtidiga användare SQL Server kan hantera många fler samtidiga användare än Access och minimerar minneskraven när fler användare läggs till.
Ökad tillgänglighet Med SQL Server kan du säkerhetskopiera dynamiskt, antingen inkrementell eller fullständig, databasen medan den används. Med andra ord behöver du inte tvinga användarna att avsluta sitt arbete och stänga databasen när du vill säkerhetskopiera databasen.
Hög prestanda och skalbarhet SQL Server-databasen fungerar vanligtvis bättre än en Access-databas, särskilt med en stor databas med terabytestorlek. Dessutom bearbetar SQL Server frågor mycket snabbare och effektivt genom att bearbeta frågor parallellt, med hjälp av flera inbyggda trådar i en enda process för att hantera användarförfrågningar.
Förbättrad säkerhet Med hjälp av en betrodd anslutning integreras SQL Server med Windows systemsäkerhet för att ge en enda integrerad åtkomst till nätverket och databasen, med det bästa av båda säkerhetssystemen. Detta gör det mycket enklare att administrera komplexa säkerhetsscheman. SQL Server är den perfekta lagringen för känslig information som personnummer, kreditkortsdata och adresser som är konfidentiella.
Omedelbar återställbarhet Om operativsystemet kraschar eller strömmen går kan SQL Server automatiskt återställa databasen till ett konsekvent tillstånd på några minuter och utan att databasadministratören behöver ingripa.
Användning av VPN Åtkomst och virtuellt privat nätverk (VPN) kommer inte överens. Men med SQL Server kan fjärranvändare fortfarande använda Access front-end-databasen på ett skrivbord och SQL Server back-end som ligger bakom VPN-brandväggen.
Azure SQL Server Förutom fördelarna med SQL Server erbjuder dynamisk skalbarhet utan driftstopp, intelligent optimering, global skalbarhet och tillgänglighet, eliminering av hårdvarukostnader och minskad administration.

Välj det bästa alternativet Azure SQL Server

Om du migrerar till Azure SQL Server finns det tre alternativ att välja mellan, vart och ett med olika fördelar:

Enkel databas/elastiska pooler Det här alternativet har en egen uppsättning resurser som hanteras via en SQL Database server. En enskild databas är som en innesluten databas i SQL Server. Du kan också lägga till en elastisk pool, som är en samling databaser med en delad uppsättning resurser som hanteras via SQL Database Server. De vanligaste funktionerna i SQL Server är tillgängliga med inbyggd säkerhetskopiering, korrigering och återställning. Men det finns ingen garanterad exakt underhållstid och migrering från SQL Server kan vara svårt.
Hanterad instans Det här alternativet är en samling system- och användardatabaser med en delad uppsättning resurser. En hanterad instans är som en instans av SQL Server databasen som är mycket kompatibel med SQL Server lokalt. En hanterad instans har inbyggd säkerhetskopiering, korrigering, återställning och är enkel att migrera från SQL Server. Det finns dock ett litet antal SQL Server funktioner som inte är tillgängliga och ingen garanterad exakt underhållstid.
Virtuell Azure-dator Med det här alternativet kan du köra SQL Server inuti en virtuell dator i Azure molnet. Du har full kontroll över SQL Server-motorn och en enkel migreringsväg. Men du måste hantera dina säkerhetskopior, korrigeringar och återställning.

Mer information finns i Välja din databasmigreringsväg till Azure och Vad är Azure SQL?.

Första stegen

Det finns några frågor som du kan åtgärda direkt som kan underlätta migreringsprocessen innan du kör SSMA:

Lägga till tabellindex och primärnycklar Kontrollera att alla Access-tabeller har ett index och en primärnyckel. SQL Server kräver att alla tabeller har minst ett index och att en länkad tabell har en primärnyckel om tabellen kan uppdateras.
Kontrollera primärnyckel-/sekundärnyckelrelationer Se till att dessa relationer baseras på fält med konsekventa datatyper och storlekar. SQL Server stöder inte kopplade kolumner med olika datatyper och storlekar i sekundärnyckelbegränsningar.
Ta bort kolumnen Bifogad fil SSMA migrerar inte tabeller som innehåller kolumnen Bifogad fil.

Innan du kör SSMA ska du utföra följande första steg.

Stäng Access-databasen.
Se till att de aktuella användarna som är anslutna till databasen också stänger databasen.
Om databasen är i .mdb filformat tar du bort säkerhet på användarnivå.
Säkerhetskopiera databasen. Mer information finns i Skydda data med säkerhetskopierings- och återställningsprocesser.

Tips Överväg att installera Microsoft SQL Server Express Edition på skrivbordet som stöder upp till 10 GB och är ett kostnadsfritt och enklare sätt att gå igenom och kontrollera migreringen. När du ansluter använder du LocalDB som databasinstans.

Tips Använd om möjligt en fristående version av Access.

Köra SSMA

Microsoft tillhandahåller Microsoft SQL Server Migration Assistant (SSMA) för att underlätta migreringen. SSMA migrerar huvudsakligen tabeller och urvalsfrågor utan parametrar. Formulär, rapporter, makron och VBA-moduler konverteras inte. SQL Server Metadata Explorer visar dina Access-databasobjekt och SQL Server-objekt så att du kan granska det aktuella innehållet i båda databaserna. De här två anslutningarna sparas i migreringsfilen om du bestämmer dig för att överföra fler objekt i framtiden.

Anteckning Migreringsprocessen kan ta lite tid beroende på storleken på databasobjekten och mängden data som ska överföras.

Om du vill migrera en databas med hjälp av SSMA måste du först ladda ned och installera programvaran genom att dubbelklicka på den nedladdade MSI-filen. Se till att du installerar rätt 32- eller 64-bitarsversion för din dator.
När du har installerat SSMA ska du öppna det på skrivbordet, helst från datorn med Access-databasfilen.
Du kan också öppna det på en dator som har åtkomst till Access-databasen från nätverket i en delad mapp.
Följ de inledande instruktionerna i SSMA för att ange grundläggande information som platsen för SQL Server, Access-databasen och objekt som ska migreras, anslutningsinformation och om du vill skapa länkade tabeller.
Om du migrerar till SQL Server 2016 eller senare och vill uppdatera en länkad tabell lägger du till en rowversion-kolumn genom att välja Granska verktyg>Projektinställningar>Allmänt.
Fältet rowversion hjälper dig att undvika postkonflikter. Access använder det här rowversion-fältet i en länkad tabell i SQL Server för att avgöra när posten senast uppdaterades. Om du lägger till fältet rowversion i en fråga används det för att markera raden på nytt efter en uppdatering. Det här förbättrar effektiviteten genom att undvika skrivkonflikter, fel och scenarier för borttagning av poster som kan inträffa när Access identifierar olika resultat från den ursprungliga överföringen, till exempel kan inträffa med flyttalsdatatyper och utlösare som ändrar kolumner. Undvik dock att använda fältet rowversion i formulär, rapporter eller VBA-kod. Mer information finns i rowversion.
Anteckning Undvik att blanda ihop rowversion med tidsstämplar. Även om nyckelordet tidsstämpel är en synonym för rowversion i SQL Server kan du inte använda rowversion som ett sätt att tidsstämpla en datapost.
Om du vill ange exakta datatyper väljer du Granska verktyg>Typmappning förprojektinställningar>. Om du till exempel bara lagrar engelsk text kan du använda datatypen varchar i stället för nvarchar .

Konvertera objekt

SSMA konverterar Access-objekt till SQL Server-objekt, men objekten kopieras inte direkt. SSMA tillhandahåller en lista med följande objekt att migrera så att du kan bestämma om du vill flytta dem till SQL Server databas:

Tabeller och kolumner
Välj Frågor utan parametrar.
Primär- och sekundärnycklar
Index och standardvärden
Kontrollera villkor (tillåt nollängdskolumnegenskap, kolumnverifieringsuttryck, tabellverifiering)

Det bästa är att använda SSMA-utvärderingsrapporten, som visar konverteringsresultatet, inklusive fel, varningar, informationsmeddelanden, tidsuppskattningar för att utföra migreringen och enskilda felkorrigeringssteg som ska vidtas innan du faktiskt flyttar objekten.

Konvertering av databasobjekt tar objektdefinitionerna från Access-metadata, konverterar dem till motsvarande Transact-SQL-syntax (T-SQL) och läser sedan in den här informationen i projektet. Därefter kan du visa SQL Server- eller SQL Azure-objekten och deras egenskaper med hjälp av SQL Server eller SQL Azure Metadata Explorer.

Följ den här guiden om du vill konvertera, läsa in och migrera objekt till SQL Server.

Tips När du har migrerat Access-databasen sparar du projektfilen för senare användning, så att du kan migrera dina data igen för testning eller slutlig migrering.

Länka tabeller

Överväg att installera den senaste versionen av SQL Server OLE DB- och ODBC-drivrutinerna istället för att använda de inbyggda SQL Server-drivrutinerna som levereras med Windows. De nyare drivrutinerna är inte bara snabbare, utan stöder nya funktioner i Azure SQL som de tidigare drivrutinerna inte har. Du kan installera drivrutinerna på varje dator där den konverterade databasen används. Mer information finns i Microsoft OLE DB-drivrutin 18 för SQL Server och Microsoft ODBC-drivrutin 17 för SQL Server.

När du har migrerat Access-tabellerna kan du länka till tabellerna i SQL Server som nu är värd för dina data. Genom att länka direkt från Access får du också ett enklare sätt att visa dina data istället för att använda de mer komplexa hanteringsverktygen i SQL Server. Du kan fråga och redigera länkade data beroende på vilka behörigheter som har ställts in av SQL Server databasadministratören.

Anteckning Om du skapar en ODBC DSN när du länkar till SQL Server -databasen under länkningsprocessen skapar du antingen samma DSN på alla datorer som använder det nya programmet eller använder programmässigt den anslutningssträng som lagras i DSN-filen.

Mer information finns i Länka till eller importera data från en Azure SQL Server-databas och Importera eller länka till data i en SQL Server databas.

Tips Glöm inte att använda Länkhanteraren i Access för att enkelt uppdatera och länka om tabeller. Mer information finns i Hantera länkade tabeller.

Testa och revidera

I följande avsnitt beskrivs vanliga problem som kan uppstå under migreringen och hur du hanterar dem.

Frågor

Endast urvalsfrågor konverteras. andra frågor är inte det, inklusive urvalsfrågor som tar parametrar. Vissa frågor kanske inte konverteras helt och SSMA rapporterar frågefel under konverteringsprocessen. Du kan manuellt redigera objekt som inte konverteras med hjälp av T-SQL-syntax. Syntaxfel kan också kräva manuell konvertering av Access-specifika funktioner och datatyper till SQL Server. Mer information finns i Jämförelse av SQL i Access med T-SQL för SQL Server.

Datatyper

Access och SQL Server har liknande datatyper, men tänk på följande möjliga problem.

Stort tal Datatypen Stort tal lagrar ett icke-monetärt, numeriskt värde och är kompatibel med datatypen bigint i SQL. Du kan använda den här datatypen för att effektivt beräkna stora tal, men det kräver att du använder Access 16-databasfilformatet (16.0.7812 eller senare) .accdb och fungerar bättre med 64-bitarsversionen av Access. Mer information finns i Använda datatypen Stort tal och Välj mellan 64- och 32-bitarsversionen av Office.

Ja/Nej Som standard konverteras en Access Yes/No-kolumn till ett SQL Server bitfält. För att undvika postlåsning kontrollerar du att bitfältet är inställt på att inte tillåta NULL-värden. I SSMA kan du välja bitkolumnen för att ange egenskapen Tillåt null-värden till NEJ. I TSQL använder du instruktionerna CREATE TABLE eller ALTER TABLE .

Datum och tid Det finns flera saker att tänka på när det gäller datum och tid:

Om kompatibilitetsnivån för databasen är 130 (SQL Server 2016) eller högre, och en länkad tabell innehåller en eller flera datetime- eller datetime2-kolumner, kan tabellen returnera meddelandet #deleted i resultatet. Mer information finns i Access-länkad tabell för att SQL-Server databasreturnerar #deleted.
Använd datatypen Date/Time i Access för att mappa till datatypen datetime. Använd den utökade datatypen Datum/tid för Access för att mappa till datatypen datetime2 som har ett större datum- och tidsintervall. Mer information finns i Använda den utökade datatypen Datum/tid.
När du frågar efter datum i SQL Server bör du ta hänsyn till både tid och datum. Till exempel:
- DateOrdered Mellan 19-01-01 och 19-01-31 kanske inte inkluderar alla beställningar.
- DateOrdered Between 1/1/19 00:00:00 AM And 1/31/19 11:59:59 PM does all orders.

Bifogad fil Datatypen Bifogad fil lagrar en fil i Access-databasen. I SQL Server har du flera alternativ att överväga. Du kan extrahera filerna från Access-databasen och sedan överväga att lagra länkar till filerna i SQL Server -databasen. Alternativt kan du använda FILESTREAM, FileTables eller Remote BLOB store (RBS) för att hålla bifogade filer lagrade i SQL Server databasen.

Hyperlänk Access-tabeller har hyperlänkkolumner som SQL Server inte stöder. Som standard konverteras dessa kolumner till nvarchar(max)-kolumner i SQL Server, men du kan anpassa mappningen för att välja en mindre datatyp. I din Access-lösning kan du fortfarande använda hyperlänkbeteendet i formulär och rapporter om du anger egenskapen Hyperlänk för kontrollen till Sant.

Flervärdesfält Flervärdesfältet i Access konverteras till SQL Server som ett ntext-fält som innehåller den avgränsade uppsättningen värden. Eftersom SQL Server inte har stöd för en flervärdesdatatyp som motsvarar en många-till-många-relation krävs det kanske ytterligare design- och konverteringsarbete.

Mer information om hur du mappar datatyper i Access och SQL Server finns i Jämföra datatyper.

Anteckning Flervärdesfält konverteras inte.

Mer information finns i Datum- och tidstyper, Strängtyper och binära typer och Numeriska typer.

Visual Basic

Även om VBA inte stöds av SQL Server bör du tänka på följande möjliga problem:

VBA-funktioner i frågor Access-frågor har stöd för VBA-funktioner för data i en frågekolumn. Men Access-frågor som använder VBA-funktioner kan inte köras på SQL Server, så alla begärda data skickas till Microsoft Access för bearbetning. I de flesta fall bör dessa frågor konverteras till direktfrågor.

Användardefinierade funktioner i frågor Microsoft Access-frågor stöder användning av funktioner som definierats i VBA-moduler för att bearbeta data som skickas till dem. Frågor kan vara fristående frågor, SQL-uttryck i formulär-/rapportdatakällor, datakällor för kombinationsrutor och listrutor i formulär, rapporter och tabellfält samt standarduttryck eller verifieringsuttryck. SQL Server kan inte köra dessa användardefinierade funktioner. Du kan behöva designa om funktionerna manuellt och konvertera dem till lagrade procedurer på SQL Server.

Optimera prestanda

Det absolut viktigaste sättet att optimera prestanda med din nya serverdel SQL Server är att bestämma när du ska använda lokala frågor eller fjärrfrågor. När du migrerar dina data till SQL Server flyttar du också från en filserver till en klient/serverdatabasmodell för databehandling. Följ de här allmänna riktlinjerna:

Kör små, skrivskyddade frågor på klienten för snabbast åtkomst.
Kör långa läs-/skrivfrågor på servern för att dra nytta av den större processorkraften.
Minimera nätverkstrafiken med filter och aggregering för att bara överföra de data du behöver.

Optimera prestanda i klient-serverdatabasmodellen Mer information finns i Skapa en direktfråga.

Följande är ytterligare, rekommenderade riktlinjer.

Placera logik på servern Programmet kan också använda vyer, användardefinierade funktioner, lagrade procedurer, beräknade fält och utlösare för att centralisera och dela programlogik, affärsregler och principer, komplexa frågor, dataverifiering och kod för referensintegritet på servern i stället för på klienten. Fråga dig själv, kan den här frågan eller uppgiften utföras på servern bättre och snabbare? Slutligen testar du varje fråga för att säkerställa optimala prestanda.

Använda vyer i formulär och rapporter Gör så här i Access:

För formulär använder du en SQL-vy för ett skrivskyddat formulär och en SQL-indexerad vy för ett skrivskyddat formulär som datakälla.
För rapporter använder du en SQL-vy som datakälla. Men skapa en separat vy för varje rapport så att du enklare kan uppdatera en specifik rapport utan att påverka andra rapporter.

Minimera inläsningen av data i ett formulär eller en rapport Visa inte data förrän användaren ber om det. Du kan till exempel behålla egenskapen datakälla tom, låta användarna välja ett filter i formuläret och sedan fylla i egenskapen datakälla med filtret. Eller använd where-satsen i DoCmd.OpenForm och DoCmd.OpenReport för att visa de exakta posterna som krävs av användaren. Överväg att inaktivera postnavigering.

Var försiktig med heterogena frågor Undvik att köra en fråga som kombinerar en lokal Access-tabell och en länkad SQL Server-tabell, en så kallad hybridfråga. Den här typen av fråga kräver fortfarande Access för att ladda ned alla SQL Server data till den lokala datorn och sedan köra frågan, den kör inte frågan i SQL Server.

När du ska använda lokala tabeller Överväg att använda lokala tabeller för data som ändras sällan, till exempel listan över delstater eller provinser i ett land eller en region. Statiska tabeller används ofta för filtrering och kan fungera bättre på Access front-end.

Mer information finns i Finjusteringsverktyg för databasmotorer, Använda Prestandaanalys för att optimera en Access-databas och Optimera Microsoft Office Access-program länkade till SQL Server.