Opened 11 years ago

Closed 7 years ago

#6338 closed New feature (duplicate)

Better error message on sqlite3 failure

Reported by: simeon Owned by: simeon
Component: Database layer (models, ORM) Version: master
Severity: Normal Keywords:
Cc: Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: yes
Easy pickings: yes UI/UX: no


I recently updgraded my OS and restored my django projects from backup. The django shell worked but when I ran dbshell
I got a exception ending in

  File "/usr/lib/python2.5/site-packages/django/db/", line 48, in <lambda>
    runshell = lambda: _import_database_module(_import_path, "client").runshell()
  File "/usr/lib/python2.5/site-packages/django/db/backends/sqlite3/", line 6, in runshell
    os.execvp('sqlite3', args)
  File "/usr/lib/python2.5/", line 354, in execvp
    _execvpe(file, args)
  File "/usr/lib/python2.5/", line 392, in _execvpe
    func(fullname, *argrest)
OSError: [Errno 2] No such file or directory

The astute pythoner notes the 3rd line up tries to execute a call to sqlite3 and the actual error message "No such file or directory" is just to indicate that we couldn't execute the sqlite3 binary. It took me a minute to realise that I hadn't yet installed sqlite3 and I was on my way. Should we catch the exception and provide a more explicit error message? See patch - but I don't mind if this is a wontfix.

Attachments (2)

patch.diff (704 bytes) - added by simeon 11 years ago.
patch.2.diff (1.5 KB) - added by Ashutosh Dwivedi 7 years ago.
patches the same in /django/core/management/

Download all attachments as: .zip

Change History (8)

Changed 11 years ago by simeon

Attachment: patch.diff added

comment:1 Changed 11 years ago by Simon Greenhill <dev@…>

Triage Stage: UnreviewedReady for checkin

comment:2 Changed 11 years ago by Malcolm Tredinnick

Patch needs improvement: set
Triage Stage: Ready for checkinAccepted

Surely the same problem must exist with all the other backends as well. So let's fix the problem, not just one arm of the problem (i.e. patch them all).

With regards to the patch, a few changes I'd like to see:

  1. Error messages that are only going to be seen by a developer don't get marked for translation. That saves on the workload for translators a bit.
  2. Use errno.ENOENT rather than the magic number "2" in the error check. It's more self-descriptive that way.
  3. The final bare "except" is unneeded. Uncaught exceptions are always raised out of the local block.

comment:3 Changed 8 years ago by Julien Phalip

Severity: Normal
Type: New feature

Technically a new feature. Not sure how current this is now though...

comment:4 Changed 7 years ago by Preston Holmes

Easy pickings: set
UI/UX: unset

Changed 7 years ago by Ashutosh Dwivedi

Attachment: patch.2.diff added

patches the same in /django/core/management/

comment:5 Changed 7 years ago by Ashutosh Dwivedi

Its already covered in /django/core/management/ under the following code

  def handle(self, **options):
        connection = connections[options.get('database', DEFAULT_DB_ALIAS)]
        except OSError:
            # Note that we're assuming OSError means that the client program                                                                                 
            # isn't installed. There's a possibility OSError would be raised                                                                                 
            # for some other reason, in which case this error message would be                                                                               
            # inaccurate. Still, this message catches the common case.                                                                                       
            raise CommandError('You appear not to have the %r program installed or on your path.' % \

If more specific error handling is required as in simeon's patch and as pointed out by mtredinnkick I have included a patch for the same which displays the error only if the executable is not found else raises the exception for user to figure out what is wrong .

comment:6 Changed 7 years ago by Claude Paroz

Resolution: duplicate
Status: newclosed

As aashu_dwivedi wrote, this is now properly handled in (fixed in r8990 / #8978). I don't see any real use case where patch.2.diff would be useful, but I suggest creating a new ticket if this is the case.

Closing as dup of #8978

Note: See TracTickets for help on using tickets.
Back to Top