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/1073...
* 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.
