Sql-server – Access Data stored in SQL Server

According to the MySQL Documentation, the steps for the Migration Wizard should be

1. Connecting to the databases
2. Schemata Retrieval and Selection
3. Reverse Engineering
4. Object Selection
5. Migration
6. Manual Editing
7. Target Creation Options
8. Schema Creation
9. Create Target Results
10. Data Migration Setup
11. Bulk Data Transfer
12. Migration Report

Sounds like you got to Step 9. You have to make sure to setup Data Migration. Apparently, it is not automatic.

If you are having problems with the import, you are not alone. This has been a source of heartache for many. You may need to try :

• MySQL Migration Toolkit
• SQLyog

OK, there are several things that it could be but I'm not sure if we can determine which from here. These include the following:

1. AD propagation issues
2. AD caching "stickiness" on the target SQL Server
3. Domain Trust issues (particularly if the target server is in a different domain)
4. Windows Group membership/visibility issues
5. UAC blocking users access to certain groups needed for the new server
6. Kerberos issues (very common)
7. Etc...

And yes, dropping and re-adding the Users does seem to fix it in some of these cases, even though this should in theory never be needed because the SIDs should always match for Windows Users in transferred databases. It may be that the target SQL server simply lacks the same necessary server-level principal definitions as the original servers (and this as a side-effect creates explicit ones), or it may be that the act of adding the Login/user causes SQL Server to forcibly rerun the query and reload it's AD information for that user.

In any event, the real problem tends to be that dropping a user is a potentially disruptive and destructive act. It may work, but it may also cause some bad side-effects. Nonetheless, if you want to try that, then the best procs I know of for that are from Ted Krueger and they are located here: http://blogs.lessthandot.com/index.php/DataMgmt/DBAdmin/fixing-orphaned-database-users.

Other (possible) solutions that you could employ include:

• Automated procedure that does not drop the User, but does add and associate a server-level Windows Login for it.
• Create a Windows AD group for access to the database, add all of the users to that, and then add that to the SQL Server as a Login and Database as a User. (this is the recommended approach for managing large-scale access anyway).
• ...