Budibase attempts INSERT instead of UPDATE when editing an existing row (SQL Server datasource)

[shotoneko]

Description

Hi everyone,

I’m running into a critical issue with Budibase when using a SQL Server datasource.

I have a table Proveedores with a primary key (id_proveedor) and a UNIQUE constraint on RUT.
When editing an existing record (via a modal / edit form), Budibase attempts to INSERT a new row instead of UPDATE the existing one, which causes constraint violations (duplicate RUT, NULL in NOT NULL columns, etc.).

What I’ve confirmed so far

SQL Server traces (sys.dm_exec_input_buffer) clearly show:

INSERT INTO [Proveedores] (...) VALUES (...);
SELECT SCOPE_IDENTITY();

instead of an UPDATE.

This happens even when:
The modal is intended for editing
The Save button is configured manually

I execute a custom SQL UPDATE query with explicit bindings

The INSERT is not coming from my query — it appears Budibase is automatically issuing a Create Row operation in the background.

Additional context

The table has relationships defined (foreign keys), but the edit form does not include relationship fields.

Budibase still seems to “sync” relationships or treat the form as a create operation if row context is lost.
When Docker / Budibase backend is unstable or reconnecting, this behavior becomes more frequent.
Using SQL Server constraints, this results in:
duplicate key errors
Cannot insert NULL into column ...
I can fully reproduce and confirm this from the SQL Server side.

What I’m trying to understand

Under what conditions does Budibase decide to run INSERT instead of UPDATE for an edit form?

How can I force a true UPDATE and completely disable automatic CREATE behavior?
Is there a known issue with row context being lost in modals or when relations exist in the datasource schema?
Is the recommended approach to avoid “Save Row” entirely and only use custom queries / stored procedures?
At this point, updating existing rows is unreliable because Budibase consistently attempts to create new records.
Any guidance, confirmation of expected behavior, or workaround would be greatly appreciated.

Thanks in advance.