code unit 1 line 1 statement, stored as Query - considered "empty" in Job TaskRun - fails [ADBricks]

ADBricksExplore — Thu, 29 Jan 2026 12:13:56 GMT

Hi colleagues,

could someone explain, why a single line statement [CALL ...();] fails (considered "empty" in error message) when invoked by a Job's Task[SQL\Query] run?
- as shown on the attached screen:

The same statement, stored in (Notebook, Workspace File) is been invoked OK, by a corresponding (Task[Run\Notebook], Task[SQL\File]) and executed OK

Re: code unit 1 line 1 statement, stored as Query - considered "empty" in Job TaskRun - fa

pradeep_singh — Sun, 01 Feb 2026 15:25:27 GMT

When you configure a Databricks job with a task type: SQL → Query, the job runs a saved SQL asset.

If the query’s body wasn’t actually saved, or if the Run As user doesn’t have permission to read it, Databricks loads an empty query and returns one of the following errors:

“Query text cannot be empty”
“Unexpected empty statement”

To fix this issue:

In Databricks, go to SQL > Queries > My Queries.
Open the exact Query asset referenced by the job.
Click Save to ensure the CALL ...(); body is persisted.
Re-run the job.

Re: code unit 1 line 1 statement, stored as Query - considered "empty" in Job TaskRun - fa

SteveOstrowski — Sun, 08 Mar 2026 07:29:03 GMT

Hi @ADBricksExplore,

This behavior where a CALL statement works from a Notebook or SQL File task but fails with an "empty" error from a SQL Query task comes down to how these task types resolve the SQL content at runtime.

UNDERSTANDING THE DIFFERENCE BETWEEN SQL TASK TYPES

When you configure a job task as SQL > Query, the task references a saved query asset stored in the Databricks SQL workspace (visible under SQL > Queries). At runtime, the job fetches the body of that saved query object and sends it to the SQL warehouse for execution.

When you use SQL > File, the task reads the .sql file directly from your workspace or Git repo. And when you use a Notebook task, it executes the notebook cell contents directly. Both of these read the content from the file system rather than from the saved query store.

WHY THE "EMPTY" ERROR OCCURS

There are a few common reasons the SQL Query task sees an "empty" body even though you can see content in the editor:

1. The query was not explicitly saved. If you typed or pasted your CALL statement into the SQL editor but never clicked the Save button (or if Save silently failed), the query object in the backend may have an empty body. The editor can show unsaved content in your browser session, but the job fetches the persisted version. Open the query in SQL > Queries > My Queries, verify your CALL statement appears, and click Save explicitly.

2. The "Run As" user lacks permission to read the query. When a job runs, it executes as a specific user (configured in the job's "Run As" setting, which defaults to the job owner). If that user does not have at least CAN RUN permission on the saved query, Databricks returns an empty body rather than an authorization error. To check this, open the query, click Share, and confirm the Run As user has the appropriate permission level.

3. The SQL warehouse assigned to the task does not match. The SQL Query task requires a SQL warehouse (serverless or pro). If there is a mismatch or the warehouse is not accessible to the Run As user, the query resolution can fail silently.

RECOMMENDED STEPS TO RESOLVE

1. Go to SQL > Queries in the Databricks workspace.
2. Locate the exact query referenced by your job task. Open it.
3. Confirm you see your CALL statement in the editor (e.g., CALL my_catalog.my_schema.my_procedure();).
4. Click Save to ensure it is persisted.
5. Click Share and verify the job's Run As user has CAN RUN or higher permission.
6. In the job configuration, confirm the SQL warehouse assigned to the task is a Pro or Serverless warehouse, and that the Run As user has access to it.
7. Re-run the job.

ALTERNATIVE APPROACH: USE A SQL FILE TASK INSTEAD

If you continue to have trouble with the SQL Query task type, consider switching to the SQL > File task type. Create a .sql file in your workspace containing your CALL statement:

CALL my_catalog.my_schema.my_procedure();

Then configure the job task as SQL > File and point it to that workspace file. This approach reads the file content directly and avoids the saved query resolution layer entirely. Based on your description, this pattern already works for you with the SQL File task type, so it may be the most straightforward path forward.

REFERENCE

Documentation on SQL task types in Jobs:
https://docs.databricks.com/aws/en/jobs/sql

Documentation on query permissions:
https://docs.databricks.com/aws/en/sql/user/queries/index.html

A related community thread with the same "Query text can not be empty" error and resolution:
https://community.databricks.com/t5/data-engineering/workflow-sql-task-query-showing-empty/td-p/107300

* This reply used an agent system I built to research and draft this response based on the wide set of documentation I have available and previous memory. I personally review the draft for any obvious issues and for monitoring system reliability and update it when I detect any drift, but there is still a small chance that something is inaccurate, especially if you are experimenting with brand new features.

topic Re: code unit 1 line 1 statement, stored as Query - considered "empty" in Job TaskRun - fa in Data Engineering

code unit 1 line 1 statement, stored as Query - considered "empty" in Job TaskRun - fails [ADBricks]

Re: code unit 1 line 1 statement, stored as Query - considered "empty" in Job TaskRun - fa

Re: code unit 1 line 1 statement, stored as Query - considered "empty" in Job TaskRun - fa