FullResultSet exception when using objects.all()


After going to version 4.2 of django, I get FullResultSet exception when trying to get all rows of a table using the objects.all() method of the model.


    initials = [op.get('name')[0].upper() for op in kms_models.Operator.objects.all().values('name')]

I don’t understand what I am doing wrong and how to get all objects of a table.
Thanks for your help,
F. Cordonier

Please post the full error message with the traceback. That may help identify the cause of the issue.

Also, are you using a custom manager for your Operator model? If so, it would be helpful to see that.

Hello Ken, Thanks for your answer.
Here is the exception traceback:

Traceback (most recent call last):
  File "C:\Users\cordonie\.virtualenvs\pste_proto-tij3fROr\lib\site-packages\django\core\handlers\exception.py", line 55, in inner
    response = get_response(request)
  File "C:\Users\cordonie\.virtualenvs\pste_proto-tij3fROr\lib\site-packages\django\core\handlers\base.py", line 197, in _get_response
    response = wrapped_callback(request, *callback_args, **callback_kwargs)
  File "C:\Users\cordonie\PycharmProjects\kmsdb_explorer\pste_proto\KMS\views.py", line 162, in operator_list
    return operator_list_page(request, page)
  File "C:\Users\cordonie\PycharmProjects\kmsdb_explorer\pste_proto\KMS\views.py", line 147, in operator_list_page
    list(set([op.get('name')[0].upper() for op in kms_models.Operator.objects.all().values('name')])))
  File "C:\Users\cordonie\.virtualenvs\pste_proto-tij3fROr\lib\site-packages\django\db\models\query.py", line 398, in __iter__
  File "C:\Users\cordonie\.virtualenvs\pste_proto-tij3fROr\lib\site-packages\django\db\models\query.py", line 1881, in _fetch_all
    self._result_cache = list(self._iterable_class(self))
  File "C:\Users\cordonie\.virtualenvs\pste_proto-tij3fROr\lib\site-packages\django\db\models\query.py", line 208, in __iter__
    for row in compiler.results_iter(
  File "C:\Users\cordonie\.virtualenvs\pste_proto-tij3fROr\lib\site-packages\django\db\models\sql\compiler.py", line 1513, in results_iter
    results = self.execute_sql(
  File "C:\Users\cordonie\.virtualenvs\pste_proto-tij3fROr\lib\site-packages\django\db\models\sql\compiler.py", line 1549, in execute_sql
    sql, params = self.as_sql()
  File "C:\Users\cordonie\.virtualenvs\pste_proto-tij3fROr\lib\site-packages\mssql\compiler.py", line 235, in as_sql
    where, w_params = self.compile(self.where) if self.where is not None else ("", [])
  File "C:\Users\cordonie\.virtualenvs\pste_proto-tij3fROr\lib\site-packages\mssql\compiler.py", line 421, in compile
    return super().compile(node, *args, **kwargs)
  File "C:\Users\cordonie\.virtualenvs\pste_proto-tij3fROr\lib\site-packages\django\db\models\sql\compiler.py", line 546, in compile
    sql, params = node.as_sql(self, self.connection)
  File "C:\Users\cordonie\.virtualenvs\pste_proto-tij3fROr\lib\site-packages\django\db\models\sql\where.py", line 174, in as_sql
    raise FullResultSet
[31/Aug/2023 09:33:14] "GET /kms/operators/all/ HTTP/1.1" 500 118726

Concerning your second question, my model is not managed:

class Operator(models.Model):
    operator_id = models.CharField(max_length=3, primary_key=True)
    name = models.CharField(unique=True, max_length=75)
    jtag_pwd_service_active = models.CharField(null = True, blank = True, max_length=1)
    accept_stb_log = models.CharField(null = True, blank = True, max_length=1)
    cancelled = models.CharField(null = True, blank = True, max_length=1)
    ist_upload_dt = models.DateField(null = True, blank = True)
    operator_email_address = models.CharField(max_length=50, blank=True)
    operator_pgp_key_reference = models.CharField(max_length=50, blank=True)
    class Meta:
        managed = False
        db_table = 'operator'
    def name_for_filename(self):
        n = self.name
        invalid = '/\%\\+ '
        for i in invalid:
            n = n.replace(i, '_')
        return n

I set
managed = False
to prevent any modification to the database (my application shall only read the database and not modify anything); it’s a kind of “viewer”.


Hi there,

The issue has been corrected (or workarounded) within an update of the mssql backend. After upgrading to mssql-django 1.3, the exception is handled in the backend and is no more impacting the application.

Issue closed.

F. Cordonier