http://starrocks.io logo
Join Slack
Powered by
<@U0A71G31CDV> I see this error in starrocks what ...
# questions-and-troubleshooting
s
@Rocky I see this error in starrocks what does it mean ? Failed to parse SQL: DROP TABLE 
#Tableau_1_sid_02000079_1_Connect_CheckDropTablePrivilege
, because. com.starrocks.common.AnalysisException: This command is not supported in the prepared statement protocol yet
r
This error occurs because the client (in this case, Tableau) is trying to execute a 
DROP TABLE
command using the Binary (Prepared Statement) Protocol, which StarRocks does not currently support for DDL (Data Definition Language) commands. Why this happens with Tableau When Tableau connects to a data source, it often runs internal checks to verify permissions or clean up temporary tables. It uses a command like: 
DROP TABLE #Tableau_..._Connect_CheckDropTablePrivilege
If your connection is configured to use Server-Side Prepared Statements, the driver attempts to "prepare" this command before executing it. StarRocks currently supports the prepared statement protocol primarily for 
SELECT
queries (and some DML like `INSERT`/`UPDATE` in newer versions), but not for DDL like 
DROP TABLE
. How to fix it You need to disable server-side prepared statements in your connection settings. This forces the driver to use the standard text protocol, which StarRocks supports for all commands. 1. For JDBC connections If you are using a JDBC-based connection, add 
useServerPrepStmts=false
to your connection URL:
Copy code
text
jdbc:mysql://<fe_ip>:9030/your_db?useServerPrepStmts=false
2. For ODBC connections If you are using the MySQL ODBC driver with Tableau: 1. Open the ODBC Data Source Administrator. 2. Select your StarRocks DSN and click Configure. 3. Go to the Details or Cursors/Results tab. 4. Ensure the option "Prepare statements on the server" (or similar, depending on the driver version) is unchecked. 3. Tableau Specific (TDC file) If you cannot change the driver settings directly, you can sometimes use a Tableau Datasource Customization (
.tdc
) file to set 
CAP_SELECT_INTO
or force specific protocol behaviors, though the connection string fix is usually the most reliable. Summary * The Cause: StarRocks doesn't support 
DROP TABLE
via the binary prepared statement protocol. * The Fix: Set 
useServerPrepStmts=false
in your connection parameters. References • sql-reference/sql-statements/prepared_statement.md • sql-reference/http_sql_api.md
s
@Rocky it was wroking until yesterday and we re-installed starrocks to enable case insensitive, and started seeing this issue. is this somehow related to case insensitvie issue ?
r
The issue is likely related to the version upgrade that usually accompanies a re-installation or the specific way StarRocks handles the Prepared Statement Protocol in newer versions. Why it started after the re-install When you re-installed StarRocks to enable case-insensitivity (likely by setting 
enable_table_name_case_insensitive
in v4.0+ or 
lower_case_table_names
in earlier versions), you probably moved to a version (v3.2 or later) that officially supports the MySQL Binary Protocol (Prepared Statements). 1. Protocol Activation: In older versions, StarRocks did not support the prepared statement protocol at all. When Tableau connected, the driver realized the server didn't support it and automatically fell back to the "Text Protocol" (standard SQL), which works for 
DROP TABLE
. 2. The "Success" Trap: Because your new installation now advertises support for prepared statements (to allow faster 
SELECT
and 
INSERT
queries), Tableau's driver attempts to use this protocol for its internal maintenance tasks, including the 
DROP TABLE
command it uses to check privileges. 3. Unsupported Command: While StarRocks now supports the protocol, it only supports it for DML (SELECT, INSERT, UPDATE, DELETE). It does not yet support DDL (like 
DROP TABLE
) via this specific binary protocol, leading to the 
AnalysisException
. Is it related to case-insensitivity? The case-insensitivity setting itself isn't causing the error, but the server version/configuration required to use those features is what enabled the protocol that Tableau is now trying (and failing) to use. How to fix it You must explicitly tell the client driver not to use server-side prepared statements for this connection. * For JDBC: Add 
useServerPrepStmts=false
to your connection string. * For Tableau/ODBC: In the MySQL ODBC Data Source configuration, ensure "Prepare statements on the server" is uncheck (it is often under the "Options" or "Cursors/Results" tab). This will force Tableau to go back to the standard SQL protocol it was using "yesterday," which is fully compatible with StarRocks' 
DROP TABLE
command. References • sql-reference/sql-statements/prepared_statement.md • administration/management/FE_configuration.md (see 
enable_table_name_case_insensitive
) References • best_practices/query_tuning/query_profile_text_based_analysis.md • sql-reference/sql-statements/prepared_statement.md • data_source/feature-support-data-lake-analytics.md
s
@Rocky I used same starrocks version v4.0 to re-install, We only re-installed v4.0 to enable case insesntivity. So why would I see this issue now ?
r
While the version number (v4.0) remained the same, the "re-installation" process changed the cluster's state and configuration, which triggered this issue in Tableau. Here is exactly why this is happening now: 1. The Protocol was likely "Discovered" during Re-install StarRocks v4.0 supports the MySQL Binary (Prepared Statement) Protocol. However, Tableau's driver doesn't always use it—it probes the server for capabilities. * Before the re-install: Your previous installation might have had server-side prepared statements disabled (
enable_mysql_prepared_statement = false
), or Tableau might have cached the connection "capabilities" from an even older version where it wasn't supported. * After the re-install: Because you did a fresh installation, StarRocks initialized with its default v4.0 settings, where the prepared statement protocol is active. When Tableau re-connected to the "new" cluster, it detected this capability and immediately tried to use it for internal tasks like permission checks (
DROP TABLE
). 2. Case Insensitivity interaction The 
enable_table_name_case_insensitive
setting is not the direct cause of the error, but it is the reason you performed the re-install that reset your environment. However, there is one technical detail: when case-insensitivity is enabled, StarRocks becomes more strictly compliant with certain MySQL behaviors to ensure names match correctly. This "increased compatibility" can sometimes make drivers like Tableau more confident in using advanced features like the Binary Protocol. 3. Why it fails on 
DROP TABLE
 StarRocks v4.0 supports prepared statements for 
SELECT
, 
INSERT
, 
UPDATE
, and 
DELETE
. It does not support DDL (Data Definition Language) like 
DROP TABLE
via this protocol. When Tableau sends: 
PREPARE "stmt1" FROM 'DROP TABLE #Tableau_...'
StarRocks throws the error because its "Prepare" logic is currently limited to DML. How to fix it You need to tell Tableau (and its driver) to stop using the server-side prepared statement protocol. If using JDBC: Change your connection string to include: 
?useServerPrepStmts=false
If using ODBC (standard for Tableau): 1. Open your ODBC Data Source Administrator. 2. Find the DSN for StarRocks and click Configure. 3. Look for "Details >>" or "Cursors/Results". 4. Uncheck the box that says "Prepare statements on the server". If you want to disable it globally on StarRocks (as a workaround): You can try setting the global variable (though client-side is preferred):
Copy code
sql
SET GLOBAL enable_mysql_prepared_statement = false;
(Note: You may need to restart the session or the FE for this to take full effect on existing connections). Summary The re-installation "woke up" a feature (Prepared Statements) that Tableau is now trying to use for a command StarRocks doesn't yet support. Disabling it in your connection settings will return things to the way they were "yesterday." References • sql-reference/sql-statements/prepared_statement.md • administration/management/FE_configuration.md • sql-reference/System_variable.md References • administration/management/FE_configuration.md • sql-reference/System_variable.md • sql-reference/System_limit.md • sql-reference/sql-statements/prepared_statement.md
s
@Rocky how can i check if this variable is enabled in my starrocks ? 
enable_mysql_prepared_statement
if I revert this variable to false that should fix the issue or the client has to set 
?useServerPrepStmts=false
?
r
To check and resolve this issue using the variable you mentioned, follow these steps: 1. How to check the variable You can check if the MySQL prepared statement protocol is enabled in your session or globally by running:
Copy code
sql
-- Check current session value
SHOW VARIABLES LIKE 'enable_mysql_prepared_statement';

-- Check global value (which affects all new connections)
SHOW VARIABLES GLOBAL LIKE 'enable_mysql_prepared_statement';
2. Will reverting it fix the issue? Yes, setting this variable to 
false
globally will fix the issue. When 
enable_mysql_prepared_statement
is set to 
true
(which is the default in StarRocks v3.2+ and v4.0), StarRocks advertises to the MySQL driver that it supports the Binary Protocol. Tableau's driver sees this and tries to use it for all commands, including internal maintenance like 
DROP TABLE
. Since StarRocks only supports the binary protocol for DML (SELECT, INSERT, etc.) and not DDL (DROP TABLE), it fails. By setting it to 
false
, StarRocks will tell the client it doesn't support the binary protocol. The client (Tableau) will then automatically fall back to the Text Protocol (standard SQL), which works perfectly for all commands. 3. Server-side fix vs. Client-side fix You have two options to resolve this: Option A: Server-Side Fix (Easiest for all users) If you want to fix this for everyone connecting to the cluster without changing their Tableau settings, run this as an admin:
Copy code
sql
SET GLOBAL enable_mysql_prepared_statement = false;
Note: Existing connections might need to be restarted (reconnected) for this to take effect. Option B: Client-Side Fix (Recommended for Performance) If you only want to fix it for specific connections, keep the variable 
true
on the server (so other apps can still benefit from faster prepared statements) and only disable it in the connection string: * JDBC: 
jdbc:mysql://<FE_IP>:9030/db?useServerPrepStmts=false
* ODBC (Tableau): Uncheck "Prepare statements on the server" in the DSN configuration. Summary Re-installing v4.0 likely reset your global variables to their defaults, which enabled the prepared statement protocol. Setting 
SET GLOBAL enable_mysql_prepared_statement = false;
is the fastest way to revert to the behavior you had "yesterday." References • sql-reference/sql-statements/prepared_statement.md • sql-reference/System_variable.md • administration/management/FE_configuration.md References • administration/management/FE_configuration.md
s
@Rocky it is giving empty result when I try search 
enable_mysql_prepared_statement
in my starrocks. Is this correct variable ?
r
The reason you are seeing this issue now, even though you are using the same version (v4.0), is that the re-installation reset your cluster's configuration and global variables to their defaults. When you re-installed to enable case-insensitivity (which usually involves setting 
lower_case_table_names
or 
enable_table_name_case_insensitive
), the new deployment initialized with Server-Side Prepared Statements enabled by default (a feature introduced in v3.2 and active in v4.0). 1. Why it's happening In v4.0, StarRocks advertises to the MySQL driver (which Tableau uses) that it supports the "Binary Protocol" (Prepared Statements). Tableau detects this and tries to use it for its internal housekeeping, including the 
DROP TABLE
command it uses to check for permissions. However, StarRocks currently only supports the binary protocol for DML (SELECT, INSERT, UPDATE, DELETE). It does not yet support DDL (like 
DROP TABLE
) via this protocol, resulting in the 
AnalysisException
. 2. Why you can't find the variable The variable 
enable_mysql_prepared_statement
is a hidden variable in some StarRocks builds, or it may not appear in a standard 
SHOW VARIABLES
list depending on your user privileges or the specific sub-version of v4.0. To check if it exists (even if hidden), try running this:
Copy code
sql
-- This will return the value if the variable exists, even if hidden
SELECT @@enable_mysql_prepared_statement;
3. How to fix it (Reverting the change) Since the re-install wiped your previous global settings, you need to manually disable this protocol again. Run this command as an admin:
Copy code
sql
SET GLOBAL enable_mysql_prepared_statement = false;
*After running this, you may need to restart your Tableau connection so it picks up the change in server capabilities.* 4. Alternative: The Client-Side fix If you don't want to change the global server setting, you can fix it specifically for Tableau by modifying the connection: * ODBC (most common for Tableau): Go to the ODBC Data Source Administrator -> Configure your StarRocks DSN -> Details -> Uncheck "Prepare statements on the server". * JDBC: Add 
useServerPrepStmts=false
to the connection string. Summary: Your re-install for case-insensitivity reset the server's "identity" to its default state, which now includes a protocol that Tableau's driver tries to use but StarRocks' DDL engine can't handle yet. Disabling it globally via the 
SET GLOBAL
command above will restore the behavior you had "yesterday." References • sql-reference/sql-statements/prepared_statement.md • sql-reference/System_variable.md • administration/management/FE_configuration.md References • release_notes/release-4.0.md
s
@Rocky I see this variable enable_prepare_stmt instead of 
enable_mysql_prepared_statement
so do you mean setting to false for this variable enable_prepare_stmt will fix the issue ? I see it is set to true
r
Yes, you are exactly right. In StarRocks v4.0, the variable you need to control is indeed 
enable_prepare_stmt
. Setting this to 
false
will fix the issue. Why you see 
enable_prepare_stmt
instead In older documentation or specific development versions, the name 
enable_mysql_prepared_statement
was occasionally used, but in the stable v4.0 release, 
enable_prepare_stmt
is the standard variable that controls the MySQL Binary Protocol (Server-Side Prepared Statements). How to apply the fix You can fix this globally for the entire cluster so that Tableau (and any other client) stops trying to use the unsupported protocol for DDL commands:
Copy code
sql
-- 1. Double check the current value (you confirmed it's true)
SELECT @@global.enable_prepare_stmt;

-- 2. Disable it globally
SET GLOBAL enable_prepare_stmt = false;
What this does * Disables the Binary Protocol: StarRocks will no longer tell the MySQL driver "I support prepared statements." * Forces the Text Protocol: Tableau’s driver will fall back to sending standard SQL strings (Text Protocol). Since the Text Protocol supports 
DROP TABLE
and all other DDL perfectly, your error will disappear. * Persists across restarts: Using 
SET GLOBAL
ensures the setting stays even if the FE restarts, and it will apply to all new connections created after the change. Recommendation If you have existing Tableau sessions open, you should close and reopen them (or restart the Tableau workbook connection) after running the command to ensure they pick up the new server capabilities. Summary: Re-installing v4.0 reset this variable to its default (
true
). By setting 
enable_prepare_stmt = false
, you are returning the cluster to the behavior it had before the re-install. References • sql-reference/sql-statements/prepared_statement.md • sql-reference/System_variable.md References • sql-reference/sql-statements/prepared_statement.md • sql-reference/System_variable.md References • sql-reference/sql-statements/prepared_statement.md • sql-reference/System_variable.md • release_notes/release-3.2.md
s
@Rocky I do not think this variable 
enable_prepare_stmt
 is the problem. I see this is always set to true even before my re-instllation and it worked earlier for my tableau, so setting it to fasle might not work .? or should I just try it on client side ?
r
I understand the confusion. You are correct that in StarRocks v4.0, the official variable name is 
enable_prepare_stmt
. The name 
enable_mysql_prepared_statement
was used in some early development phases but is not the active variable in your version. Here is the breakdown of why this is happening and why setting 
enable_prepare_stmt
to 
false
is the recommended fix, even if you believe it was 
true
before: 1. Why 
enable_prepare_stmt
is the variable In v4.0, this variable controls whether StarRocks advertises support for the MySQL Binary Protocol (Server-Side Prepared Statements). * Default: 
true
(starting from v3.2/v4.0). * Behavior: When 
true
, clients like Tableau see that the server supports prepared statements and will attempt to use them for performance. 2. Why it likely "worked earlier" but fails now Even if the variable was 
true
yesterday, several things could have changed during your re-installation for case-insensitivity: * Driver Handshake: Re-installing the cluster (or potentially changing the 
lower_case_table_names
setting) can cause the Tableau/MySQL driver to re-negotiate its connection. It may have only now "noticed" the server-side support and decided to switch protocols. * Protocol Limitation: StarRocks' Binary Protocol currently only supports DML (SELECT, INSERT, etc.). It does not support DDL (like 
DROP TABLE
). Tableau often runs a 
DROP TABLE
or 
CREATE TEMPORARY TABLE
check when it first connects. If it tries to "Prepare" a 
DROP TABLE
statement, StarRocks will throw the 
AnalysisException
you are seeing. 3. Should you use the Server Fix or Client Fix? Both will work. Here is how to decide: Option A: The Server-Side Fix (Global) Run this to disable the protocol for the whole cluster. This is the "fix it for everyone" approach:
Copy code
sql
SET GLOBAL enable_prepare_stmt = false;
Why do this? If you have many Tableau users, you don't want to change every single one of their connection strings. This forces all clients to use the "Text Protocol," which supports all SQL commands (including 
DROP TABLE
) without issue. Option B: The Client-Side Fix (Surgical) Add 
?useServerPrepStmts=false
to your Tableau connection string (if using JDBC) or uncheck "Prepare statements on the server" in the ODBC DSN. Why do this? If you want other applications (like a high-speed Java microservice) to keep using prepared statements for performance, but only want to fix Tableau’s specific DDL error. Recommendation Since you just re-installed and Tableau is now broken, try setting the variable to 
false
globally first: 1. Run 
SET GLOBAL enable_prepare_stmt = false;
2. Crucial: Restart your Tableau connection (close and reopen the workbook). 3. If the error disappears, you have confirmed that the new installation's protocol handshake was the culprit. Summary: 
enable_prepare_stmt
is the correct variable. Even if it was 
true
before, disabling it is the standard "workaround" for tools like Tableau that try to use prepared statements for unsupported DDL commands. References • sql-reference/sql-statements/prepared_statement.md • sql-reference/System_variable.md • release_notes/release-4.0.md References • sql-reference/sql-statements/prepared_statement.md • release_notes/release-3.2.md • table_design/hybrid_table.md • sql-reference/System_variable.md • using_starrocks/caching/query_cache.md
s
@Rocky I set global value to false but Now I see this error, so something is wrong. com.starrocks.sql.common.StarRocksPlannerException: prepare statement can't be executed, maybe need set enable_prepare_stmt=true
r
The error you are seeing now (
StarRocksPlannerException: prepare statement can't be executed
) confirms that your Tableau driver is still trying to use the Binary Protocol (Server-Side Prepared Statements), but because you set the variable to 
false
, StarRocks is now actively rejecting the request. Here is exactly what is happening and how to fix it: 1. Why 
enable_prepare_stmt
is the only variable you see In StarRocks v4.0, the variable 
enable_mysql_prepared_statement
has been fully replaced/standardized as 
enable_prepare_stmt
. They control the same underlying feature: the MySQL Binary Protocol. 2. Why the error changed (The "Deadlock") * When 
true
(Default): StarRocks tells Tableau "I support prepared statements." Tableau tries to use them for a 
DROP TABLE
command. StarRocks doesn't support 
DROP TABLE
via this protocol yet, so it gives you the 
AnalysisException
. * When `false`: StarRocks tells Tableau "I do not support prepared statements." However, if Tableau's connection was already open, it still thinks the server supports it (or the driver is forcing it). When it sends the request, StarRocks sees the feature is disabled and throws the 
StarRocksPlannerException
. 3. Why it worked "yesterday" Before your re-installation, your previous cluster likely had this variable set to 
false
globally, or your Tableau driver had not yet cached the "Server Capabilities" of the new cluster. Re-installing reset the global default to 
true
and forced a new handshake, which "woke up" this feature in the Tableau driver. 4. How to fix this properly To stop this error, you must ensure that both the server and the client agree to use the standard Text Protocol. Step 1: Force the Server to stay False Keep the global setting as you have it:
Copy code
sql
SET GLOBAL enable_prepare_stmt = false;
Step 2: Clear Existing Sessions (Crucial) Global variables do not affect connections that are already open. Tableau keeps a pool of connections. * The easiest way: Restart your StarRocks FE(s). This will kill all sessions and force them to reconnect using the new 
false
default. * Alternative: Run 
SHOW PROCESSLIST;
and 
KILL [connection_id];
for all Tableau connections. Step 3: Fix the Client Side (Recommended) If the error persists after a restart, the Tableau driver is likely forcing prepared statements regardless of the server setting. 1. In Tableau, edit your Connection. 2. If using JDBC: Append 
?useServerPrepStmts=false
to the server URL. 3. If using ODBC: Open the "ODBC Data Source Administrator," find your StarRocks DSN, click Configure -> Details -> and uncheck "Prepare statements on the server." Summary: The error you see now is just the "other side" of the same problem. Disabling it globally (
false
) and then restarting your Tableau workbook/connection to clear the session cache is the solution. References • sql-reference/sql-statements/prepared_statement.md • sql-reference/System_variable.md
2 Views
Open in Slack
PreviousNext
Powered by