Ok. After further investigation it turns out there isn't a problem with the adapter, apart from lack of obvious documentation.
The adapter detects if the SQL Server database uses 'security schemas' (SQL Server 2005/08) and if it does it enforces those schemas which was the cause of my problems. I'd advise that when creating a SQL Server 2005/08 database to be used with Rails, you create a security schema named identically to the user that is going to be running the migrations and assign it to that user; note, this should be done before running any migrate tasks. If I'm correct, the result of this is that ONLY that user can run migrations properly. Under most circumstances a user is assigned the 'dbo' schema. So I ran the migrate for the first time and the tables were associated with the dbo schema. The second time I ran the migrate the schemas are enforced and because of this and the way the adapter works, it wasn't able to properly build the list of 'already existing tables'. So because it hadn't detected the existing tables, it tried to create them again and that is where the second migration was falling over. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
