Fix executemany() raising from the SQL panel

_record() passed the param list straight to _last_executed_query(), but the
backend's last_executed_query() expects a flat sequence of scalars. On
sqlite it re-quotes them with QUOTE(?) placeholders, so a sequence of param
sequences raises ProgrammingError. It happens in a finally: block after the
statement has already run, so the write lands and the request still 500s.

Thread a many flag through _record() and render the statement as
'N times: <sql>' in that case, which is what Django's own
CursorDebugWrapper does.

The select/explain/profile buttons re-execute raw_sql with params through
plain cursor.execute, which fails the same way, so they are hidden for
executemany queries.

Author: alliasgher

debug_toolbar/panels/sql/tracking.py

@@ -187,7 +187,7 @@ def _last_executed_query(self, sql, params):
         finally:
             self.db._djdt_logger = self.logger
 
-    def _record(self, method, sql, params):
+    def _record(self, method, sql, params, *, many=False):
         alias = self.db.alias
         vendor = self.db.vendor
 
@@ -219,13 +219,27 @@ def _record(self, method, sql, params):
             else:
                 sql = str(sql)
 
+            if many:
+                # params is a sequence of param sequences, but
+                # last_executed_query() expects a flat sequence of scalars, so
+                # it cannot interpolate this. Report the statement and how many
+                # times it ran, matching Django's own CursorDebugWrapper.
+                try:
+                    times = len(params)
+                except TypeError:
+                    times = "?"
+                display_sql = f"{times} times: {sql}"
+            else:
+                display_sql = self._last_executed_query(sql, params)
+
             kwargs = {
                 "vendor": vendor,
                 "alias": alias,
-                "sql": self._last_executed_query(sql, params),
+                "sql": display_sql,
                 "duration": duration,
                 "raw_sql": sql,
                 "params": _params,
+                "many": many,
                 "stacktrace": get_stack_trace(skip=2),
                 "template_info": template_info,
             }
@@ -281,4 +295,4 @@ def execute(self, sql, params=None):
         return self._record(super().execute, sql, params)
 
     def executemany(self, sql, param_list):
-        return self._record(super().executemany, sql, param_list)
+        return self._record(super().executemany, sql, param_list, many=True)

debug_toolbar/templates/debug_toolbar/panels/sql.html

@@ -74,7 +74,8 @@
             {{ query.duration|floatformat:"2" }}ms
           </td>
           <td class="djdt-actions">
-            {% if query.params is not None %}
+            {# executemany params are a sequence of param sequences, which these views cannot re-execute. #}
+            {% if query.params is not None and not query.many %}
               <form method="post">
                 {{ query.form.as_div }}
                 <button formaction="{% url 'djdt:sql_select' %}" class="remoteCall">Sel</button>

docs/changes.rst

@@ -16,6 +16,9 @@ Pending
 * Stopped the history panel buttons from submitting their form when clicked
   before the panel script has loaded, which navigated away from the page.
 * Added support for Django 6.1.
+* Fixed ``cursor.executemany()`` raising from the SQL panel instead of being
+  recorded. The statement is now shown as ``N times: <sql>``, matching
+  Django's own debug cursor.
 
 7.0.0 (2026-06-17)
 ------------------

tests/panels/test_sql.py

@@ -104,6 +104,51 @@ def test_recording(self):
         # ensure the stacktrace is populated
         self.assertTrue(len(query["stacktrace"]) > 0)
 
+    def test_executemany(self):
+        """
+        executemany() must be recorded without raising.
+
+        The backend's last_executed_query() expects a flat sequence of scalar
+        params, so handing it a list of param sequences fails. It happens in a
+        finally: block after the write has already landed, so the exception
+        escapes into the caller.
+        """
+        self.assertEqual(len(self.panel._queries), 0)
+
+        with connection.cursor() as cursor:
+            cursor.executemany(
+                "INSERT INTO tests_binary (field) VALUES (%s)",
+                [(b"one",), (b"two",)],
+            )
+
+        self.assertEqual(len(self.panel._queries), 1)
+        query = self.panel._queries[0]
+        self.assertEqual(
+            query["sql"], "2 times: INSERT INTO tests_binary (field) VALUES (%s)"
+        )
+        self.assertTrue(query["many"])
+        self.assertEqual(Binary.objects.count(), 2)
+
+    def test_executemany_with_empty_param_list(self):
+        """An empty param list runs no statement but must still not raise."""
+        self.assertEqual(len(self.panel._queries), 0)
+
+        with connection.cursor() as cursor:
+            cursor.executemany("INSERT INTO tests_binary (field) VALUES (%s)", [])
+
+        self.assertEqual(len(self.panel._queries), 1)
+        self.assertEqual(
+            self.panel._queries[0]["sql"],
+            "0 times: INSERT INTO tests_binary (field) VALUES (%s)",
+        )
+        self.assertEqual(Binary.objects.count(), 0)
+
+    def test_execute_is_not_marked_as_many(self):
+        sql_call()
+
+        self.assertEqual(len(self.panel._queries), 1)
+        self.assertFalse(self.panel._queries[0]["many"])
+
     def test_assert_num_queries_works(self):
         """
         Confirm Django's assertNumQueries and CaptureQueriesContext works