That's really good to know and it makes sense. To verify, this is with the activerecord-odbc-adapter, correct?
On Mon, Jan 12, 2009 at 7:39 AM, Ben <[email protected]> wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
