Mismatch in Exported excel and report

Hi, 

I have a report with ~1850 rows and when I export the report it gives me ~1880 rows. the data for the report UI is using a QyeryEntity from a database view and for the report it is directly from the database view and written to an excel template. 

Unable to figure out why the mismatch in the no of rows. 

TIA!

  Discussion posts and replies are publicly visible

Parents
  • If you're basing the lower number of rows on the "totalcount" you get from the Appian query entity, then it might appear lower than it really should be if the Primary Key column is not unique.  As far as I can tell (and after testing specific use cases), the totalCount is calculated based on unique instances of the primary key column in the view (at least when not running a query that returns all rows).  So in other words, if you had a view where querying just the primary key column returned {1, 2, 3, 3, 3, 4}, then the blind totalCount returned would be 4 (when you probably expected 6).

    The real solution for this is to make sure every view is set up such that whichever column you define as the primary key in the CDT, generates a unique value.  Sometimes for merged data sets this might seem hard or impossible, but I've found that concatenating the primary keys of the source tables can work (i suggest joining them with a "-" or other non-numeric character to avoid accidental overlaps).  So for example, the primary key column might have values like {"1-1", "1-2", "2-1", "3-1", "4-1"} (when before you may have just had {1, 1, 2, 3, 4}).

Reply
  • If you're basing the lower number of rows on the "totalcount" you get from the Appian query entity, then it might appear lower than it really should be if the Primary Key column is not unique.  As far as I can tell (and after testing specific use cases), the totalCount is calculated based on unique instances of the primary key column in the view (at least when not running a query that returns all rows).  So in other words, if you had a view where querying just the primary key column returned {1, 2, 3, 3, 3, 4}, then the blind totalCount returned would be 4 (when you probably expected 6).

    The real solution for this is to make sure every view is set up such that whichever column you define as the primary key in the CDT, generates a unique value.  Sometimes for merged data sets this might seem hard or impossible, but I've found that concatenating the primary keys of the source tables can work (i suggest joining them with a "-" or other non-numeric character to avoid accidental overlaps).  So for example, the primary key column might have values like {"1-1", "1-2", "2-1", "3-1", "4-1"} (when before you may have just had {1, 1, 2, 3, 4}).

Children
No Data