Gropar att undvika när du använder den nya Microsoft SSMA version 7.8

Microsoft har uppdaterat sina SQL Server Management Assistants regelbundet, och de har precis uppdaterat SSMA för Access. Du kan dock inte se vad som är nytt för 7.8 i deras officiella dokumentation. Den senaste versionen av SQL Server Migration Assistant (SSMA) version 7.8 kan laddas ned här.

7.8-versionen är mycket enklare än tidigare, särskilt med hantering av 32/64 bitar, men det finns egenheter som vi kommer att titta på.

Vilken version ska jag ladda ner?

SSMA måste kunna ansluta till Access och för att göra det måste det vara samma antal bitar som den installerade Access. Av den anledningen, om du har 32-bitars åtkomst, bör du ladda ner och installera 32-bitars SSMA. Observera att 32-bitars program också kallas "x86". Annars bör du installera 64-bitars SSMA för att fungera med 64-bitars åtkomst.

Positiv feedback

Jag älskade det faktum att SSMA redan från början kände igen att servern var på Azure SQL. Stort plus, tummen upp!

När du använder Office365 måste du ladda ner Access Database Engine 2010

För inte länge sedan behövde jag installera det på en klients virtuella dator och när jag gjorde det stötte jag på dessa fel/buggar.

När du kör Office 365 måste du ladda ner Microsoft Access Database Engine 2010 Redistributable så att SSMA kan läsa din Access-data. Microsoft Access som följer med Office365 är i en sandlådemiljö och därför inte tillgänglig för SSMA.

Ytterligare problem du kan stöta på med SSMA

Efter att ha installerat Microsoft Access Database Engine 2010 Redistributable fick jag ett annat fel, även relaterat till Office 365. Den här tråden kan hjälpa!

För att lösa problemet avinstallerade jag Office 16 Click-To-Run Extensibility Component 64-bit Registration – se bilden nedan.

Jag kunde inte migrera alla tabeller samtidigt

Efter att ha loggat in på SQL Server valde jag de tabeller som jag ville synkronisera och tryckte på  knapp. Migreringen ägde dock inte rum för alla bord, utan bara ett! Så jag kunde bara migrera ett bord åt gången, vilket är hemskt. Tänk på att behöva migrera över 100 tabeller och frågor, det var inte mitt problem men ändå ... en mardröm.

Du måste lägga till främmande nycklar själv

Min lokala Access-databas hade inga begränsningar för främmande nyckel. När jag migrerade till SQL bad SSMA mig inte att ställa in begränsningar för främmande nyckel. Tekniskt sett inte ett problem med själva SSMA-verktyget, men något att vara medveten om och att kontrollera vid migrering eftersom, jag antar, den ursprungliga databasen inte hade några begränsningar, så vi måste se till att vi tillämpar den. SSMA borde göra det åt oss.

Vilka buggar eller fel fick du när du använde SSMA? Var är de avgörande för ditt projekt? Låt oss veta i kommentarerna nedan.