Solved Access-SqlAzure migration: stuck

Etxezarreta

Member
Local time
, 00:55
Joined
Apr 13, 2020
Messages
175
Hello,
I have been trying to migrate tables form Access to SqlAzure: I always crash on "SNAC" versions error messages, even though I have the latest one.
We have been trying to sort it out with the microsoft guys (SqlAzure and Access people) for three days.
I have Office 365x64, the connection to SqlAzure works well, but no way to end the migration: it stops.
The Microsof guy tried with the same configuration, it does work.
I bought a new computer, I downloaded office 365 Prox64, SSMS, SSMA, tied again-> same error message.
As they have only limited experience of Access BE migrated to SqlAzure at Microsoft, maybe one you guys has already faced the same kind of error.
Thanks a lot in advance for sharing your experience.
Etxe.
 
After uninstalling Office 365, I tried to install RunAccess2016: it works.
When I re install Office 365, whatever the way I install it (Click to Run or with the installer), there is no way to choose "Link tables" in the SSMA, or the message "you need to install a newer version of SNAC" appears.
I am a bit desperate, the MSN supports techs are speechless.
Thanks for your help.
Etxe.
 
How many tables are you trying to migrate?
If it's not many it may be easier to do some work arounds?
 
You could possibly use docmd.TransferDatabase acExport to move them using the ODBC database type.
 
You could possibly use docmd.TransferDatabase acExport to move them using the ODBC database type.
I see, something like
DoCmd.TransferDatabase acExport, "ODBC Database", "ODBC;Driver=ODBC Driver 13 for SQL server;Server=*******;Database=****;Uid=***;Pwd=***;Encrypt=yes;TrustServerCertificate=no;Connection Timeout=30;", acTable, "MyAccessTestTable", "ServerTestTable", , False

When this is done for every table, what is the next step?
 
Yup, that looks good.

Then after making at least 2 backups...

Delete the tables from your database.
Link the Azure tables back in, rename them to the original name, Bob should be your uncle.

Personally, I would create a local table of all your current table names. Add a column for the remote table name. You can then do some clever stuff later.
All the linked table names will be of the sort:

tblCurrentName changes to > dbo_tblCurrentName

You can write a little function to rename them automatically should you be inclined.
 

Users who are viewing this thread

Back
Top Bottom