Facing issue with query entity

Views are notoriously known for performance issues. Any reason for not using synced records?

Views are notoriously known for performance issues. Any reason for not using synced records?

Ultimately the value of sync'ed records shine here - with an uncommon caveat about data stewardship.

If the view is in a remote data source that another team controls, then the Appian environment also (usually...) has access to the view's underlying tables and thus could sync / manage logic more directly. However, if that other team also controls the logic of the view, then suddenly that logic has to be synchronized across multiple technical teams. It turns into a people / governance problem at that point.

View is used because - 

1. We have many calculated columns to show in view.

2. Data to be fetched from multiple tables

Sync'ed records support both of these points, and excel at the latter.  Is there anything specific about your view's calculations that cannot be replicated in sync'ed record logic?

If sync'ed records are truly out of the question, then must the calculations be completed 'live', or can the calculations be completed and stored every time the data is changed in specific ways? In my experience it is rare that calculations MUST be live, but rather, the calculations are done live because that is easy, saves development time, and this method doesn't become a problem in most cases. For your case, if the calculations cause query timeouts, (especially at scale), then it's worth investing some time into a little refactoring.

• Process Re-engineering/Non GFT/ITeSS (and other valid values) would get stored into a non-view table (let's call it "Inventory_Calcs" for now) in table's currentReductionStage column
• Every time something relevant to the calculation of currentReductionStage changes for the relevant records, the currentReductionStage for the associated eucInventoryId gets updated to the proper valid value. This can be done with an Appian process (preferred if you control all of the logic), or database function / stored procedure if a non-Appian team controls the logic
• Your current view (whatever backs ELMRISKREDUCTIONLANDINGPAGEVW) would do a simple join to the Inventory_Calcs table and retrieve the pre-calculated value.

If the view must be calculated live for business-related reasons, then does every column need to be calculated every time the view is called? If not, it may be more efficient to split your view up into multiple views and multiple queries in order only perform the calculations when they're needed on the UI or in process. Depending on the use of sub-selects / CTE's in the view, it is possible that swapping from the equivalent of (SELECT * FROM <view>) to (SELECT <columnA ... columnN> FROM <view> ) will not yield any performance since the optimizer can't sus out all of the indirect relationships of the selected columns to CTE's, so it calculates everything to ensure data integrity. This particular case was why I refactored a particularly tough view into sync'ed records last year, fwiw.