Create a record for non primary key based table

Question

I have a table X which does not have a primary key. the format of data is something like this,

Indentifier for Request 
 Emails [non Unique] 
 Column A

ABC123 
 useremail@email.com 
 A

ABC123 
 useremail@email.com 
 V

XYZ582 
 User2@email.com 
 D

I have to create a record to view this data. 
 Notes: 
 
 there is no primary key to this table. 
 Indentifier column is currently marked as primary key in table. 
 this table is not handled by Appian and is only referenced for data. 
 the table has more than 800 thousand rows at one time on average. the custom plugin breaks if user tries to export all data at once. [Business req. on export from Appian] 
 
 The record list breaks with following error: Expression evaluation error at function a!gridField [line 27]: A grid component [label=&ldquo;&rdquo;] has an invalid value for &ldquo;totalCount&rdquo;. &ldquo;totalCount&rdquo; must not be null or less than the number of items in any of the &ldquo;data&rdquo; arrays, but &ldquo;totalCount&rdquo; was XX and the largest column data array had XXXXX items. Why record: I would like to leverage the filters and export functionality from records for this table. I know this can be achieved using query entity and export to excel plugin however I would like to know If this can be achieved in records which has all these functionalities inbuilt.

Mike Schmitt · Answer

Do you have any way of creating a View within Appian that references the external DB table? I'm not sure the feasibility of such an approach but if something like this were possible (or if you could create a view in that other system specifically to be consumed by Appian), then there would be easier approaches to overcoming your issue I expect.

Mike Schmitt · Answer

My (vague) understanding of views is that they have no performance impact until they're run, i.e. there is no impact for the view just existing, until you try to query it. At that point the performance impact is essentially the same as a query into it.

Mike Schmitt · Answer

If your view is simple and mainly establishes a unique column by some means (either by row index or by concatenating some of the other column values in such a way that it's guaranteed to be unique), i wouldn't expect the query from that view to be particularly worse than querying from the original table. It wouldn't be *better*, but also might not actually be *worse*.