Migrera en Access-databas till SQL Server
Applies ToAccess för Microsoft 365 Access 2024 Access 2021 Access 2019 Access 2016

Vi har alla gränser och en Access-databas är inget undantag. En Access-databas har till exempel en storleksgräns på 2 GB och kan inte ha stöd för fler än 255 samtidiga användare. När det är dags för Access-databasen att gå vidare till nästa nivå kan du alltså migrera till SQL Server. SQL Server (oavsett om det är 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 frontend-lösningar som du har skapat och förhoppningsvis motiverar dig att använda Access för framtida databaslösningar. Använd Migreringsassistenten för Microsoft SQL Server (SSMA) för att migrera, följ de här stegen.

Stegen i databasmigreringen till SQL Server

Innan du börjar

Följande avsnitt innehåller bakgrund 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 klientdatabas och en backend-databas. Detta kallas för att dela upp databasen och är utformad 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 genom att SQL Server fungerar som en ny backend för de data som nu finns på en server.

Därför kan du fortfarande underhålla access-databasen med länkade tabeller till SQL Server-tabellerna. I praktiken kan du dra nytta av snabb programutveckling som en Access-databas ger, tillsammans med skalbarheten för SQL Server.

Fördelar med SQL Server

Behöver du fortfarande övertygande 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 dynamiskt säkerhetskopiera, antingen stegvis 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. SQL Server bearbetar också 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. Det gör det mycket enklare att administrera komplexa säkerhetsscheman. SQL Server är en idealisk lagringsplats för känslig information som personnummer, kreditkortsuppgifter och adresser som är konfidentiella.

  • Omedelbar återställning     Om operativsystemet kraschar eller om strömmen går kan SQL Server automatiskt återställa databasen till ett enhetligt tillstånd efter bara några minuter och utan någon ingripande databasadministratör.

  • Användning av VPN    Access och Virtual Private Networks (VPN) kommer inte överens. Men med SQL Server kan fjärranvändare fortfarande använda Access-frontenddatabasen på ett skrivbord och SQL Server-backend som finns 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 maskinvarukostnader och minskad administration.

Välj det bästa Azure SQL Server-alternativet

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

  • Enskild databas/elastiska pooler    Det här alternativet har en egen uppsättning resurser som hanteras via en SQL Database-server. En enda 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-servern. De vanligaste SQL Server-funktionerna är tillgängliga med inbyggda säkerhetskopior, korrigeringar och återställning. Men det finns ingen garanterad exakt underhållstid och migrering från SQL Server kan vara svår.

  • 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 den lokala SQL Server-servern. En hanterad instans har inbyggda säkerhetskopior, korrigeringar, återställning och är lätt 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 i 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 databasmigreringssökväg till Azure och Vad är Azure SQL?.

Första stegen

Det finns några problem som du kan åtgärda på förhand som kan effektivisera migreringsprocessen innan du kör SSMA:

  • Lägga till tabellindex och primärnycklar    Kontrollera att varje Access-tabell har ett index och en primärnyckel. FÖR SQL Server krävs att alla tabeller har minst ett index och att en länkad tabell har en primärnyckel om tabellen kan uppdateras.

  • Kontrollera primär-/sekundärnyckelrelationer    Kontrollera att relationerna baseras på fält med konsekventa datatyper och storlekar. SQL Server stöder inte kopplade kolumner med olika datatyper och storlekar i sekundärnyckelvillkor.

  • 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 steg.

  1. Stäng Access-databasen.

  2. Se till att aktuella användare som är anslutna till databasen också stänger databasen.

  3. Om databasen är i .mdb filformat tar du bort säkerhet på användarnivå.

  4. Säkerhetskopiera databasen. Mer information finns i Skydda dina data med säkerhetskopierings- och återställningsprocesser.

Tips    Överväg att installera Microsoft SQL Server Express-utgåvan på skrivbordet som har stöd för 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    Om möjligt använder du en fristående version av Access.

Kör SSMA

Microsoft tillhandahåller Microsoft SQL Server Migration Assistant (SSMA) för att underlätta migreringen. SSMA migrerar främst 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 ytterligare objekt i framtiden.

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

  1. Om du vill migrera en databas med SSMA laddar du först ned och installerar programvaran genom att dubbelklicka på den nedladdade MSI-filen. Se till att du installerar rätt 32- eller 64-bitarsversion för datorn.

  2. När du har installerat SSMA öppnar du det på skrivbordet, helst från datorn med Access-databasfilen.

    Du kan också öppna den på en dator som har åtkomst till Access-databasen från nätverket i en delad mapp.

  3. Följ anvisningarna i SSMA för att tillhandahålla grundläggande information som SQL Server-platsen, Access-databasen och objekt som ska migreras, anslutningsinformation och om du vill skapa länkade tabeller.

  4. Om du migrerar till SQL Server 2016 eller senare och vill uppdatera en länkad tabell lägger du till en radversionskolumn genom att välja Granska verktyg > Projektinställningar > Allmänt.

    Med rowversionsfältet undviker du postkonflikter. Access använder det här rowversionsfältet i en länkad SQL Server-tabell för att avgöra när posten senast uppdaterades. Om du lägger till rowversionsfältet i en fråga använder Access det för att markera raden igen efter en uppdateringsåtgärd. Det här förbättrar effektiviteten genom att undvika fel i skrivkonflikter och scenarier för borttagning av poster som kan inträffa när Access upptäcker olika resultat från den ursprungliga insändningen, till exempel med flyttalsnummerdatatyper och utlösare som ändrar kolumner. Undvik dock att använda rowversionsfältet i formulär, rapporter eller VBA-kod. Mer information finns i rowversion.

    Obs    Undvik att blanda ihop rowversion med tidsstämplar. Även om nyckelordets 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 datainmatning.

  5. Om du vill ange exakta datatyper väljer du Granska verktyg > Projektinställningar > Typmappning. 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 kopierar inte objekten direkt. SSMA innehåller en lista över följande objekt som ska migreras så att du kan bestämma om du vill flytta dem till SQL Server-databasen:

  • Tabeller och kolumner

  • Välj Frågor utan parametrar.

  • Primär- och sekundärnycklar

  • Index och standardvärden

  • Kontrollera villkor (tillåt kolumnegenskap med nollängd, kolumnverifieringsuttryck, tabellverifiering)

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

Om du konverterar databasobjekt tas objektdefinitionerna från Access-metadata, konverteras till motsvarande T-SQL-syntax (Transact-SQL) och läser sedan in den här informationen i projektet. Du kan sedan 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 att testa eller slutföra migreringen.

Länka tabeller

Överväg att installera den senaste versionen av SQL Server OLE DB- och ODBC-drivrutinerna i stället för att använda de inbyggda SQL Server-drivrutinerna som levereras med Windows. De nyare drivrutinerna går inte bara snabbare, utan de har stöd för 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 Driver 18 for SQL Server och Microsoft ODBC Driver 17 for 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 i stället för att använda de mer komplexa SQL Server-hanteringsverktygen.  Du kan fråga och redigera länkade data beroende på vilka behörigheter som konfigurerats av SQL Server-databasadministratören.

Obs    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 programmässigt använder anslutningssträngen 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 ändra

I följande avsnitt beskrivs vanliga problem du kan stöta på 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 T-SQL-syntax. Syntaxfel kan också kräva manuell konvertering av Access-specifika funktioner och datatyper till SQL Server-funktioner. 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 kompatibelt med datatypen BIGINT i SQL. Du kan använda den här datatypen för att effektivt beräkna stora tal, men det krävs att du använder Access 16-databasformatet (16.0.7812 eller senare) och fungerar bättre med 64-bitarsversionen av Access. Mer information finns i Använda datatypen Stort tal och Välja mellan 64- eller 32-bitarsversionen av Office.

Ja/Nej    Som standard konverteras en Access-kolumn av typen Ja/Nej 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 markera bitkolumnen för att ange egenskapen Tillåt null-värden till NO. I TSQL använder du satserna CREATE TABLE eller ALTER TABLE .

Datum och tid    Det finns flera datum- och tidsöverväganden:

  • Om databasens kompatibilitetsnivå är 130 (SQL Server 2016) eller högre och en länkad tabell innehåller en eller flera datum- eller datumtid2-kolumner, kan tabellen returnera meddelandet #deleted i resultatet. Mer information finns i Access länkade tabell till SQL-Server databas returnerar #deleted.

  • Använd datatypen Datum/tid i Access för att mappa till datatypen datetime. Använd den utökade datatypen Datum/tid i 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 ska du ta hänsyn till både tid och datum. Till exempel:

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

    • DatumBeställd Mellan 19-01-01 00:00:00 Och 19-31-01 23:59:59 inkluderar alla beställningar.

Bifogad fil   Datatypen Bifogad fil lagrar en fil i Access-databasen. I SQL Server finns det flera alternativ att tänka på. Du kan extrahera filerna från Access-databasen och sedan överväga att lagra länkar till filerna i SQL Server-databasen. Du kan också använda FILESTREAM, FileTables eller Remote BLOB Store (RBS) för att spara bifogade filer som lagras 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 Access-lösningen kan du fortfarande använda hyperlänkens beteende i formulär och rapporter om du anger egenskapen Hyperlänk för kontrollen till true.

Flervärdesfält    Access-flervärdesfältet 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 mappning av datatyper i Access och SQL Server finns i Jämföra datatyper.

Obs    Flervärdesfält konverteras inte.

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

Visual Basic

VBA stöds inte av SQL Server, men observera 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 ska dessa frågor konverteras till direktfrågor.

Användardefinierade funktioner i frågor    Microsoft Access-frågor stöder användningen 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-/rapportpostkä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 dessa funktioner manuellt och konvertera dem till lagrade procedurer på SQL Server.

Optimera prestanda

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

  • Kör små skrivskyddade frågor på klienten för snabb åtkomst.

  • Kör långa, lästa/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 klientserverdatabasmodellen

Mer information finns i Skapa en direktfråga.

Nedan följer 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 referensintegritetskod 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? Testa slutligen varje fråga för att säkerställa optimala prestanda.

Använda vyer i formulär och rapporter    Gör följande 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 läs-/skrivformulä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 viss rapport utan att påverka andra rapporter.

Minimera inläsning av data i ett formulär eller en rapport    Visa inte data förrän användaren ber om det. Se till exempel till att egenskapen recordsource är tom, att användarna väljer ett filter i formuläret och sedan fyller i egenskapen recordsource med filtret. Du kan också använda where-satsen i DoCmd.OpenForm och DoCmd.OpenReport för att visa exakt de poster som användaren behöver. Du kan inaktivera inspelningsnavigering.

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, som ibland kallas för en hybridfråga. Den här typen av fråga kräver fortfarande att Access hämtar alla SQL Server-data till den lokala datorn och sedan kör frågan, den kör inte frågan i SQL Server.

När ska lokala tabeller användas?    Överväg att använda lokala tabeller för data som sällan ändras, 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-frontend.

Mer information finns i Database Engine Tuning Advisor, Använda Analysera prestanda för att optimera en Access-databas och Optimera Microsoft Office Access-program som är länkade till SQL Server.

Se även

Migreringsguide för Azure-databas

Microsoft Data Migration Blog

Migrering, konvertering och storleksändring av Microsoft Access till SQL Server

Så här kan du dela med dig av en Access-skrivbordsdatabas

Behöver du mer hjälp?

Vill du ha fler alternativ?

Utforska prenumerationsförmåner, bläddra bland utbildningskurser, lär dig hur du skyddar din enhet med mera.

Communities hjälper dig att ställa och svara på frågor, ge feedback och få råd från experter med rika kunskaper.