There is an issue when using chatglm to call the TiDB database through langchain, but it works fine when switched to MySQL

Translated
1

Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.

Original topic: 使用chatglm 通过langchain调用tidb数据库时有问题改成mysql就好了

| username: TiDBer_kn6fnmHR

The specific error is sqlalchemy.exc.ProgrammingError: (pymysql.err.ProgrammingError) (1064, 'You have an error in your SQL syntax; check the manual that corresponds to your TiDB version for the right syntax to use line 1 column 12 near “请求模型” ')
[SQL: 请求模型]

image
image1572×469 16.9 KB

2
| username: tidb菜鸟一只 | Original post link

What are the character sets of the two databases?

3
| username: MrSylar | Original post link

Check the code for the SQL statement that caused the error, then run it in TiDB to see where it is incompatible with MySQL.

4
| username: 小龙虾爱大龙虾 | Original post link

Go to the dashboard’s log search and search for the keyword “command dispatched failed”. You can find the SQL that caused the error.

5
| username: dba远航 | Original post link

The issue of syntax support

6
| username: TiDBer_kn6fnmHR | Original post link

It should be a database encoding issue. There is no problem when switching to other databases. This database has not set the character set encoding.

7
| username: TiDBer_kn6fnmHR | Original post link

I am using sqldatabasechain for interaction here, and it is not associated with specific SQL statements.

8
| username: TiDBer_kn6fnmHR | Original post link

Boss, TiDB and Flink always show this error, but it gets better after a while. Which TiDB configuration might be the problem?

9
| username: 有猫万事足 | Original post link

You have no problem asking about other middleware here in TiDB.
At least provide the version information of flink-cdc-connectors.
At the very least, it seems that it is no longer written this way.

10
| username: TiDBer_kn6fnmHR | Original post link

Using TiDB 7.3, Flink 1.17, flink-sql-connector-tidb-cdc 2.2.1. If CDC uses a version later than 2.2.1, the CPU will always be highly utilized.

11
| username: 有猫万事足 | Original post link

When fetching the tableId, a null pointer exception occurred.

Currently, it’s unclear which position has the null pointer.

Are there any other exceptions in the error stack?

Looking at it now, TiSession will check whether this session has been closed.

Could it be a session expiration issue?

12
| username: TiDBer_kn6fnmHR | Original post link

This situation always fails directly during initialization.

13
| username: 有猫万事足 | Original post link

Also, could it be that your table is a view?

  // https://github.com/pingcap/tispark/issues/961
  // TODO: support reading from view table in the future.

I see a comment here saying that views are not supported.