Forums

Hello there. I'm having a problem with my app. I've cloned it from my repo and it worked fine on my and my pal's local machines, but it doesnt work here somehow... Im using virtualenv, setted up according to tutorial (a nice one, btw!), Django 1.6 and sqlite3. I've uploaded my db file (it was a real problem, cuz it's 200mb and upload process crashed at 5% every time, so i had to upload it with little rar-ed chuncks and unrar via console later - quite a trick for a junior dev like me), i checked my db file via sqlite console and everything seems ok, but when i try to open some page, that should hit the db, it crashes with error like:

OperationalError at /game_test/

no such table: game_app_game <<<--- i bet there is one!

Request Method: GET

Request URL: http://kulver.pythonanywhere.com/game_test/

Django Version: 1.6.5

Exception Type: OperationalError

Exception Value:

no such table: game_app_game

Exception Location: /home/Kulver/.virtualenvs/django16/lib/python2.7/site-packages/django/db/backends/sqlite3/base.py in execute, line 451

Index page with no db interaction loads well.

Help me please =)

Observing my sources is surely allowed. (Note that settings.py is overwitten by settings_local.py at the bottom of the script.)

i accidently found out that django was looking for the DB in the wrong place. i added a pull path to db:

DATABASES = {

    'default': {

        'ENGINE': 'django.db.backends.sqlite3',  # Add 'postgresql_psycopg2', 'mysql', 'sqlite3' or 'oracle'.

        'NAME': '/home/kulver/game_of_peoples/sqlite3.db',

         ...

and now i have another error: OperationalError at /game_test/ unable to open database file

Also tried to: chmod 777 sqlite3.db

Didnt help.

Problem solved. Looks like path/to/db is case-sensitive, what a surprise for me...

Glad you figured it out! yes, paths and filenames are case-sensitive on linux...

I seem to be having the same issue(newbie alert).. and i am curious to find out how you solved it, If you solved it thanks..

This kind of error can come from a number of things so it's hard to say specifically what's happening in your case. Are you using sqlite? If you'd using Django, have you run manage.py migrate?

Yes I am on sqlite @giles I have run manage. py migrate, added this 'django.contrib.sites' to my installed apps, and even changed the Database path to this

 DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.sqlite3',
        #'NAME': os.path.join(BASE_DIR, 'db.sqlite3'),
        'NAME': '/home/awanjila/my-first-blog/sqlite3.db',

    }
}

i am still getting that error.. Kindly assit..

[edit by admin: code formatting]

.

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.sqlite3',
        #'NAME': os.path.join(BASE_DIR, 'db.sqlite3'),
        'NAME': '/home/awanjila/my-first-blog/sqlite3.db',

    }
}

Database path to this

Can I take a look at your files? We can see them from our side, but we always ask for permission first.

Kindly do so,, You have all the permissions.. Thank you

Hi there,

I can see you're using a virtualenv. When you want to run commands like manage.py migrate, you have to remember to activate your virtualenv first. Something like this:

$ source my-venv/bin/activate
(my-venv) $  python manage.py migrate

Notice how the bash prompt -- $ -- changes and now has your virtualenv name in it (my-venv) $

Hi Harry, My virtualvenv is activated and i have also applied all my migrations inside it, but somehow i still get that error, what else could not be doing right?

(myvenv) wanjila@wanjila:~/djangogirls$ python manage.py migrate Operations to perform: Apply all migrations: sites, contenttypes, admin, auth, blog, sessions Running migrations: No migrations to apply.

Try deleting your database completely, and re-running the migration? (assuming you have no important data in there yet?)

I have the same issue. I've applied all migrations also.

Hi delores,

Have you checked all the troubleshooting steps listed in this thread?

• are you using the full, absolute path to your database? so, eg, /home/delores/myproject/mydb.sqlite, not just "mydb.sqlite".
• the path is case-sensitive, so check that too?
• did you definitely activate your virtualenv before running the migrate command?

Hi folks,

I am having a very similar error. Any help would be much appreciated. Pretty new to Django.

Running Django 2.0.3, just cloned my github files (works on my mac) in a virtual environment. I have run all migrations, etc and tried all the fixes I could find!

The error on the main page is:

OperationalError at /GR/
no such table: GR_intervention

My settings seem to be fine:

DATABASES = {
'default': {
    'ENGINE': 'django.db.backends.sqlite3',
    'NAME': os.path.join(BASE_DIR, 'db.sqlite3'),
}

}

I have tried reconfiguring them with the actual path name, etc. Tried re-running migrations, deleting Database and reinstalling, nuking the project and restarting!

Feel free to look through the project if you can.

Any help would be much appreciated guys Thanks so much

Follow UP: - I edited the WSGI file and it seems to be working!

Excellent, glad you got it working! What change did you need to make to the WSGI file?

Updating the WSGI file seems to have fixed it! Thanks Giles Here is my current WSGI file:

import os  import sys

path = os.path.expanduser('~/GR')
if path not in sys.path:
    sys.path.append(path)

os.environ['DJANGO_SETTINGS_MODULE'] = 'base.settings'

from django.core.wsgi import get_wsgi_application
from django.contrib.staticfiles.handlers import StaticFilesHandler
application = StaticFilesHandler(get_wsgi_application())

Prior my WSGI file had looked like:

import os
import sys

settings_path = '/home/resilientstudio/resilientstudio.pythonanywhere.com'
sys.path.insert(0, settings_path)

os.environ['DJANGO_SETTINGS_MODULE'] = 'base.settings'

from django.core.wsgi import get_wsgi_application
application = get_wsgi_application()

Ah, I see -- so it looks like it must have been looking at the wrong settings file previously...?

BTW although the Django StaticFilesHandler will work on PythonAnywhere, it's not super-efficient -- when you have the rest of your site working, you might want to take a look at this help page on using our built-in static files system, which can offload all of the work of serving your static assets to separate, faster processes.