Skip to content

[Bug]: Multi Datasource rest and swagger not working #3638

Open
0 of 1 issue completed
Open

Description

@pontiusmatt

What happened?

Hello, I have tried a couple different versions of creating a multi datasource configuration. I have two databases, that I want to use one DAB instance to span across (not joining data or anything, just exposing endpoints for the two databases). I have deployed this in a test/dev environment and I have swagger picking up the entities in the second config (datasource and entities only in this one) file but is not picking up the methods available. That said, when I try to post to a couple of the tables to do inserts I get 500 errors, but the stored procedure calls work fine and the reads seem to work fine.

Version

1.7.93

What database are you using?

Azure SQL

What hosting model are you using?

Container Apps

Which API approach are you accessing DAB through?

No response

Relevant log output


Code of Conduct

  • I agree to follow this project's Code of Conduct

Activity

  1. pontiusmatt commented on Jun 9, 2026

    @pontiusmatt
    Author

    Just confirming - I am seeing the same behaivor in 2.0.8 version of DAB as well

  2. pontiusmatt commented on Jun 9, 2026

    @pontiusmatt
    Author

    Also - the API approach we are trying to use is the REST api.

  3. pontiusmatt commented on Jun 15, 2026

    @pontiusmatt
    Author

    Is anyone else running into this issue or am I potentially doing something wrong?

  4. JerryNixon commented on Jul 7, 2026

    @JerryNixon
    Contributor

    Confirmed.

  5. JerryNixon commented on Jul 7, 2026

    @JerryNixon
    Contributor

    Hi,

    Yes — one DAB instance can serve multiple databases. Each database goes in its own config file, linked from a root config via data-source-files. I validated this with Microsoft.DataApiBuilder 2.0.9.

    What works: reads, stored procedures, and Swagger/OpenAPI across both databases.

    The bug you hit: POST/PUT/PATCH/DELETE on a table in a linked file returns HTTP 500. I reproduced it and confirmed the cause is positional — the same table writes fine in the root config and fails in a linked file. Reads and stored procedures are unaffected because they don't use the table-mutation path.

    Workaround (pick one, until fixed)

    1. Put writable tables in the root config, read-only tables in linked files. Simplest if only one DB needs writes.
    2. Run one DAB instance per database behind a single gateway/reverse proxy (APIM, App Gateway, nginx, YARP). Full CRUD on every table, one API surface. Best when both DBs need writes.
    3. Expose writes as stored procedures — works, but only worth it if you must keep a single multi-source instance.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingcriCustomer Reported issuetriageissues to be triaged

    Type

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions