Updating multiple records from RG to SQL external database

I have a RG where I return records from a SQL Database (using API Connector). I then populate two other RGs, based on a field called ‘Selected’. If Selected, then The record stays in RG1, if they user clicks on it in RG1, that will Unselect it, at which point I move it to RG2. I call out to an API that sets the field and writes it back to the sql database. My problem is I’d like to be able to allow the user to select multiple records at once, using a checkbox in RG1 and then click a button to apply it. This would move all the selected records to RG2 and call the API to update the SQL database records for those records they checked. I’m unclear as to how to make a call for each selected record in the RG. Without some sort of loop functionality, I’m unclear as to how to do this. I see examples using AP Workflows (which I don’t seem to understand), but they all work on bubble databases, not external databases like my external SQL database. Any help would be greatly appreciated! Thanks.

I think the approach you’re looking for is to “run a workflow on a list” which is essentially a loop function that works exclusively in the API. This lets you, for example, run one API call for each item in the list.

My confusion is that I don’t see an option for that ‘list’ to be a RG. Am I missing something?

I’m not quite sure I understand. A repeating group (RG) is simply a tool to visually display a list of things on the UI. You can have a list of things that isn’t displayed in a RG. Additionally, each table in your database essentially stores a list of things (each row is a “thing” in Bubble speak).

Does that help?

Questions rather than solutions …

If the lists are constrained to “a reasonable size”, like under 20 rows …

What are the limitations of the API you are using? For example, does it allow multi-row updates?

Can you combine the parameters into a list within a text form, or does each one need to be bound individually? Do you have access to create and run stored procedures, where you can define a large enough number of parameters?

If I was using Bubbles databases then I could select from them. But since my databases are on my SQL Server in the cloud, I don’t have them as an option. Hope I’m explaining this better.

I am using Bubbles API plugin. My APIs call out to my SQL Server. I have full control of the stored procedures, so I can modify them as needed. Does that help?

Assuming I could pass a lot of parameters/a list to update, back to my api, how do I get the RG record list data into a single list to pass?

For a list of text items bound to a single parameter, you can concatenate list data into a single text field using mylist's customer name :join and specify the delimiter.

For more complex structures with multiple fields, List Item Expression can come in handy.

For individual parameters, specifically reference the list items for each parameter, mylist #1's customer name

There are a lot of possible ways to do things, it will be interesting to see if you find something suitable.

Still no luck in getting this to work. I really think I must be missing something, or maybe this is another limitation when using outside databases (SQL hosted elsewhere in this case).

Rephrasing this, I am returning records from an API call (to an external SQL database) to a Repeating Group. I have added a checkbox onto the RG line, so that the user can check off the lines they want to select. Then I want the user to click a button that will call out to an API that calls the external SQL Database and updates a selected field in that database.

I only see ways to do this with the Bubble databases, using API Workflows, but not with external SQL database API calls.

Am I missing something or is this a limitation?

How to do it depends on the requirements of the APIs you use, which at the moment you haven’t disclosed any details for.

Whether to use API workflows or page workflows to send the data depends on whether you want a server-based flow and API call, or a client-based call.

Which is appropriate depends on whether it matters if the user alters what is sent, and whether this altering can be limited.

Another factor is whether you want to push processing to the background, to no longer depend on the user keeping the page open.

This in turn depends on your business meaning of the data.

Short version: more details will help get more ideas.

This topic was automatically closed after 70 days. New replies are no longer allowed.