Forum Discussion
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....
- ✅ mutation create...
- ✅ mutation delete...
✅ (directly in the SQL DB): UPDATE dbo.product SET product_name = 'CHANGED' WHERE ROWID = '<UUID>'
Did someone else here experience something similar? Is this a defect 🐞 in the GraphQL API / Fabric SQL DB / their combination?
What was your solution? (And what was the issue exactly?)
A workaround might be to create a stored proc and let that do the update. I'd prefer to be able to use a working update mutation though. So
Any help highly appreciated! <3 --> Snippets below
Best
Martin
(Snippets stripped down for readability)
The failing mutation:
mutation {
updateproduct (
ROWID: "<UUID>",
item: {
product_name: "CHANGED"
})
{
ROWID product_name
}
}
//// Definitions from the GraphQL schema:
"""Updates a product"""
updateproduct (
"""The ID of the item being updated."""
ROWID: UUID!
"""Input representing all the fields for updating product"""
item: UpdateproductInput!
): product
"""Input type for updating product_mapping"""
input UpdateproductInput {
"""Input for field ROWID on type UpdateproductInput"""
ROWID: UUID
"""Input for field product_name on type UpdateproductInput"""
product_name: String
}The table in Fabric SQL DB (as by "Script as create")
CREATE TABLE [dbo].[product](
[ROWID] [uniqueidentifier] NOT NULL,
[product_name] [nvarchar](255) NOT NULL,
) ON [PRIMARY]
ALTER TABLE [dbo].[product_mapping]
ADD PRIMARY KEY CLUSTERED (
[ROWID] ASC
) WITH ( STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF,
ONLINE = OFF, OPTIMIZE_FOR_SEQUENTIAL_KEY = OFF)
ON [PRIMARY]
ALTER TABLE [dbo].[product_mapping]
ADD DEFAULT (newsequentialid()) FOR [ROWID]
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."
- 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) - 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) - 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- Addtional bit of info, that I stripped initially since I didn't think it could be the culprit 😯:
16 Replies
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.
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?
I understand your frustration. Yes, querying part works well
The error have been very cryptic in Fabric. Give below a try
- Import a table ( only having mutations can cause issues )
- Create a test procedure with the output columns same as input and add additional return values as needed.
- Import that procedure into Graph QL
- This method works well. Once this works for you, you can tweak and play around with settings
Thanks again,
I will try to work from your sample but thath might take a few days....Will come back asap
Best
Martin
v-achippaCommunity Support
Hi msturzen,
Thank you for reaching out to Microsoft Fabric Community.
Thank you ipkus for the prompt response.
As we haven’t heard back from you, we wanted to kindly follow up to check if the solution provided by the user for the issue worked? or let us know if you need any further assistance.
Thanks and regards,
Anjan Kumar ChippaDear v-achippa,
to me there is no solution yet. All I have is a workaround for something - update of a single row in a SQL DB - that should just work out of the box. Don't get me wrong: I am thankful for the workaround.
At least - if there is some known product limitation - that should be documented in Fabric's GraphQL API documentation
Thanks
Martin
- Kagiyama_yutaka
Continued Contributor
Fabric graphql only runs an update when the exposed schema shows that column writable, and the call stops when the input includes the pk field; sending just the writable column or doing the change through a tiny proc stays inside the normal behavior.
Hi Kagiyama_yutaka,
the update mutation requires the pk column as the query's first argument so it can identify the row to update. The PK column itself is not updated in the update snippet I posted initially.
I only send the writable column or am I misreading something?
Best
Martin
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."
- Additional 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) - Fabric's GraphQL engine generates SQL similar like this for the update mutation:
UPDATE _table_
This is done to be able to return the requested columns without an additional select after the update (update does not return the updated rows directly)
SET _fields_
OUTPUT _requested-fields_ -- no 'INTO table_variable or table' option here!!!
WHERE _primary-key_ - 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- Additional bit of info, that I stripped initially since I didn't think it could be the culprit 😯:
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."
- 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) - 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) - 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 MartinPing v-achippa
- Addtional bit of info, that I stripped initially since I didn't think it could be the culprit 😯:
