March 24, 2017 at 6:54 pm
IIRC, for logs look at the XML files in \SSMAProjects\SqlMigrationname\report folder.
Another issue I find is that Access allows you to use field names that are reserved words that cause issues with MS SQL Server. If the person who created the database did not create Primary keys for all tables then I would not be surprised is they also use keywords for field names.
FWIW:
I had a project like this where the Access tables were not very SQL Server "friendly". SSMA really had a horrible time with it. I finally decided to manually create all the table in the SQL server properly. I used append queries to import the data. This way many years ago when I was first learning to use SQL Server as an Access back end. SSMA back then also was not as good as it is now.
March 29, 2017 at 2:53 pm
I decided to try upsizing using the Access application Database Tools option. For my first attempt I used a SQL server 2012 server and created a new database. It was partially successful. As I described in a previous posting, a significant number of the access tables did not have primary keys. Those tables were migrated to SQL, but were flagged as read only. A few other tables were not migrated at all with no indication why. This posting helped a great deal. https://docs.microsoft.com/en-us/sql/ssma/access/incompatible-access-features-accesstosql
The problem I experienced were invalid or out of range date fields in the access application. Once those fields were corrected, the upsizing to SQL migration was successful. That was nice.
When the snows fall and the white winds blow,The lone wolf dies but the pack survives.
Once you've accepted your flaws, no one can use them against you.
Viewing 2 posts - 16 through 16 (of 16 total)
You must be logged in to reply to this topic. Login to reply