Skip to main content

When exporting data from a table, it is limiting the record output to the number of records listed in the record count at the bottom of the table (e.g. Showing Rows 1-10 of 10+).


Given this behavior, if a user wants to export all the data in an object, they need to scroll through the entire dataset and then click export. This is inconvenient even with smaller datasets but for larger datasets, this is an absolute nuisance.


Additionally, this is counter to the way that standard salesforce reports work and therefore introduces inconsistency in to the overall platform. In an SFDC report, you get 2000 records but when you click export, you get all the data in the CSV/XLSX.


Steps to reproduce:


  1. Make sure there is more than 1 record in Account Object

  2. Create page using XML below

  3. Preview Page

  4. Click Export Icon

Expected Behavior

Exported record count should equal number of records in Account Object


Actual Behavior

1 record is exported because


Sample Page


<skuidpage unsavedchangeswarning="yes" personalizationmode="server" showsidebar="true" showheader="true" tabtooverride="Account">   <models>

      <model id="Account" limit="1" query="true" createrowifnonefound="false" sobject="Account" adapter="" type="">

         <fields>

            <field id="Name"/>

            <field id="CreatedDate"/>

         </fields>

         <conditions/>

         <actions/>

      </model>

   </models>

   <components>

      <pagetitle model="Account" uniqueid="sk-1T1Yns-68">

         <maintitle>

            <template>{{Model.labelPlural}}</template>

         </maintitle>

         <subtitle>

            <template>Home</template>

         </subtitle>

         <actions>

            <action type="savecancel"/>

         </actions>

      </pagetitle>

      <skootable showconditions="true" showsavecancel="false" searchmethod="server" searchbox="true" showexportbuttons="true" pagesize="10" createrecords="true" model="Account" mode="read" uniqueid="sk-1T1Yns-69">

         <fields>

            <field id="Name" allowordering="true"/>

            <field id="CreatedDate" allowordering="true"/>

         </fields>

         <rowactions>

            <action type="edit"/>

            <action type="delete"/>

         </rowactions>

         <massactions usefirstitemasdefault="true">

            <action type="massupdate"/>

            <action type="massdelete"/>

         </massactions>

         <views>

            <view type="standard"/>

         </views>

         <exportproperties usetablecolumns="true"/>

      </skootable>

   </components>

   <resources>

      <labels/>

      <css/>

      <javascript/>

   </resources>

   <styles>

      <styleitem type="background" bgtype="none"/>

   </styles>

</skuidpage>

I believe there is a setting on the export button: “attempt to load all rows before export”. It is off by default, but if you check it, it should allow all rows to be exported.

Yep. The tricky (not-so-intuitive) part is that after you check the box to allow exporting, you have to click on the little Export icon below the table in the builder to get the export options.

Raymond - Thanks for the guidance!!  Enabling that option triggers Skuid to pull all the data down to the client prior to export.

Skuid - 

Even with the “export all” option enabled, the table export is limited to 11000 rows (even though it indicates max of 10,000 - I’m guessing it’s a Max Load Count size thing).  Additionally, there is no message to the user that there are more records so the user is left to believe that they have everything.  This issue is posted separately at https://community.skuid.com/t/table-limits-record-retrieval-to-11-000-records-in-a-table-….

My question now is why does the table component pull down all the data, then send it to the server for export as opposed to just re-issuing the SOQL on the server and generating the file there? The current approach is counter to the way web based “exports” typically work.  For large datasets, pulling down everything to the client, only to send it right back to the server seems incredibly inefficient and limiting.

Thanks!

Other posts I have read have basically said that Skuid isn’t built for working with huge data and you should use standard Salesforce exporting for those needs. The rudimentary work around might be to put a rich text field just below the table that says "Table Maximum 11,000 rows. If attempting to access more than 11,000 records, use this report: (Insert Salesforce Report Hyperlink Here).

Thanks Raymond, as always, like your creativity with the RTF workaround 🙂  With the push to use Skuid and our app completely skinning SFDC, taking users back out to SFDC reports is not very desirable (different UI/UX experience completely) but a valid workaround nonetheless.

The main questions/concerns I have are:

1) Resultset is limited
2) There is no automatic notification when there is more data available (even though you currently can’t access it)
3) Technical approach to how paging and data export works is inefficient and limiting.  

Looking for input from Skuid on this to help fix anything that might be considered a bug and/or improve the product moving forward.  

Agreed. The Skuid Gods may want to check this out:
https://developer.salesforce.com/docs…

Based on great insight from JD/Ben in the thread at https://community.skuid.com/t/table-limits-record-retrieval-to-11-000-records-in-a-table-…, here’s an update on this:

#1 - Limited Resultset - This is a limitation of Standard Set Controller (https://developer.salesforce.com/page/Paginating_Data_for_Force.com_Applications).  An enhancement request has been created at https://community.skuid.com/t/allow-models-to-load-more-than-10-000-rows?rfm=1&topic_…

#2 - No automatic notification - This is a bug and is being tracked at https://community.skuid.com/t/no-warning-message-display-when-there-is-more-data-to-load-…

#3 - Export Technical Approach - The reason the rows are sent from client to server instead of just re-issuing SOQL on server is that export supports UI-Only fields, templates and External Data.  


Reply


View our Community Site Map

Nintex Community Sitemap
Terms & ConditionsCookie settings