OperationalError: no such table on initial syncdb

4.9k views Asked by At

I'm running syncdb to create an sqlite db. It was working until recently, and I don't see anything I've changed that would cause it to fail. Mostly I just changed some field names.

I have the following in models.py:

    class GC_User(models.Model):
        first_name = models.CharField(max_length=50)
        last_name = models.CharField(max_length=50)
        email = models.EmailField()
        wp_userID = models.PositiveSmallIntegerField(unique=True)

When I run syncdb after deleting the old db file, I get 150 lines of traceback, the last part of which is:

  File "C:\Python33\lib\site-packages\django\db\backends\util.py", line 53, in execute
    return self.cursor.execute(sql, params)
  File "C:\Python33\lib\site-packages\django\db\backends\sqlite3\base.py", line 450, in execute
    return Database.Cursor.execute(self, query, params)
django.db.utils.OperationalError: no such table: gameconapp_gc_user

Any thoughts about what might be causing this? I can put in more of the traceback if that would be helpful.

Thanks!

Update: After much digging, my partner determined that the problem was that the application's init.py was getting called. Since a routine there tried to access the GC_User table, it got the no such table error.

For now I've commented it out so I could run syncdb, and once we're in production we won't be resetting the db, but it's counterintuitive to me that the application is being initialized before the database is set up.

4

There are 4 answers

0
Tatsh On

I had this issue with a local SQLite 3 database. First I removed the file to be sure.

To solve this issue I used syncdb --no-initial-data then proceeded to use migrate with each app mentioned that was stated to not be synced:

./manage.py syncdb --no-initial-data
./manage.py migrate app1
./manage.py migrate app2
./manage.py migrate app3

There is no guaranteed order so this has to be done manually and just check what order works for you. In my case the simple_email_confirmation app had to be done first before anything else. After a few tries, ./manage.py migrate on its own should work.

0
Dric512 On

Although the discussion is a bit old, I had the same error because I was using ChoiceFields for which choices required a DB connection, for example:

class ExpenseIndividualForm(Form):
  """
  Form to get a specific expense (Individual)
  """
  date = forms.DateField(label=u"Date", initial=datetime.date.today())
  category = forms.ChoiceField(label=u"Catégorie", choices=get_individual_choices())
  employee = forms.ChoiceField(label=u"Utilisateur", choices=get_employee_choices())

for which functions get_individual_choices and get_employee_choice lookup into the database.

When I executed manage syncdb, it imports the classes and executes the initialization codes, which causes a very obscure error.

As proposed by arctelix, protecting the code of these functions inside try... except OperationalError solves the problem

0
Suhas Kashyap On

This error you have encountered since you have changed fields in your models. The table is created prior and is not changed there. So comment out the models and its corresponding and try ./manage.py makemigrations ./manage.py migrate --fake

Now remove the comment and run

./manage.py makemigrations ./manage.py migrate

This must help!

2
Arctelix On

Since you changed field names in the model I assume you are using south to handle the migrations. If that is the case: south does not initialize the database until after syncdb when you run migrate. Django loads all __init__ and models.py files when the sever starts. Any code in these files that requires database access needs to be wrapped in a try/except when they use south.

try:
    #code requiring database access here
except OperationalError:
    #close the database connection
    connection.close()

This way you don't have to ever worry about it again if for some reason you need to install with a fresh database again.

Or, since yours is not a reusable app, next time you have to start from scratch just remove the south migrations (they are only required for existing databases).