In my case I needed to resort to using raw sql. The query was complex and the variables many, and thus I encountered a number of different database (cx_oracle) errors while working on the view and I didn't have a quick and dirty way to see the sql that was generated.
Getting the most recently generated sql is possible by importing django.db.connections. You can then tack it into your exception and see it on the default error page using the following technique.
This is where you build your view. Do whatever you need to do. In my case
I was inserting a row into the database here.
except Exception as inst:
inst.args is a tuple of arguments that were passed when the exception
was raised. Django will turn this variable into the main error message
you see atop the default error page. It's a tuple, so you can't append
to it, but you can replace it with another tuple and add any information
that would serve you well.
inst.args = ("%s sql:%s" % (inst.args, " ".join(connections[db].queries.pop()['sql'].split())),)
Sure that's ugly, but it served my debugging purpose. Use pop to get the most
recent query from the queries list. I wanted to get rid of the while space and
newline characters, which is the reason for the split and join. Now you just
raise the exception.
If you are going to do this kind of thing frequently you should probably explore the process-exception middleware API.