OperationalError: no such table on initial syncdb

Question

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.

You could initialize your application within `try/except` and fail silently if the database table isn't set yet. So you don't need to think about uncommenting on production changes — Thomas Schwärzl, Feb 21 '14 at 14:06

score 2 · Answer 1 · answered Aug 24 '14 at 11:34

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.

score 1 · Answer 2 · answered Mar 11 '14 at 21:56

1

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).

answered Mar 11 '14 at 21:56

Arctelix

4,478
3
27
38

I'm not at all familiar with south; I've been mostly teaching myself from the docs with lots of trial and error. It sounds useful. The code I had put in init.py really didn't need to be run on every startup, so I put it on a menu of tasks a manager or admin can run explicitly. – Beverly Block Mar 15 '14 at 06:00
@BeverlyBlock it's been a while and did not see your comment. South comes into play when you want to change model fields and NOT have to reset your database. It will migrate your existing database to match the new fields. It's super easy to use and will be part of django in the next release so definitely start using it. – Arctelix Dec 25 '14 at 21:25

score 1 · Answer 3 · answered Jun 26 '14 at 21:12

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

score 0 · Answer 4 · answered Feb 27 '19 at 20:31

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!

OperationalError: no such table on initial syncdb

4 Answers4

Linked