# There is already an object named 'schema\_migrations' in the

**URL:** <https://www.ruby-forum.com/t/there-is-already-an-object-named-schema-migrations-in-the/158425>\
**Category:** Rails\
**Created:** [January 23, 2009, 6:37am UTC](https://www.ruby-forum.com/t/there-is-already-an-object-named-schema-migrations-in-the/158425 "2009-01-23T06:37:22Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![blewis](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/c57346/32.png) [@blewis](https://www.ruby-forum.com/u/blewis)\
**Post date:** [January 23, 2009, 6:37am UTC](https://www.ruby-forum.com/t/there-is-already-an-object-named-schema-migrations-in-the/158425/1 "2009-01-23T06:37:22Z")

</div>

Hi I have an unusual one, hoping one of you geniuses can give me a hint  
as I don’t know where else to look.

I’m running an combo of Rails/Sql Server (I know, I know, legacy though)  
using Ubuntu/UnixODBC/FreeTDS/activerecord-odbc-adapter. The app seems  
to be talking to the DB perfectly. When I have a clean database, I’m  
able to run rake db:migrate and everything generates correctly. However,  
if I add another migration and run the migrations again, I get this  
error:

rake aborted!  
S0001 (2714) [unixODBC][FreeTDS][SQL Server]There is already an object  
named ‘schema\_migrations’ in the database.

Which, of course there is! I’m just attempting to add a new table,  
column, etc. The only way I’ve been able to add migrations thus far is  
to wipe the database and rerun the migrations from scratch. Obviously  
can’t keep that up forever.

with a --trace argument, I do notice that it thinks I’m running them for  
the first time. Where does the rake task look to decide this?

\*\* Invoke db:migrate (first\_time)  
\*\* Invoke environment (first\_time)

Thanks so much for any help you can provide!

-Ben

---

<div class="post-metadata">

**Author:** ![blewis](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/c57346/32.png) [@blewis](https://www.ruby-forum.com/u/blewis)\
**Post date:** [January 23, 2009, 7:28am UTC](https://www.ruby-forum.com/t/there-is-already-an-object-named-schema-migrations-in-the/158425/2 "2009-01-23T07:28:40Z")

</div>

Hi Ben,

I think there should be a table generated with name as schema\_info in  
your database.

this table will have version as the column that contain the number of  
the latest migration file you executed.

next time when you run migrations it will run all migration files  
having number above the version number mentioned in schema\_info table.

try to trace the schema\_info table as above behavior.

Thanks,  
Piyush.

try to trace it and  
On Jan 23, 10:37 am, Ben L. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)

---

<div class="post-metadata">

**Author:** ![blewis](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/c57346/32.png) [@blewis](https://www.ruby-forum.com/u/blewis)\
**Post date:** [January 23, 2009, 5:01pm UTC](https://www.ruby-forum.com/t/there-is-already-an-object-named-schema-migrations-in-the/158425/3 "2009-01-23T17:01:52Z")

</div>

Thanks for the response Piyush,

Actually the schema\_info table was replace by the schema\_migrations  
table in later versions of rails (2.0+ I think?). When looking at the  
schema\_migrations table, I do see all the migrations to date listed.  
Rails seems to be making the decision that this is the first time the  
migrations have run from some local setting.

---

<div class="post-metadata">

**Author:** ![blewis](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/c57346/32.png) [@blewis](https://www.ruby-forum.com/u/blewis)\
**Post date:** [January 24, 2009, 3:33pm UTC](https://www.ruby-forum.com/t/there-is-already-an-object-named-schema-migrations-in-the/158425/4 "2009-01-24T15:33:49Z")

</div>

The “first\_time” just means that’s the first time the task is being  
invoked in this rake run, I believe. Doesn’t mean it thinks you’re  
running migrations for the first time ever.

I encountered this error with a plugin that had not been upgraded to be  
compatible with Rails 2.x. I would recommend running rake --trace  
again, but then look at the call stack that gets dumped to figure out  
exactly which task is causing this error, and perhaps what plugin may or  
may not be related.

dwh

---

<div class="post-metadata">

**Author:** ![blewis](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/c57346/32.png) [@blewis](https://www.ruby-forum.com/u/blewis)\
**Post date:** [February 9, 2009, 10:41pm UTC](https://www.ruby-forum.com/t/there-is-already-an-object-named-schema-migrations-in-the/158425/5 "2009-02-09T22:41:38Z")

</div>

Looks like there was another post with a similar issue, just figured I’d  
cross-reference in case someone actually does still want to use the  
activerecord-odbc-adapter.

---

<div class="post-metadata">

**Author:** ![blewis](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/c57346/32.png) [@blewis](https://www.ruby-forum.com/u/blewis)\
**Post date:** [January 26, 2009, 6:59pm UTC](https://www.ruby-forum.com/t/there-is-already-an-object-named-schema-migrations-in-the/158425/6 "2009-01-26T18:59:41Z")

</div>

I got this working finally.

I decided to try the rails-sqlserver-2000-2005-adapter gem rather than  
the activerecord-odbc-adapter I was using before. I then had change the  
connection type in database.yml from:  
adapter:ODBC  
to:  
adapter:sqlserver  
mode:ODBC

This seems to have fixed the issue, and give me the added bonus of the  
sql output to the console, which I wasn’t getting with the other  
adapter.

thanks for all your input!

-Ben