You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
No error message, because no error is being raised.
Description
Description
When using LangChain for NL2SQL, there is a discrepancy between the displayed SQL in the intermediate steps and the actual SQL that is executed. The executed SQL seems to mishandle umlauts (ä, ö, ü), using escape sequences (e.g., \u00fc for ü) instead of the actual umlaut characters. This results in incorrect query execution, as the database does not recognize the conditions specified due to encoding errors.
Expected Behavior
The SQL query should be executed exactly as shown in the intermediate steps, preserving the correct encoding for special characters such as umlauts. The conditions in the WHERE clause should correctly filter the records based on the given values.
Actual Behavior
The executed SQL does not correctly handle the encoding of umlauts, leading to no matches in conditions that involve these characters, even when appropriate records exist in the database.
Output of invoke()
Invoking: `sql_db_query_checker`with`{'query': "SELECT COUNT(*) AS open_cancellation_orders FROM auftraege WHERE type = 'K\\u00fcndigung erfassen' AND status = 'offener K\\u00fcndigungsvorgang'"}```sqlSELECTCOUNT(*) ASopen_cancellation_ordersFROMauftraegeWHEREtype='Kündigung erfassen'ANDstatus='offener Kündigungsvorgang'``Invoking: `sql_db_query`with`{'query': "SELECT COUNT(*) AS open_cancellation_orders FROM auftraege WHERE type = 'K\\u00fcndigung erfassen' AND status = 'offener K\\u00fcndigungsvorgang'"}`
[(0,)]EsgibtderzeitkeineoffenenKündigungsaufträgeinderDatenbank.
The SQL statement in the middle is correct (including the special characters), this is what should be executed. And if I execute this SQL statement in another tool, I get the correct result.
However, the SQL statement at the top and the bottom (with wrong speacial character representation) seems to be what is actually executed. Since the value in the where-clause is wrong, the query does not return any row, which is wrong.
What surprises me is that even within the same output two different versions of the SQL statement are displayed, one correct and one incorrect, and that unfortunately the wrong one is executed.
System Info
System Information
OS: Windows
OS Version: 10.0.19045
Python Version: 3.11.9 (tags/v3.11.9:de54cf5, Apr 2 2024, 10:12:12) [MSC v.1938 64 bit (AMD64)]
Packages not installed (Not Necessarily a Problem)
The following packages were not found:
langgraph
langserve
The text was updated successfully, but these errors were encountered:
dosubotbot
added
Ɑ: agent
Related to agents module
🤖:bug
Related to a bug, vulnerability, unexpected error with an existing feature
labels
Apr 29, 2024
Checked other resources
Example Code
This is the code I execute, but without my db it will be hard to reproduce....
Error Message and Stack Trace (if applicable)
No error message, because no error is being raised.
Description
Description
When using LangChain for NL2SQL, there is a discrepancy between the displayed SQL in the intermediate steps and the actual SQL that is executed. The executed SQL seems to mishandle umlauts (ä, ö, ü), using escape sequences (e.g., \u00fc for ü) instead of the actual umlaut characters. This results in incorrect query execution, as the database does not recognize the conditions specified due to encoding errors.
Expected Behavior
The SQL query should be executed exactly as shown in the intermediate steps, preserving the correct encoding for special characters such as umlauts. The conditions in the WHERE clause should correctly filter the records based on the given values.
Actual Behavior
The executed SQL does not correctly handle the encoding of umlauts, leading to no matches in conditions that involve these characters, even when appropriate records exist in the database.
Output of invoke()
The SQL statement in the middle is correct (including the special characters), this is what should be executed. And if I execute this SQL statement in another tool, I get the correct result.
However, the SQL statement at the top and the bottom (with wrong speacial character representation) seems to be what is actually executed. Since the value in the where-clause is wrong, the query does not return any row, which is wrong.
What surprises me is that even within the same output two different versions of the SQL statement are displayed, one correct and one incorrect, and that unfortunately the wrong one is executed.
System Info
System Information
Package Information
Packages not installed (Not Necessarily a Problem)
The following packages were not found:
The text was updated successfully, but these errors were encountered: