syncdb attempts to create the already created db tables again

[aatif]

When I try to run manage.py syncdb, the database raises an error that "table xyz already exists". How can I set it to check table duplication while synching? Remember that I am not running syncdb command the first time. So some of the required tables have been created already.

Django people may close this ticket saying "you should discuss it in the mailing list", I checked the mailing list for this problem but they say it should be reported as a bug. Tell me if it is fixed.

[Ramiro Morales]

If you want it to be a bug report, you will need to provide more information than what you've provided, the report is too vague and if you don help people to help you with a bit of effort on you part then somebody is going to close this ticket too. Some things you might want to provide and homework you might want to get done:

• What DB backend are you using?
• If applicable, what version of RDBMS?
• What are application and model names, the table names?
• What's the table affected? one corresponding to a model in your app or to another application?
• Reproduce from the start and describe the exact work flow you are following from creating the project/application to the point where you get the error message
• Describe how the already existing table was created (manually? by another RDBMS user?, by syncdb itself?)
• Paste the exact error message

Also, create a minimal test case that reproduces what you are seeing (that is, take the project and remove things so it is not contains extra, un-related stuff) and paste the relevant file fragments here (DATABASE_*, INSTALLLED_APPS settings, models.py, ...)

When you create a ticket there is a list of recommendations in the first page, one of them links to a ​bug reporting guidelines page where all the above characteristics of a good bug report are described.

[Karen Tracey]

What mailing list did you check? I don't see anything recent about an error like this on django-users?

The only case I am aware of when syncdb may do this is described in this mailing list thread:

​http://groups.google.com/group/django-users/browse_thread/thread/9b3830c369a97f1a/bdfcba336a19d7e9

and there is no recommendation report it as a bug there. There does happen to be, however, a ticket open for that case, #9116, which mentions ways to avoid the problem without changing Django code. So I'm going to close this as a dup of that. If you've got a different case, as Ramiro says you'll need to supply a good bit more specifics of your configuration and what leads up to the error before anyone can help. In general syncdb does not attempt to re-create tables that already exist, so until you give us some specifics on what's special about your case nobody can really do anything to help.

[aatif]

• What DB backend are you using?

MySQL

• If applicable, what version of RDBMS?

-

• What are application and model names, the table names?

Application name is 'People', model name is 'Person', table name is 'people_person'.

• What's the table affected? one corresponding to a model in your app or to another application?

in my application

• Reproduce from the start and describe the exact work flow you are following from creating the project/application to the point where you get the error message

I was following a step by step session of a book on Django, created a project, added an application, syncdb (people_person was created here), added admin interface to the project, configuring url for admin, tried to syncdb again, and My SQL popped error (table "people_person already exists").

• Describe how the already existing table was created (manually? by another RDBMS user?, by syncdb itself?)

syncdb itself

• Paste the exact error message

errorvalue_mysql_exceptions.OperationalError: (1050, "Table 'people_person' already exists")

[Karen Tracey]

This is exactly the situation in the thread I pointed to above, down to using the same book. There are ways you can prevent the error that are detailed in that thread, please read it and pick whichever you like best. Ticket #9116 is already open to cover looking into changing Django to be aware of this particular database peculiarity, so I'm closing this again as a dup of that because we don't need two tickets tracking the same thing.