FIX: Capture PRINT messages in nextset() via SQL_SUCCESS_WITH_INFO

[jahnvi480]

Work Item / Issue Reference

AB#45395

GitHub Issue: #612

---

Summary

This pull request addresses an issue where diagnostic messages (such as SQL Server PRINT output) from subsequent result sets were not properly captured when using the nextset() method. The fix ensures that all messages are collected, even across multiple result sets, and adds comprehensive tests to verify this behavior.

Bug Fix: Diagnostic Message Handling

• Updated the nextset() method in cursor.py to capture diagnostic messages (e.g., PRINT output) when SQL returns SQL_SUCCESS_WITH_INFO, ensuring messages from all result sets are preserved.

Testing Improvements

• Added several new tests in test_004_cursor.py to verify that PRINT messages are correctly captured across multiple result sets and that messages from previous result sets are cleared appropriately:
  • Test for multiple PRINT statements across result sets via nextset()
  • Test for PRINT messages interleaved with SELECT statements
  • Test for three consecutive PRINT messages across nextset() calls
  • Test to ensure nextset() clears messages from the previous result set

[Copilot]

Pull request overview

This PR fixes a gap in diagnostic message handling when iterating across multiple result sets: Cursor.nextset() now collects diagnostics (e.g., SQL Server PRINT output) when SQLMoreResults returns SQL_SUCCESS_WITH_INFO, ensuring messages from subsequent result sets aren’t silently dropped.

Changes:

• Update Cursor.nextset() to pull diagnostic records on SQL_SUCCESS_WITH_INFO from SQLMoreResults.
• Add regression and scenario tests validating PRINT message capture across multiple nextset() calls (including mixed PRINT + SELECT).
• Add a test asserting nextset() clears prior result-set messages.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
mssql_python/cursor.py	Capture diagnostics on SQL_SUCCESS_WITH_INFO during nextset() to preserve PRINT output across result sets.
tests/test_004_cursor.py	Add regression tests covering multi-result PRINT diagnostics behavior through nextset().

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[github-actions]

📊 Code Coverage Report

🔥 Diff Coverage 100%

🎯 Overall Coverage 80%

📈 Total Lines Covered: 6670 out of 8271 📁 Project: mssql-python

---

Diff Coverage

Diff: main...HEAD, staged and unstaged changes

• mssql_python/cursor.py (100%)

Summary

• Total: 7 lines
• Missing: 0 lines
• Coverage: 100%

---

📋 Files Needing Attention

📉 Files with overall lowest coverage (click to expand)

mssql_python.pybind.logger_bridge.cpp: 59.2%
mssql_python.pybind.ddbc_bindings.h: 59.7%
mssql_python.pybind.logger_bridge.hpp: 70.8%
mssql_python.pybind.ddbc_bindings.cpp: 76.1%
mssql_python.row.py: 76.9%
mssql_python.__init__.py: 77.3%
mssql_python.pybind.connection.connection.cpp: 77.3%
mssql_python.ddbc_bindings.py: 79.6%
mssql_python.logging.py: 85.5%
mssql_python.connection.py: 85.6%

---

🔗 Quick Links

⚙️ Build Summary	📋 Coverage Details
View Azure DevOps Build	Browse Full Coverage Report

[KellyKr]

I just ran into this and see the fix will be coming. Nice!

To ask for a bit more: the type of cursor.messages is list[Unknown], it would be nice to have correct typing on it.

[sumitmsft]

I just ran into this and see the fix will be coming. Nice!

To ask for a bit more: the type of cursor.messages is list[Unknown], it would be nice to have correct typing on it.

@jahnvi480 While we're touching the messages handling, can we also fix the typing? Today self.messages = [] is inferred as list[Unknown] by IDEs and type-checkers.

The C++ binding (SQLGetAllDiagRecords) always returns Tuple[str, str] per entry. (sql_state_with_error_code, message_text) and the tests already assert this shape. So. do you think it's a safe fix?

[jahnvi480]

Thanks @KellyKr and @sumitmsft for detailed review, I have verified and updated the typing for messages.