When
Using a multi-database setup where a root config links a second database config via data-source-files:
# Root config (database 1)
dab init --database-type mssql --connection-string "@env('DAB_SQL_DB1')" --host-mode Development -c dab-config.json
dab add Db1Orders --source dbo.Orders --permissions "anonymous:*" --source.type table -c dab-config.json
# Linked config (database 2)
dab init --database-type mssql --connection-string "@env('DAB_SQL_DB2')" --host-mode Development -c dab-config-db2.json
dab add Db2Customers --source dbo.Customers --permissions "anonymous:*" --source.type table -c dab-config-db2.json
# Link them
dab configure --data-source-files dab-config-db2.json -c dab-config.json
dab start -c dab-config.json
Then send a write to a table entity that is defined in the linked file (dab-config-db2.json):
POST /api/Db2Customers
Content-Type: application/json
{ "Name": "test" }
Expected
The insert succeeds and returns HTTP 201 with the created row, the same as an equivalent table entity defined in the root config. Table writes should work regardless of whether the entity's data source is in the root config or in a linked data-source-files config.
Actual
The request returns HTTP 500 with a generic error:
{
"error": {
"code": "UnexpectedError",
"message": "While processing your request the server ran into an unexpected error.",
"status": 500
}
}
The server log shows a KeyNotFoundException keyed by the entity name, thrown in the SQL mutation/insert path:
System.Collections.Generic.KeyNotFoundException: The given key 'Db2Customers' was not present in the dictionary.
at Azure.DataApiBuilder.Core.Resolvers.BaseQueryStructure..ctor(...)
at Azure.DataApiBuilder.Core.Resolvers.SqlInsertStructure..ctor(...)
at Azure.DataApiBuilder.Core.Resolvers.SqlMutationEngine.PerformMutationOperation(...)
Scope / Root cause (confirmed by test)
The failure is positional, not database- or table-specific. Swapping the topology proves it — the same table behaves differently based only on which config file it lives in:
| Table |
In root config |
In linked data-source-files config |
dbo.Categories |
POST succeeds (200/201) |
POST fails (500) |
dbo.Category |
POST succeeds (200/201) |
POST fails (500) |
Additional observations:
- Reads (
GET) work for linked-file entities.
- Stored procedures in linked files work (they use the
execute path, not the table-mutation path).
- Only table mutations (
POST/PUT/PATCH/DELETE) on linked-file entities fail.
dab validate passes and reports REST paths for all entities across both files.
Impact
In a multi-database DAB instance, tables in any linked (non-root) database are effectively read-only. Only the root database supports table writes.
When
Using a multi-database setup where a root config links a second database config via
data-source-files:Then send a write to a table entity that is defined in the linked file (
dab-config-db2.json):Expected
The insert succeeds and returns HTTP 201 with the created row, the same as an equivalent table entity defined in the root config. Table writes should work regardless of whether the entity's data source is in the root config or in a linked
data-source-filesconfig.Actual
The request returns HTTP 500 with a generic error:
{ "error": { "code": "UnexpectedError", "message": "While processing your request the server ran into an unexpected error.", "status": 500 } }The server log shows a
KeyNotFoundExceptionkeyed by the entity name, thrown in the SQL mutation/insert path:Scope / Root cause (confirmed by test)
The failure is positional, not database- or table-specific. Swapping the topology proves it — the same table behaves differently based only on which config file it lives in:
data-source-filesconfigdbo.Categoriesdbo.CategoryAdditional observations:
GET) work for linked-file entities.executepath, not the table-mutation path).POST/PUT/PATCH/DELETE) on linked-file entities fail.dab validatepasses and reports REST paths for all entities across both files.Impact
In a multi-database DAB instance, tables in any linked (non-root) database are effectively read-only. Only the root database supports table writes.