The code I'm using consistently returns the next most recent entry in a SharePoint list as opposed to the most recent one. I built out a whole screen to test this so I could see everything going on. This allowed me to determine definitively that the filter part of the function is what causes this behavior. With the filter included it fails to find the very last qualifying record. Take the filter out and it works perfectly (except I need to have the filter of course).
Sequence is run code > add a record to SP > run code again in a minute or two and see failure.
I'm at a loss... how can a documented function behave so intermittently? How are we supposed to build reliable code blocks when the simpliest little piece of code only sometimes returns the last record?
The only other thing that helps is waiting a LONG time (like 15 minutes). Then it works the first time but executing again even a few minutes later it fails the first time again.
The target list is brand new, containing only plain text, number and date columns. Explicitly setting the ID using LookUp easily allows me to return the correct record, just not when I find it based on the filter condition.
So to clarify, with the filter in place in the example below, I expect to get record ID: 5 but I consistently get ID: 6. If I execute the code again, I then get the correct result (5) which appears to demonstrate that it is not the terms of the filter but that the last record is somehow not in a state that allows it to be returned in the result set the first time the code executes (even making all the records have filter parameters that qualify does not fix further demonstrating this).
Does not work
//find most recent previous entry matching conditions Refresh(Events); Set(varPreviousEvent, First( Sort( Filter( Events, EventClass = varCurrentEventClass, TaskID = varTask.ID), ID, Descending) ) );
|8||Task||983||I want & I get|
Refresh(Events); Set(varPreviousEvent, First( Sort( //Filter( Events, //EventClass = varCurrentEventClass, TaskID = varTask.ID), ID, Descending) ) );
Some things that didn't work:
Update: I just recreated another SP list and a new app and was EASILY able to recreate this issue... code only works the *second* time you click the button unless you wait several minuts. I need to use this code block on the fly to find and update records and can't have it only work sometimes, when it feels like it. I really don't know what to do... I need this simple function in dozens of places around my app. Is this a bug?
Solved! Go to Solution.
I think I discovered something important related to what is causing this!!!
In my test app, stripped of all unrelated and unneeded screens, datasources, etc. If I uncheck the feature "Use longer data cache timeout and background refresh" the lookup suddenly works as expected... ever time, reliably. If I turn it back it on, the problem immediately returns. Turn it back off, it is fixed.
Obviously I need to do some more testing on my actual production app but this is the first time I have found a reliable way to toggle this problem from fixed to broken and back again.
Another thing, I have felt from the beginning that a lookup function should not have to depend on a Refresh() before or after it as this is what the lookup does... in my testing, when the feature is turned off, my lookup works without any refresh of the Events table anywhere in the entire routine!
I was going to see if I could reproduce your issue on my local machine. I have one quick question so that my test is similar to yours: how many records do you have in your list?
Thanks so much @Drrickryp
The target list in this case started with about 100 but is now up to around 500 from my testing.
Delegation does not appear to be impacting this as I tried it with the app limit set well over the total records and to 1 with the same results.
Loading items into a gallery seems to work better but it is still fails about every fifth time, probably based on how fast I add the record then go back and click the button.
The code in PowerApps does not seem to always progress in a linear fashion as documented. I mean in theory I should be able to patch a new record > refresh datasource > then find that record by First(Filter(Sort but this straight up does not work. I'm catching all my errors to a table and only get etag errors if I try multiple operations without the refresh (which really slows everything down but that's another story).
I suspect this would work much better using a SQL source as the latency may be coming from the SP list but it is too late to make this switch now so I am kind of stuck I guess.
Loading into gallery first
Refresh(Events); Set(varPreviousEvent, First( Filter( Sort( GalleryAllRecentEvents.AllItems, ID, Descending), EventClass = varCurrentEventClass, TaskID = varTask.ID) ) );
I don't get it...
I just sat here and added records to the SharePoint list, refreshed the list sorted by ID and noted that the highest ID was 665. I then waited 30 seconds and went to a button on my app and pressed it with this exact code and watched varOutputOperation1 update from 660 to 663. I pressed it again and watched it update to 665. This is by far the simplest part of my whole app and it doesn't work! How can I rely on a PowerApp full of complex code if a dead simple formula like this one can not work as expected?
Set(varOutputOperation1, First( Filter( Sort( Events, ID, Descending), EventClass = varCurrentEventClass, TaskID = varTask.ID) ) )
I'm not sure about your datasource and other variables but since you are using ID as the filter and it's unique. Why bother with the first, filter and sort.
Set(varPreviousEvent, Lookup(GalleryAllRecentEvents.AllItems, EventClass = varCurrentEventClass, TaskID = varTask.ID) )
Lookup() is delegatable in Sharepoint and all of the work will be done on the server side. It ought to be fast. Same would go throughout your app where ever you are using First(Filter(Sort)))
Hmm... so you are saying that LookUp returns the highest ID by default so all I need are the filter arguments?
The filter had seemed to be the problem but this certainly seems to be worth a shot... let me see if this changes things and THANKS! I'm really tearing my hair out on this on :-/
There must be something wrong with either my app or my list.
Returns the first (lowest ID) record meeting both conditions
Set(varNewPreviousEvent, LookUp(Events, EventClass = varCurrentEventClass && TaskID = varTask.ID ) )
Behaves exactly like what was happening before, add records > click > no change > click again > right result
Set(varNewPreviousEvent, LookUp(Sort(Events,ID, Descending), EventClass = varCurrentEventClass && TaskID = varTask.ID ) )
Lookup returns the first record in the specified datasource that matches its equation ie. returns a true value. ID's should be unique so you don't need to filter them at all or sort them descending unless you are over the delegation limit. (You wouldn't find it otherwise). To return a specific field from the found record, say for a label in a gallery, you would use the third argument of the Lookup function. ie Lookup(datasource,ID=someIDvalue,fieldname)
Thanks, I do understand how this works and it works perfectly the SECOND time the button is clicked.
I need to filter by the IDs because it is part of a much larger and more complex operation. The IDs I'm filtering by are not the auto incremented IDs of the target list but rather are IDs written to these previous events when they occurred. The objective is to find the last matching event and write the number of minutes since its creation and the current time. All of this is easy but it is based on finding the correct entry (not just the last one) the FIRST time around. This little block of code (which should work) will be part of a larger series of steps and I won't be around to click the button twice.
Join us next Wednesday for our Demo Extravaganza, October 16, 2019 8am PDT.
Join us for an in-depth look at the new innovations across Dynamics 365 and the Microsoft Power Platform.
Continue your learning in our online communities.
Features releasing from October 2019 through March 2020
Coming to a city near you
Fill out a quick form to claim your user group badge now!
Connect, share, and learn with your peers year-round
Register by September 5 to save $200