Overføre en Access-database til SQL Server

Før du begynner

Avsnittene nedenfor inneholder bakgrunn og annen informasjon som hjelper deg med å komme i gang.

Om delte databaser

Alle Access-databaseobjekter kan enten være i én databasefil, eller de kan lagres i to databasefiler: en frontdatabase og en bakdatabase. Dette kalles oppdeling av databasen og er utformet for å forenkle deling i et nettverksmiljø. Bakdatabasefilen må bare inneholde tabeller og relasjoner. Frontfilen må bare inneholde alle andre objekter, inkludert skjemaer, rapporter, spørringer, makroer, VBA-moduler og koblede tabeller til bakdatabasen. Når du overfører en Access-database, ligner den på en delt database i den SQL Server fungerer som en ny serverdel for dataene som nå er plassert på en server.

Som et resultat av dette kan du fortsatt vedlikeholde frontdatabasen i Access med koblede tabeller til de SQL Server tabellene. Du kan effektivt utlede fordelene ved rask programutvikling som en Access-database gir, sammen med skalerbarheten til SQL Server.

SQL Server fordeler

Trenger du fortsatt litt overbevisende overføring til SQL Server? Her er noen ekstra fordeler å tenke på:

Flere samtidige brukere SQL Server kan håndtere mange flere samtidige brukere enn Access og minimerer minnekrav når flere brukere legges til.
Økt tilgjengelighet Med SQL Server kan du dynamisk sikkerhetskopiere, enten trinnvis eller fullført, databasen mens den er i bruk. Dermed trenger du ikke å tvinge brukere til å avslutte databasen for å ta sikkerhetskopi av data.
Høy ytelse og skalerbarhet Den SQL Server databasen fungerer vanligvis bedre enn en Access-database, spesielt med en stor database i terabytestørrelse. SQL Server behandler spørringer mye raskere og effektivt ved å behandle spørringer parallelt ved hjelp av flere opprinnelige tråder i én enkelt prosess for å håndtere brukerforespørsler.
Forbedret sikkerhet Ved hjelp av en klarert tilkobling integreres SQL Server med Windows systemsikkerhet for å gi én enkelt integrert tilgang til nettverket og databasen, og bruker det beste fra begge sikkerhetssystemene. Dette gjør det mye enklere å administrere komplekse sikkerhetsordninger. SQL Server er den ideelle lagringsplassen for sensitiv informasjon, for eksempel personnumre, kredittkortdata og adresser som er konfidensielle.
Umiddelbar gjenoppretting Hvis operativsystemet krasjer eller strømmen går ut, kan SQL Server automatisk gjenopprette databasen til en konsekvent tilstand i løpet av noen minutter og uten at det er noen databaseadministrator.
Bruk av VPN Access og virtuelle private nettverk (VPN) kommer ikke overens. Men med SQL Server kan eksterne brukere fortsatt bruke Access-frontdatabasen på et skrivebord og SQL Server bak VPN-brannmuren.
Azure SQL Server I tillegg til fordelene med SQL Server, tilbys dynamisk skalerbarhet uten nedetid, intelligent optimalisering, global skalerbarhet og tilgjengelighet, eliminering av maskinvarekostnader og redusert administrasjon.

Velg det beste Alternativet for Azure SQL Server

Hvis du overfører til Azure SQL Server, finnes det tre alternativer å velge mellom, hver med forskjellige fordeler:

Enkle database-/elastiske bassenger Dette alternativet har sitt eget sett med ressurser som administreres via en SQL Database-server. Én enkelt database er som en database i SQL Server. Du kan også legge til et elastisk utvalg, som er en samling av databaser med et delt sett med ressurser som administreres via SQL Database-serveren. De mest brukte SQL Server funksjonene er tilgjengelige med innebygde sikkerhetskopier, oppdateringer og gjenoppretting. Men det er ingen garantert nøyaktig vedlikeholdstid og overføring fra SQL Server kan være vanskelig.
Administrert forekomst Dette alternativet er en samling av system- og brukerdatabaser med et delt sett med ressurser. En administrert forekomst er som en forekomst av den SQL Server databasen som er svært kompatibilitet med SQL Server lokalt. En administrert forekomst har innebygde sikkerhetskopier, oppdateringer, gjenoppretting og er enkelt å overføre fra SQL Server. Det finnes imidlertid et lite antall SQL Server funksjoner som ikke er tilgjengelige, og ingen garantert nøyaktig vedlikeholdstid.
Azure Virtuell datamaskin Med dette alternativet kan du kjøre SQL Server i en virtuell maskin i Azure-skyen. Du har full kontroll over SQL Server-motoren og en enkel overføringsbane. Men du må administrere sikkerhetskopier, oppdateringer og gjenoppretting.

Hvis du vil ha mer informasjon, kan du se Velge databaseoverføringsbanen til Azure og Hva er Azure SQL?.

De første trinnene

Det er noen problemer du kan løse på forhånd som kan bidra til å strømlinjeforme overføringsprosessen før du kjører SSMA:

Legge til tabellindekser og primærnøkler Kontroller at hver Access-tabell har en indeks og en primærnøkkel. SQL Server krever at alle tabeller har minst én indeks og krever at en koblet tabell har en primærnøkkel hvis tabellen kan oppdateres.
Kontrollere primær-/sekundærnøkkelrelasjoner Kontroller at disse relasjonene er basert på felt med konsekvente datatyper og -størrelser. SQL Server støtter ikke sammenføyde kolonner med ulike datatyper og størrelser i sekundærnøkkelbegrensninger.
Fjerne Vedlegg-kolonnen SSMA overfører ikke tabeller som inneholder Vedlegg-kolonnen.

Før du kjører SSMA, må du utføre følgende første trinn.

Lukk Access-databasen.
Kontroller at gjeldende brukere som er koblet til databasen, også lukker databasen.
Hvis databasen er i .mdb filformat, fjerner du sikkerhet på brukernivå.
Sikkerhetskopier databasen. Hvis du vil ha mer informasjon, kan du se Beskytt dataene med sikkerhetskopierings- og gjenopprettingsprosesser.

Tips Vurder å installere Microsoft SQL Server Express versjonen på skrivebordet som støtter opptil 10 GB, og som er en gratis og enklere måte å kjøre gjennom og kontrollere overføringen på. Når du kobler til, bruker du LocalDB som databaseforekomst.

Tips Hvis det er mulig, kan du bruke en frittstående versjon av Access. Hvis du bare kan bruke Microsoft 365, kan du bruke Access 2010-databasemotoren til å overføre Access-databasen når du bruker SSMA. Hvis du vil ha mer informasjon, kan du se Microsoft Access Database Engine 2010 Redistributable.

Kjør SSMA

Microsoft tilbyr Microsoft SQL Server Migration Assistant (SSMA) for å gjøre overføring enklere. SSMA overfører hovedsakelig tabeller og utvalgsspørringer uten parametere. Skjemaer, rapporter, makroer og VBA-moduler konverteres ikke. Metadatautforskeren for SQL Server viser Access-databaseobjekter og SQL Server objekter, slik at du kan se gjennom gjeldende innhold i begge databasene. Disse to tilkoblingene lagres i overføringsfilen hvis du bestemmer deg for å overføre flere objekter i fremtiden.

Obs! Overføringsprosessen kan ta litt tid, avhengig av størrelsen på databaseobjektene og mengden data som må overføres.

Hvis du vil overføre en database ved hjelp av SSMA, må du først laste ned og installere programvaren ved å dobbeltklikke den nedlastede MSI-filen. Kontroller at du installerer riktig 32- eller 64-biters versjon for datamaskinen.
Når du har installert SSMA, åpner du det på skrivebordet, fortrinnsvis fra datamaskinen med Access-databasefilen.

Du kan også åpne den på en maskin som har tilgang til Access-databasen fra nettverket i en delt mappe.
Følg instruksjonene i SSMA for å gi grunnleggende informasjon, for eksempel SQL Server plassering, Access-databasen og objekter som skal overføres, tilkoblingsinformasjon og om du vil opprette koblede tabeller.
Hvis du overfører til SQL Server 2016 eller nyere og vil oppdatere en koblet tabell, kan du legge til en rowversion-kolonne ved å velge Se gjennom verktøy > Prosjektinnstillinger > Generelt.

Rowversion-feltet bidrar til å unngå postkonflikter. Access bruker dette rowversion-feltet i en SQL Server koblet tabell til å fastslå når posten sist ble oppdatert. Hvis du legger til rowversion-feltet i en spørring, bruker Access det til å merke raden på nytt etter en oppdateringsoperasjon. Dette forbedrer effektiviteten ved å unngå skrivekonfliktsfeil og registrere slettingsscenarioer som kan skje når Access oppdager forskjellige resultater fra den opprinnelige innsendingen, for eksempel kan oppstå med datatyper for flyttall og utløsere som endrer kolonner. Unngå imidlertid å bruke rowversion-feltet i skjemaer, rapporter eller VBA-kode. Hvis du vil ha mer informasjon, kan du se rowversion.

Obs! Unngå forvirrende rowversion med tidsstempler. Selv om tidsstempelet for nøkkelord er et synonym for rowversion i SQL Server, kan du ikke bruke rowversion som en måte å tidsstempele en dataoppføring på.
Hvis du vil angi nøyaktige datatyper, velger du Se gjennom verktøy > Prosjektinnstillinger > Typetilordning. Hvis du for eksempel bare lagrer engelsk tekst, kan du bruke varchar i stedet for datatypen nvarchar .

Konvertere objekter

SSMA konverterer Access-objekter til SQL Server objekter, men objektene kopieres ikke umiddelbart. SSMA inneholder en liste over følgende objekter som skal overføres, slik at du kan bestemme om du vil flytte dem til SQL Server database:

Tabeller og kolonner
Velg spørringer uten parametere.
Primærnøkler og sekundærnøkler
Indekser og standardverdier
Kontroller begrensninger (tillat kolonneegenskap med null lengde, kolonnevalideringsregel, tabellvalidering)

Som en anbefalt fremgangsmåte kan du bruke SSMA-vurderingsrapporten, som viser konverteringsresultatene, inkludert feil, advarsler, informasjonsmeldinger, tidsestimater for å utføre overføringen, og individuelle feilrettingstrinn som skal utføres før du faktisk flytter objektene.

Konvertering av databaseobjekter tar objektdefinisjonene fra Access-metadataene, konverterer dem til tilsvarende Transact-SQL -syntaks (T-SQL), og laster deretter inn denne informasjonen i prosjektet. Deretter kan du vise SQL Server eller SQL Azure objekter og deres egenskaper ved hjelp av SQL Server eller SQL Azure Metadata Explorer.

Følg denne veiledningen for å konvertere, laste inn og overføre objekter til SQL Server.

Tips Når du har overført Access-databasen, lagrer du prosjektfilen for senere bruk, slik at du kan overføre dataene på nytt for testing eller endelig overføring.

Koble tabeller

Vurder å installere den nyeste versjonen av SQL Server OLE DB- og ODBC-drivere i stedet for å bruke de opprinnelige SQL Server driverne som leveres med Windows. Ikke bare er de nyere driverne raskere, men de støtter nye funksjoner i Azure SQL som de forrige driverne ikke gjør. Du kan installere driverne på hver datamaskin der den konverterte databasen brukes. Hvis du vil ha mer informasjon, kan du se Microsoft OLE DB Driver 18 for SQL Server og Microsoft ODBC Driver 17 for SQL Server.

Når du har overført Access-tabellene, kan du koble til tabellene i SQL Server som nå er vert for dataene. Kobling direkte fra Access gir deg også en enklere måte å vise dataene dine på, i stedet for å bruke de mer komplekse SQL Server administrasjonsverktøyene. Du kan spørre etter og redigere koblede data avhengig av tillatelsene som er konfigurert av SQL Server databaseadministrator.

Obs! Hvis du oppretter en DSN for ODBC når du kobler til SQL Server-databasen under koblingsprosessen, kan du enten opprette samme DSN på alle maskiner som bruker det nye programmet, eller bruke tilkoblingsstreng som er lagret i DSN-filen programmatisk.

Hvis du vil ha mer informasjon, kan du se Koble til eller importere data fra en Azure SQL Server-database og importere eller koble til data i en SQL Server-database.

Tips Ikke glem å bruke Tabellkoblingsbehandling i Access til å oppdatere og koble tabeller på nytt. Hvis du vil ha mer informasjon, kan du se Behandle koblede tabeller.

Teste og revidere

Avsnittene nedenfor beskriver vanlige problemer du kan støte på under overføringen, og hvordan du håndterer dem.

Spørringer

Bare utvalgsspørringer konverteres. andre spørringer er ikke det, inkludert utvalgsspørringer som tar parametere. Noen spørringer kan ikke konverteres fullstendig, og spørringsfeil i SSMA-rapporter under konverteringsprosessen. Du kan manuelt redigere objekter som ikke konverteres ved hjelp av T-SQL-syntaks. Syntaksfeil kan også kreve manuell konvertering av Access-spesifikke funksjoner og datatyper til SQL Server. Hvis du vil ha mer informasjon, kan du se Sammenligne Access SQL med SQL Server TSQL.

Datatyper

Access og SQL Server har lignende datatyper, men vær oppmerksom på følgende potensielle problemer.

Stort tall Datatypen Stort tall lagrer en ikke-monetær numerisk verdi og er kompatibel med sql bigint-datatypen. Du kan bruke denne datatypen til effektivt å beregne store tall, men den krever at du bruker Access 16 (16.0.7812 eller nyere) ACCDB-databasefilformatet og yter bedre med 64-bitersversjonen av Access. Hvis du vil ha mer informasjon, kan du se Bruke datatypen Stort tall og Velge mellom 64-biters- eller 32-bitersversjonen av Office.

Ja/Nei Som standard konverteres en Ja/Nei-kolonne i Access til et SQL Server bit-felt. For å unngå postlåsing må du kontrollere at bitfeltet er satt til å forby NULL-verdier. I SSMA kan du velge bitkolonnen for å angi tillat nullverdier-egenskapen til NEI. Bruk setningene CREATE TABLE eller ALTER TABLE i TSQL.

Dato og klokkeslett Det finnes flere vurderinger av dato og klokkeslett:

Hvis kompatibilitetsnivået for databasen er 130 (SQL Server 2016) eller høyere, og en koblet tabell inneholder én eller flere datetime- eller datetime2-kolonner, kan tabellen returnere meldingen #deleted i resultatene. Hvis du vil ha mer informasjon, kan du se Access-koblet tabell til SQL-Server database returnerer #deleted.
Bruk datatypen Access-dato/klokkeslett til å tilordne datatypen datetime. Bruk datatypen Access Date/Time Extended til å tilordne datatypen datetime2 som har et større dato- og klokkeslettområde. Hvis du vil ha mer informasjon, kan du se Bruke datatypen Date/Time Extended.
Når du spør etter datoer i SQL Server, tar du hensyn til klokkeslettet og datoen. Eksempel:
- DateOrdered Between 1/1/19 and 1/31/19 may not include all orders.
- DateOrdered Between 1/1/19 00:00:00 AM And 1/31/19 11:59:59 PM does include all orders.

Vedlegg Datatypen Vedlegg lagrer en fil i Access-databasen. I SQL Server har du flere alternativer å vurdere. Du kan pakke ut filene fra Access-databasen og deretter vurdere å lagre koblinger til filene i SQL Server-databasen. Du kan også bruke FILESTREAM, FileTables eller Remote BLOB Store (RBS) til å beholde vedlegg som er lagret i SQL Server-databasen.

Hyperkobling Access-tabeller har hyperkoblingskolonner som SQL Server ikke støtter. Som standard konverteres disse kolonnene til nvarchar(max)-kolonner i SQL Server, men du kan tilpasse tilordningen for å velge en mindre datatype. I Access-løsningen kan du fortsatt bruke virkemåten for hyperkoblinger i skjemaer og rapporter hvis du angir hyperkoblingsegenskapen for kontrollen til sann.

Flerverdifeltet Feltet med flere verdier i Access konverteres til SQL Server som et ntext-felt som inneholder verdisettet med skilletegn. Ettersom SQL Server ikke støtter en datatype med flere verdier som gjenspeiler en mange-til-mange-relasjon, kan ytterligere utforming og konvertering være nødvendig.

Hvis du vil ha mer informasjon om tilordning av Access og SQL Server datatyper, kan du se Sammenligne datatyper.

Obs! Felt med flere verdier konverteres ikke.

Hvis du vil ha mer informasjon, kan du se dato- og klokkesletttyper, streng- og binærtyper og numeriske typer.

Visual Basic

Selv om VBA ikke støttes av SQL Server, må du være oppmerksom på følgende mulige problemer:

VBA-funksjoner i spørringer Access-spørringer støtter VBA-funksjoner på data i en spørringskolonne. Access-spørringer som bruker VBA-funksjoner, kan imidlertid ikke kjøres på SQL Server, så alle forespurte data sendes til Microsoft Access for behandling. I de fleste tilfeller bør disse spørringene konverteres til direktespørringer.

Brukerdefinerte funksjoner i spørringer Microsoft Access-spørringer støtter bruk av funksjoner som er definert i VBA-moduler for å behandle data som sendes til dem. Spørringer kan være frittstående spørringer, SQL-setninger i skjema-/rapportpostkilder, datakilder for kombinasjonsbokser og listebokser i skjemaer, rapporter og tabellfelt og standard- eller valideringsregeluttrykk. SQL Server kan ikke kjøre disse brukerdefinerte funksjonene. Du må kanskje manuelt utforme disse funksjonene og konvertere dem til lagrede prosedyrer på SQL Server.

Optimaliser ytelse

Den viktigste måten å optimalisere ytelsen med den nye SQL Server på, er å bestemme når du skal bruke lokale eller eksterne spørringer. Når du overfører dataene til SQL Server, flytter du også fra en filserver til en klient-server-databasemodell for databehandling. Følg disse generelle retningslinjene:

Kjør små, skrivebeskyttede spørringer på klienten for raskest tilgang.
Kjør lange, lese-/skrive-spørringer på serveren for å dra nytte av den større prosessorkraften.
Minimer nettverkstrafikk med filtre og aggregering for å overføre bare dataene du trenger.

Optimaliser ytelsen i klientserverdatabasemodellen

Hvis du vil ha mer informasjon, kan du se Opprette en direktespørring.

Følgende er flere, anbefalte retningslinjer.

Plassere logikk på serveren Programmet kan også bruke visninger, brukerdefinerte funksjoner, lagrede prosedyrer, beregnede felt og utløsere til å sentralisere og dele programlogikk, forretningsregler og policyer, komplekse spørringer, datavalidering og referanseintegritetskode på serveren, i stedet for på klienten. Spør deg selv, kan denne spørringen eller oppgaven utføres på serveren bedre og raskere? Til slutt tester du hver spørring for å sikre optimal ytelse.

Bruke visninger i skjemaer og rapporter Gjør følgende i Access:

Bruk en SQL-visning for et skrivebeskyttet skjema og en SQL-indeksert visning for et lese-/skriveskjema som postkilde for skjemaer.
Bruk en SQL-visning som postkilde for rapporter. Du kan imidlertid opprette en egen visning for hver rapport, slik at du enklere kan oppdatere en bestemt rapport uten å påvirke andre rapporter.

Minimere innlasting av data i et skjema eller en rapport Ikke vis data før brukeren ber om det. La for eksempel postkildeegenskapen være tom, få brukere til å velge et filter i skjemaet, og fyll deretter postkildeegenskapen med filteret. Du kan også bruke where-setningsdelen i DoCmd.OpenForm og DoCmd.OpenReport til å vise nøyaktig hvilke post(er) brukeren trenger. Vurder å deaktivere postnavigasjon.

Vær forsiktig med heterogene spørringer Unngå å kjøre en spørring som kombinerer en lokal Access-tabell og SQL Server koblet tabell, noen ganger kalt en hybridspørring. Denne typen spørring krever fremdeles at Access laster ned alle SQL Server data til den lokale maskinen, og deretter kjører spørringen, kjører den ikke spørringen i SQL Server.

Når du skal bruke lokale tabeller Vurder å bruke lokale tabeller for data som sjelden endres, for eksempel listen over delstater eller provinser i et land eller område. Statiske tabeller brukes ofte til filtrering og kan yte bedre på Access-frontserveren.

Hvis du vil ha mer informasjon, kan du se Rådgiver for databasemotorjustering, Bruke Ytelsesanalyse til å optimalisere en Access-database og optimalisere Microsoft Office Access-programmer som er koblet til SQL Server.