SQL Connector Limit

I am looking to move an old inhouse IIS application to Bubble, using my SQL database hosted on Azure. I have connected and used my stored procedures with no problem. However, I have queries that return more than 200 records (for dropdowns, for instance). While they don’t return thousands of records, they must return several hundred.

Is the 200 limit a hard limit or more of a ‘be responsible’ limit? Without this, it would make the app too limiting/not user friendly. So, I’m hoping this isn’t a hard limit, although it appears my stored procedure call that returns about 400 records is not initializing, so that leads me to this question.

What type of content are you using that 200 options would be in a dropdown? That feels like a really, really unwieldy dropdown.

Creating a timesheet with dropdowns for Customers and Projects. The Customer list is about 380 that are active.

I see. We use a timesheet system at my day job that has a dropdown for selecting client, also. The dropdown shows the 10 most recently used clients, then an option to “find” more using a search bar. I’m not sure on the Bubble limitation, but there’s probably a better UX that could be implemented that doesn’t hit the query limitation (if one exists).

1 Like

Try and run dreamfactory on azure to automatically create API sets for you SQL server. This way you don’t need to handle this through SQL

I have many complicated Stored Procedures that I am hoping to leverage and reuse. Not sure if using dreamfactory would mean me rewriting all this, which I want to avoid.

This is really a deal breaker for me. Hope there is an easy answer to this.

How about paging with OFFSET FETCH, and make multiple calls to get the next set?

http://technet.microsoft.com/en-us/library/gg699618.aspx

1 Like

Thanks. Would have to play with how to make repeated calls and then keep loading results to maybe a repeating group that then gets loaded to the dropdown or something. Just not clear on how to make the repeated calls.

1 Like

Thanks. The top 10 used is a good idea to think about. But was hoping for something other than a ‘search/find’, as this would make the UX a bit awkward going from clicking to typing, back to clicking, and then back to typing (based on the layout for a typical timesheet. Wish it was easier. Spending too much time trying to make a work around for such a simple UI element.

Back to working on this issue. I see how to work with the fetch idea, and can modify my sql stored procedure to work with passed parameters to handle this. But how do I make repeated calls in a workflow until a certain condition (I assume in a state that will be used to update the parameters used in the search) to add to a repeating group to old this returned data?

Would also love to be able to use this to load multiple records into a Bubble database.

Running repeated SQL calls is going to perform poorly, I’d only consider that for a backend process that doesn’t care how long it takes.

Maybe a better solution is using the data API to push data into Bubble’s database.

Or wrap an API around the SQL database and call that from the Bubble page, as suggested earlier by @AliFarahat

Thanks. Moved to the API Method suggested by @AliFarahat, which works. Found a service that was resonably priced to add APIs to existing databases called SlashDB. Didn’t need to learn to write APIs. Passing this info on to others, in case it helps.

2 Likes