Forum Discussion

msturzen's avatar
msturzen
Frequent Visitor
1 month ago
Solved

GraphQL update... mutation for Fabric SQL DB failing

Hi everybody,  I want to update items in a Fabric SQL DB via GraphQL mutation query. But that fails with "InternalServerError" (and nothing else).  What I tried:  ❌ mutation update.... ✅ mutatio...
API for GraphQL
data engineering
  • msturzen's avatar
    msturzen
    15 days ago

    Hi everyone, 

    After corresponding with MSFT support team I got some feedback and insights. Summing it up here hoping it might be useful to others some time. (This is the result as of Sept. 16th 2026)

    On the traces support found the following error message: "The target table 'dbo.table' of the DML statement cannot have any enabled triggers if the statement contains an OUTPUT clause without INTO clause."

    1. Addtional bit of info, that I stripped initially since I didn't think it could be the culprit 😯:
      The table used has an update trigger (updates the updated_at column)
    2. Fabric's GraphQL engine generates an UPDATE ... OUTPUT ... SQL statement (without an INTO clause)
      This is done (my guess) to be able to return the requested columns without an additional select after the update (update does not return the updated rows directly)
    3. SQL Server does not allow the above statement if there are enabled update triggers on the table. See: https://learn.microsoft.com/en-us/sql/t-sql/queries/output-clause-transact-sql?view=sql-server-ver17#triggers.  This is due to timing/racing and consistency issues.

     

    This leaves me with the following options: 

    • Do not use triggers:
      • Delete or disable (or do not create) them for the mutations you want to use (UPDATE trigger in my case), but then you lose the action the the trigger performs
      • If the action is necessary replace the trigger logic (possible in my case: Caller could just add a value for UPDATED_AT column, but would everyone do so?)
    • Use a stored procedure to do the update with an INTO clause using a @table_variable

     

    I'm not a big fan of either. I'd be very fond of the GraphQL implementation being changed to use the OUTPUT ... INTO ... solution suggested. It seems strange that a (imo) legitimate use of trigger is prohibited by an implementation detail of the GraphQL layer. I'm not very confident though this will land any time soon.

    I want to thank Tharun from the support team for helping.

    Best Martin

ipkus's avatar
ipkus
Frequent Visitor
1 month ago

Yes, GraphQL can be slightly sensitive when it comes to mutations. We have been able to implement several mutations via strored procdures.  

 

Looks like your mutation has gotten classified as a write-only (Mutation). This means it doesn't produce a Query node. GraphQL schema generation requires at least one Query field by spec — without it, schema validation fails. In the absence of a Query field, schema validation cannot be completed successfully.

Also, make sure Referenced tables are present and accessible in the underlying data source. If the required tables are unavailable, the stored procedure may fail and return a SQL error.

msturzen's avatar
msturzen
Frequent Visitor
1 month ago

Thank you so much for your reply ipkus. and confirming using a stored procedure is a way to enable updates.

Regarding your other statements:

  • What do mean by "slightly sensitive"? Is it pure luck for mutations work? Do I have to roll a D20? (sorry for being grumpy here, not your fault)
  • Is there anything I can do to get rid of that write-only classification?
    • Querying the resource works just fine --> (naive) conclusio: Seems not be write-only
    • What is a Query field? ROWID, other fields of the resource?
  • Thanks for hinting at availability of Referenced tables. In my case there no references. 
  • Unfortunately I do not see any SQL error in the response and Fabric SQL DB is very limited wrt monitoring. Any ideas for this?