SQL search for data export function

Hello Backendless team!

In our project, we often have to unload data from the database. For this, the system has an excellent feature called export. But I think it lacks one very useful feature as unloading certain data that I need and not the entire table. Because in some tables we have millions of records and the export in this case does not work quickly, but in fact I need only 300 records from there for example.

In the BL console there are a lot of places where there is a SQL search and this is great and very convenient. I think it’s time to apply this feature to data export :slight_smile:


Hi @Leonid_Turkevitch

We will consider adding this feature. When adding this task to our roadmap, we will inform you here.

Thanks @Vladimir_Yalovy

@Leonid_Turkevitch, the export screen provides a way to select one or more (or all) data tables. An SQL query (or it should be a where clause in the Backendless lingo) applies to a single table. How would you modify the export screen to accommodate your idea?


Hello @mark-piller

Honestly, I personally did not encounter tasks when I need to export at the same time for an example of five tables and for each of them I need to apply a where clause.
But your question make sanse.
Of course, you can go the simplest way but the least attractive for users by adding one where clause input field to the application. That will work by condition if the table is selected alone, then this field is available, if there is a lot of that is not available.
But the idea of processing multiple tables is more attractive :slight_smile:
Therefore, I would do the following:
Near the All Data tables checkbox, I would add another called Use Where Clause
Further, the user turned on this checkbox and selected the required tables and then when he click on Export button (In this case, the text is better to change to something like Continue) the app will show to him popup includes the list with table name and near input for where clause.

There is an important point here. The application must keep the state of the filled fields until the final request is sent to the server to perform the export. Because there can be a lot of fields filled in and that if the user chooses an extra table or, on the contrary, he forgot to choose one of the tables. He will get a very bad experience if he has to fill it all over again.


This can get complicated very quickly, plus the approach is error-prone. For example, what if the where clause has a syntax error? what if the where clause is grammatically correct, but returns no data because it logically invalid? Our approach everywhere else in console is to provide feedback to the user about any errors and let them preview the data first. We should be consistent here in that regard. I think we will approach “conditional export” somewhat differently. We plan to add support for “database views”, which would work quite similarly as the traditional Views and Stored Procedures in MySQL or SQL Server. Once we have views working, creating an export for a view would do exactly what you want. So with one feature, you get two functions: being able to retrieve data into an app with a predefined condition and run an export for the same condition.