Export to CSV of empty query fails

OS info

  • Operating System : Windows 10.0.17763
  • Wappler Version : 2.4.5

Problem description

The server-side facility to export the result of a query as a CSV file makes the server action fail if the query is empty.

I’m not sure if this is a bug or my misplaced expectation.

The result I expect when the result of the query is empty is a CSV file created with just the header, not an outright abort of the server action.

Steps to reproduce

  1. Create a query
  2. Create a CSV export based on that query
  3. If the query produces a record set, the CSV file is created
  4. Modfy the query putting a condition that you know will produce no result set
  5. If the query produces no records as a result, the server action aborts

Maybe you should add a check for no records in the query before the export action…

Otherwise even if it worked you will get an empty file as export? Not sure if that is desired

1 Like

Thank you George.

I knew that I could work around this issue and check for the query result before invoking the csv export. I was trying to avoid doing that, though, because it complicates an already large server action that needs to generate a large number of CSV files.

For a user downloading the zip file with all the CSVs, it’s not obvious that some of them are missing not because the process that generated them failed but because the preceding query resulted in no records.

A CSV file with just the header is imho a bit of a better way of saying “don’t worry, the work was done, even though there are no results to show” than the absence of that file.

But that’s my opinion :slight_smile:


I had a similar situation with one of my jobs, what i did was to replace the Download CSV button with a warning that their search or filtering produced no results and thats why there was no download button even available for them to click.

In my app I had a massive list of say 60k results in a paged query, that had about 6 filtering parameters, as each parameter was selected the list refreshed with the latest results, until their list could have contained 5 results only or 500 results depending on what filters were applied.

With no filters selected all the way to all filters selected, the DOWNLOAD CSV button would download exactly what the user was viewing.

In general because the filters were “form selects”, this was done with dynamic dropdowns, to avoid blank lists as far as possible, however there are still certain scenarios where the user may be returned an empty list, which is why as a secondary function i added a condition to the DOWNLOAD CSV button to not display when no results were available.

Personally I think this is the least confusing or frustrating solution for a client, imagine doing 6 searches or more and downloading file after file that only have header rows, my way, no download, no going to finder to open the file, equated to less client frustration.

I see your point. In your case, it’s definitely worth doing it that way

In my case, the interaction is to produce a known set of CSV files. The process starts by clicking a button that fires a long server action that first creates and updates records in tables, then produces the series of CSV files based on filtered conditions of those tables, and finally zips the folder with all the produced CSVs. On successful return, the form that fired the server action downloads the zip file.

Since the user expects to see always the same number of files in the zip, missing files may be misinterpreted as an error conditionI was a bit lazy and did not want to create a manifest within the zip but maybe I have to create it. I’ll think a bit more about it. Maybe I could start the run using a base set of csv files with “just the header” and then overwrite them with my process. Or maybe the real work around this issue is to train the users :slight_smile:

Thanks for your feedback,