[Bug] SQL Server (`shared_sql`) action operations are always routed to `/procedures` with an unresolved path template, so Insert row (V2), Execute a SQL query (V2), Get tables (V2) etc. all return 404

Describe the bug

In @microsoft/managed-apps 0.5.11 (@microsoft/managed-apps-common 0.19.0), every action-mode operation of the SQL Server connector is treated as a stored-procedure call.

ConnectorExecutor._buildOperationUrl (dist/dataClient/data/connectorExecutor.js, lines 333–336) checks apiId.indexOf('shared_sql') > -1. If that's true, it always calls _buildSharedSqlOperationUrl (line 381), which returns:

`${base}${version}datasets/${config.datasetName}/procedures${path}`

This causes three problems:

• path is the operation's raw swagger path template, for example /{connectionId}/v2/datasets/{server},{database}/tables/{table}/items for PostItem_V2. Its placeholders are never substituted, and it gets appended after /procedures.
• config.datasetName is empty for an action-mode connection reference ("dataSets": {} in ms.config.json), which produces datasets//procedures/....
• The resulting URL doesn't exist, so the connector returns 404 for every SQL action. That includes Insert row (V2) (PostItem_V2), Execute a SQL query (V2) (ExecutePassThroughNativeQuery_V2), Get tables (V2) (GetTables_V2) and Get rows (V2) (GetItems_V2).

Other connectors go through _buildStandardOperationUrl, which resolves path parameters.

The substring check also matches shared_sqldw (Azure SQL Data Warehouse).

Steps to Reproduce

1. Create a code app from the App Builder v1 template ("@microsoft/managed-apps": "0.5.11").
2. Create a SQL Server (shared_sql) connection with Microsoft Entra ID Integrated authentication. Our target was a Microsoft Fabric SQL database. The connection is valid: table-mode reads through it succeed.
3. Add the SQL Server connector as an action-mode data source. This generates SQLServerService with 22 operations, including PostItem_V2, GetTables_V2, GetItems_V2 and ExecutePassThroughNativeQuery_V2.
4. Call:

   await SQLServerService.GetTables_V2("<server>.database.fabric.microsoft.com", "<database>");
   

   Result: 404.
5. Call:

   await SQLServerService.ExecutePassThroughNativeQuery_V2(
     "<server>.database.fabric.microsoft.com", "<database>",
     { query: "SELECT COUNT(*) AS Orders FROM SalesLT.SalesOrderHeader" });
   

   Result: 404.
6. PostItem_V2(server, database, table, item) (Insert row (V2)) takes the same code path and builds the same kind of invalid URL. See Additional context.

Expected behavior

SQL Server action operations resolve their own path template the same way other connectors do. For example, Insert row (V2) should be:

POST <runtimeUrl>/<connectionId>/v2/datasets/<server>,<database>/tables/<table>/items
Content-Type: application/json

Only real stored-procedure operations (ExecuteProcedure, ExecuteProcedure_V2) should use the /procedures route.

Actual behavior

Every SQL Server action returns 404 Resource not found. Going by the code, the URL that gets built has this shape:

<runtimeUrl>/<connectionId>/datasets//procedures/{connectionId}/v2/datasets/{server},{database}/tables/{table}/items

The literal {connectionId}, {server}, {database} and {table} placeholders are never substituted.

In the same app, on the same connection and at the same moment, table-mode getAll() returns 200.

Screenshots or Error Messages

Each action call returned:

{"message":"{\"statusCode\":404,\"message\":\"Resource not found\"}","status":404}

Observed repeatedly between 2026-10-20T15:30Z and 15:44Z (UTC) for:

• ExecutePassThroughNativeQuery_V2 (4 different queries)
• GetTables_V2 with the real server and database
• GetTables_V2 with "default","default"

Relevant library code (@microsoft/managed-apps-common 0.19.0, dist/dataClient/data/connectorExecutor.js):

async _buildOperationUrl(operation, config) {
  const isSharedSql = (config.apiId ?? '').indexOf('shared_sql') > -1;   // line 333
  const path = dataSourceInfo.apis[operationName].path;                 // raw template
  if (isSharedSql) {
    return this._buildSharedSqlOperationUrl(config, path);              // line 336
  }
  return this._buildStandardOperationUrl(operation, config, operationName, path);
}
_buildSharedSqlOperationUrl(config, path) {
  const version = config.version ? `/${config.version}/` : '/';
  const base = this._joinRuntimeAndConnection(config.runtimeUrl, config.connectionId);
  return `${base}${version}datasets/${config.datasetName}/procedures${path}`;   // line 381
}

Environment information

• Node.js and npm version: node v24.7.0, npm 11.19.0 (bun 1.3.14 is used by the template's dev server)
• Are you on an enterprise network (e.g. behind a corporate proxy or firewall)? Not relevant: the URL is wrong before the request leaves the client library. Reproduced in the hosted App Builder preview in Copilot Studio; requests are relayed by the Power Platform host.
• Framework, build tool or relevant package used: React 19.2.5, Vite 7.3.5, TypeScript 5.8.3, @tanstack/react-query 5.100.6, @microsoft/managed-apps 0.5.11 (@microsoft/managed-apps-common 0.19.0)
• Any connection/components: SQL Server connector (shared_sql), Microsoft Entra ID Integrated authentication, target is a Microsoft Fabric SQL database (AdventureWorksLT sample)

Additional context

• PostItem_V2 (Insert row (V2)) was deliberately not sent live, to avoid writing a test row to a real database. Its failure is inferred from the code above, which is the same path that produced the observed 404s.
• Removing and re-adding the action-mode data source after a usable connection existed did not change the result.
• Combined with the table-mode 415 bug, an app in this version has no working way to write to SQL Server: table inserts fail with 415 and every action fails with 404.
• Suggested fix:
  • Route to /procedures only for the stored-procedure operations.
  • Send every other shared_sql operation through _buildStandardOperationUrl with path-parameter substitution.
  • Match the api id exactly (shared_sql) rather than by substring.