Budibase aims to make solving common problems very easy, and I can understand the design decision to not letting more complex scenarios clutter up their UI. But it still causes headaches for me. I ran into problems trying to display data across multiple tables, and then I learned creating a multi-table record in Budibase can get convoluted for related reasons. The first restriction is the built-in relationship picker tool, which helpfully presents the display column text (Target) and when selected enters the foreign key (476) into the table. But relationship picker has a hard coded ceiling of 100 entries. I don't have 100 accounts or 100 categories so those will work, but I have definitely shopped at more than 100 vendors! I had to create my own UI to manage the vendor relationship.

I want to write down the next problem here even though it is not yet well understood. Since Budibase couldn't help me create these multi-table entries directly, I wrote my own interface using Budibase form objects, button objects, and actions associated with button click. The idea is that each form would be a row in one table, and when I click a button, I would use several "Update Field Value" actions to update multiple forms with data generated by my data binding. Then I would use the "Save Row" action on each of those forms to submit my multi-table entry. The idea is to have a mechanism to handle regularly occurring repetitive tasks with a single click.

In practice, my single button would intermittently fail with "Null not allowed" error. If I click my button again, it would always succeed, but then I might have duplicate entries in my database due to my multi-table hack failing partway. This feels like an asynchronous race condition with "Save Row" being executed before all previous "Update Field Value" actions had completed. When I click again a second later, all of the fields are already updated so save row works.

Many databases have a mechanism to designate set of operations as a single "transaction" unit. The database is responsible for guaranteeing "all or nothing". Either every part of the transaction is successful and written to the database ("commit") or if something goes wrong, it should be as if nothing had happened. ("revert") I looked for transaction support via Budibase but didn't find anything.

Looking for a workaround, I searched for a "Wait for previous action to complete before proceeding" action but didn't find one, nor did I find anything like a "Wait X second" action. So my workaround is to use two buttons: one has all the "Update Field Value" actions, and a second button with all "Save Row" actions. I click one, then I click the other. Two button clicks is double the amount I thought it should take, but it is still better than doing all the repetitive steps by hand. Still, it doesn't mask the fact the whole situation is pretty silly and I think reflects a bug in Budibase. But since I'm a beginner it could be my own fault for reasons I don't understand yet. I'll have to play with Budibase some more.