Fatal errors occurring outside of the MSSQL data source

[we1s3]

Search before asking

• I had searched in the issues and found no similar issues.

Operating system information

MacOS(M1, M2...)

Python version information

3.10

DB-GPT version

main

Related scenes

• Chat Data
• Chat Excel
• Chat DB
• Chat Knowledge
• Model Management
• Dashboard
• Plugins

Installation Information

• Installation From Source

• Docker Installation

• Docker Compose Installation

• Cluster Installation

• AutoDL Image

• Other

Device information

M1 MAX

Models information

LLM：qwen-max
embedding：qwen text-embedding-v4

What happened

When using the mssql2021 data source, the SQL syntax generated during program execution may contain unsupported special characters, such as '`', which may appear to be characters supported by MySQL or Oracle. However, when executed in msSQL, exceptions may occur, causing the client to be unable to produce any results. Can this issue be optimized?
I am currently unable to solve this problem through prompt words. Perhaps some tool models or domain models in db gpt require more knowledge about the syntax of mssql

What you expected to happen

runtime exception

How to reproduce

Ask questions using MSSQL data source

Additional context

2025-08-22 15:50:37 haodeMacBook-Pro.local dbgpt.core.interface.output_parser[23798] INFO illegal json processing:
[
{
"thoughts": "通过查询最近的报工记录，我们可以了解最新的生产情况。我们将从报工时间、报工数量、操作员和工序这四个维度进行分析。",
"showcase": "Table",
"sql": "SELECT ReportTime AS 报工时间, ReportNum AS 报工数量, ReportMemberId AS 操作员, ProcessesId AS 工序 FROM dbo.WorkReport ORDER BY ReportTime DESC LIMIT 10;",
"title": "最近的报工记录"
}
]
clean prompt response: [ { "thoughts": "通过查询最近的报工记录，我们可以了解最新的生产情况。我们将从报工时间、报工数量、操作员和工序这四个维度进行分析。", "showcase": "Table", "sql": "SELECT ReportTime AS 报工时间, ReportNum AS 报工数量, ReportMemberId AS 操作员, ProcessesId AS 工序 FROM dbo.WorkReport ORDER BY ReportTime DESC LIMIT 10;", "title": "最近的报工记录" } ]
2025-08-22 15:50:37 haodeMacBook-Pro.local dbgpt.datasource.rdbms.base[23798] INFO Query[SELECT ReportTime AS 报工时间, ReportNum AS 报工数量, ReportMemberId AS 操作员, ProcessesId AS 工序 FROM dbo.WorkReport ORDER BY ReportTime DESC LIMIT 10;] with timeout=Nones
2025-08-22 15:50:37 haodeMacBook-Pro.local dbgpt.datasource.rdbms.base[23798] ERROR Error in session scope: (pymssql.exceptions.ProgrammingError) (102, b"Incorrect syntax near ''.DB-Lib error message 20018, severity 15:\nGeneral SQL Server error: Check messages from the SQL Server\n") [SQL: SELECT ReportTimeAS 报工时间,ReportNumAS 报工数量,ReportMemberIdAS 操作员,ProcessesIdAS 工序 FROMdbo.WorkReportORDER BYReportTime DESC LIMIT 10;] (Background on this error at: https://sqlalche.me/e/20/f405) 2025-08-22 15:50:37 haodeMacBook-Pro.local dbgpt_app.scene.chat_dashboard.chat[23798] WARNING Failed to get chart data: (pymssql.exceptions.ProgrammingError) (102, b"Incorrect syntax near ''.DB-Lib error message 20018, severity 15:\nGeneral SQL Server error: Check messages from the SQL Server\n")
[SQL: SELECT ReportTime AS 报工时间, ReportNum AS 报工数量, ReportMemberId AS 操作员, ProcessesId AS 工序 FROM dbo.WorkReport ORDER BY ReportTime DESC LIMIT 10;]
(Background on this error at: https://sqlalche.me/e/20/f405)
2025-08-22 15:50:48 haodeMacBook-Pro.local dbgpt.datasource.rdbms.base[23798] INFO Closing RDBMS connector resources...

Are you willing to submit PR?

• Yes I am willing to submit a PR!

[onestardao]

Looks like what you’re hitting isn’t just an MSSQL driver issue, it maps to ProblemMap No.6 (logic collapse in retrieval layer). The stack trace shows query context breaking outside expected bounds, so the engine can’t safely recover.
We use a semantic firewall approach that fixes this without infra rewrites — let me know if you want the checklist.

[we1s3]

Looks like what you’re hitting isn’t just an MSSQL driver issue, it maps to ProblemMap No.6 (logic collapse in retrieval layer). The stack trace shows query context breaking outside expected bounds, so the engine can’t safely recover. We use a semantic firewall approach that fixes this without infra rewrites — let me know if you want the checklist.

Please tell me how I should solve this problem. Thank you very much

[onestardao]

thanks for the details. this isn’t an MSSQL-only bug. it’s a boundary failure where raw retrieved text leaks into SQL without a strict contract. you see JSON parse errors and reserved chars because the pipeline lets un-sanitized snippets pass.

Fix path (maps to WFGY Problem Map: No.9 parsing/escaping drift, No.6 schema/shape mismatch, No.8 traceability)

1. Freeze the SQL contract

   • only parameterized queries, never concatenate strings from the LLM
   • whitelist verbs and columns, cap query length
   • escape or drop control bytes and unmatched quotes before binding

2. Sanitize the retrieval payload

   • enforce a schema: snippet_id, section_id, source_url, offsets, tokens
   • strip non-printables, normalize quotes, collapse weird unicode variants

3. Observability and repro

   • log the exact raw snippet that triggered the error, and the final SQL after binding
   • run a tiny goldset. gate deploy when error rate = 0 for N runs

full checklist with the numbered items is here:
Problem Map → https://github.com/onestardao/WFGY/tree/main/ProblemMap/README.md