Access
 sql >> Baza danych >  >> RDS >> Access

Pułapki, których należy unikać podczas korzystania z nowej wersji Microsoft SSMA 7.8

Pułapki, których należy unikać podczas korzystania z nowej wersji Microsoft SSMA 7.8

Firma Microsoft regularnie aktualizuje swoich Asystentów zarządzania SQL Server i właśnie zaktualizowała SSMA dla programu Access. Jednak nie możesz zobaczyć, co nowego w wersji 7.8 w ich oficjalnej dokumentacji. Najnowszą wersję programu SQL Server Migration Assistant (SSMA) w wersji 7.8 można pobrać stąd.

Wersja 7.8 jest znacznie łatwiejsza niż poprzednia, zwłaszcza w przypadku obsługi bitów 32/64, ale są pewne dziwactwa, którym się przyjrzymy.

Którą wersję mam pobrać?

SSMA musi mieć możliwość połączenia się z Access, a żeby to zrobić, musi mieć taką samą liczbę bitów, jak zainstalowany Access. Z tego powodu, jeśli masz 32-bitowy dostęp, powinieneś pobrać i zainstalować 32-bitową SSMA. Zauważ, że programy 32-bitowe są również określane jako „x86”. W przeciwnym razie należy zainstalować 64-bitową SSMA, aby działała z 64-bitowym dostępem.

Pozytywne opinie

Bardzo podobał mi się fakt, że SSMA od samego początku rozpoznało, że serwer jest na Azure SQL. Duży plus, kciuki w górę!

Jeśli korzystasz z Office365, musisz pobrać Access Database Engine 2010

Nie tak dawno musiałem zainstalować go na maszynie wirtualnej klienta i robiąc to, natknąłem się na te błędy / błędy.

W przypadku korzystania z usługi Office 365 należy pobrać pakiet redystrybucyjny aparatu bazy danych programu Microsoft Access 2010, aby usługa SSMA mogła odczytywać dane programu Access. Microsoft Access dostarczany z Office365 znajduje się w środowisku piaskownicy i dlatego nie jest dostępny dla SSMA.

Dodatkowe problemy, które możesz napotkać podczas korzystania z SSMA

Po zainstalowaniu pakietu redystrybucyjnego Microsoft Access Database Engine 2010 wystąpił kolejny błąd, również związany z Office 365. Ten wątek może pomóc!

Aby rozwiązać ten problem, odinstalowałem rejestrację 64-bitowego komponentu rozszerzalności pakietu Office 16 Click-to-Run – patrz obrazek poniżej.

Nie mogłem przenieść wszystkich tabel jednocześnie

Po zalogowaniu się do SQL Server wybrałem tabele, które chciałem zsynchronizować i uderzyłem Przycisk . Migracja nie odbyła się jednak dla wszystkich tabel, a tylko dla jednego! Mogłem więc migrować tylko jeden stół na raz, co jest okropne. Pomyśl o konieczności migracji ponad 100 tabel i zapytań, to nie był mój problem, ale wciąż… koszmar.

Musisz samodzielnie dodać klucze obce

Moja lokalna baza danych Access nie miała skonfigurowanych żadnych ograniczeń klucza obcego. Podczas migracji do SQL SSMA nie prosiło mnie o ustawienie ograniczeń dotyczących kluczy obcych. Technicznie nie jest to problem z samym narzędziem SSMA, ale coś, o czym należy pamiętać i sprawdzić podczas migracji, ponieważ, jak sądzę, oryginalna baza danych nie miała żadnych ograniczeń, więc musimy się upewnić, że ją egzekwujemy. SSMA powinno to zrobić za nas.

Jakie błędy lub błędy pojawiły się podczas korzystania z SSMA? Gdzie są kluczowe dla twojego projektu? Daj nam znać w komentarzach poniżej.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Microsoft Access DevCon w Wiedniu Austria 1–2 kwietnia 2017 r.

  2. Transformacja funkcjonalności klasy opakowującej

  3. 10 nietypowych porad dotyczących Microsoft Access 2019

  4. Ilu użytkowników może uzyskać dostęp do pomocy technicznej?

  5. Pytania, które należy zadać przed uruchomieniem bazy danych