Did SharePoint Data collection change?

[stephenJames]

Hello,

         I was wondering if the SharePoint data collection has changed recently. I have applications that pull from SharePoint list and library column like, Created By, Modified By etc. However while building out a new version of one of my applications, i noticed that the collect function no longer shows that i can pull from Modified By. Instead the only option is just Modified, which will pull the modified date. I checked the SharePoint list and can still see the column Modified by , but PowerApps wont let me pull from it.

I use the modified by to allow the display of personal list and library items to users based on if they were the last ones to modify them. 

If this functionality has been removed almost all of my applications cannot be updated as they would break without an easy fix.

[RandyHayes]

@stephenJames 

No changes that I've seen.  I still am seeing 'Modified By' just fine.

[stephenJames]

hi @RandyHayes so after a little more testing i have found that from a brand new canvas app if i add a gallery and set the data source to a SharePoint library. I can access the created by and modified by fields 

If i set the app on start to and run AppOnStart

ClearCollect(test, sharepoint)

 then change the gallery items to use the new test collection. 

I only get access to Created and Modified not the "by" versions of each.

So at least for me ClearCollect or Collect is not pulling all the columns and i can see that in the the collection view.

[RandyHayes]

@stephenJames 

So this is just an issue with the Field editor.  I would have never noticed it as we rarely use collections for these things and almost never use anything but a blank gallery.

What you are looking for is Author ('Created By') and Editor ('Modified By').  

If you choose one of those in the Field Editor, it will insert a 'Created By' or 'Modified By'

[stephenJames]

@RandyHayes Yeah i did notice that too. Its weird cause when looking back at previous applications i can see that i used the 'Modified By' and it still works on that application.

But on new applications it displays an error. 

I will have to go through all my applications and make some new versions replacing the 'Modified By' and 'Created By' to the new Editor and Author tags.

[RandyHayes]

@stephenJames 

I am not seeing the issues.  

But then it begs the question...why a collection is needed?   Are you setting the collection some other place?

[stephenJames · Accepted solution]

@RandyHayes 

This must just be an isolated issue with my environment, maybe because i am on GCC instead of consumer...possibly. 

Changing from "Modified By" to "Editor.Email" for example has resolved my issue. 

The main reason we use collections in almost all our applications is for pulling data from SharePoint. From learning PowerApps from videos on YouTube , i was always under the impression that if you are pulling large data sets from SharePoint that it is better and more efficient to do collections. 

For one example application, we use the application as a user interface to quickly and easily find documents in a SharePoint Document library. The document library holds at last count 1600+ documents, and it does continue to grow as new documents are added. 

The User Interface App allows us to grab all those documents and apply filtering, sorting and display restrictions for the user from a collection. This way there is no delegation warnings that i have periodically seen. This also means in my understanding only one connection to SharePoint to pull the data, instead of multiple calls to SharePoint to, get, filter, sort etc.

[RandyHayes]

@stephenJames 

Yes, it is possible the environment version is different on GCC.  I would almost assume that based on what you are seeing vs what I'm seeing.

As for the collections - It's quite misleading...almost everyone has been conditioned to use collections for everything from a single value to millions of records.  They are overused and have an overhead to them.

They have their use and purpose, but when they are not needed, they should be avoided.

In your case, you are using a collection to try and grab all the data into your app.  Here is where things are misleading, you only hit the REAL datasource once in your app.  That is when it loads the app (or, depending on the advanced options - when called for).  What does that do?  It actually collects information into a session table in the cloud service.  Once you call for a bit of data, the cloud session either has it already in the session table and returns it, or goes and grabs it.  THEN, and here is the part to consider, when you use that bit of data again, it is already in your app as you called for it before.  It doesn't go back to the datasource to get it and in many cases (depending on your advanced settings) it doesn't even go to the cloud session table...doesn't need to, you already have it.

So...if you have, let's say, 1000 records in your datasource, and you LookUp record 500, you will get that back.  If you LookUp record 500 again, you will get that again, without the trip to the session table.  If you LookUp record 100, again the process is the same.  If you Collect all the records and then try to push that into another collection (which is a common practice for gathering large sources) causes the session table to have to be accessed for all 1000 records.  This is in many cases a lot of time.

Again now, going at your case, you are dealing with a Document Library.  There are a lot of delegation traps in Doc Libraries because there are a lot of "generated" columns.  

My recommendation is to resolve delegation issues at the onset of the app to make sure your datasource is going to have the ability to delegate.  This is easily achieved.  And, once you have it, you don't need to worry over the large amounts of data for filtering non delegable criteria.   Because, if the criteria is delegable, then the session manager will be able to pass an odata query and return a session table for that.

Now...(sorry to rattle on a bit), if you HAVE to have over 2000 records in your app for a display purpose (which I would say one should reevaluate the need for that) then a collection is the only option.

Collections are only needed in cases where you need to store and manipulate over the record limit of the app records, or where you need the ability to add or remove rows in an "internal table".

So, bottom line, resolve the delegation issues and make sure your app never NEEDS over 2000 records at a time and things will not only perform better, but also reduce the chance of overrunning the app memory.

What does all of this have to do with your original issue? Nothing, but I guess I opened that can of worms...and it was fun to write.

I hope it is helpful in your designs.