Urgent Help Me out here..! Data pushed to SP is not visible in App

[KarthikPrasanna]

Hi All.

I have created an App, i am able to save data to SharePoint List, and the data is visible in SharePoint List,

Now am not able see this data in powerApp. What could be problem here, i am not able to figure out. This is my first experince like this.

Karthick

[Meneghino]

Hi @KarthikPrasanna

Could you please be a little more specifc?  How are you trying to display the data from SharePoint in PowerApps?  Is it in a gallery? If not, how?

[KarthikPrasanna]

Yes i am using a Browse Gallery to list the data.

[Meneghino]

Then there is no reason why it should not be showing your SharePoint source data.

What is the Items property of your gallery?

[KarthikPrasanna]

This is the item property:

SortByColumns(Search(TBDTimeSheet, TextSearchBox1.Text, "Title"), "Created", If(SortDescending1, Descending, Ascending))

I shared this application with my friend, he was not able load any of the record even, later I found that i was also not able to load any of the record when i am trying to view the applicaiton in web and android app.

Only when I am using this app in PowerAppStudio , I am able to view the record. What kind my mistake, i have done?

[Meneghino]

hi Karthik, two things come to mind:

1) PowerApps can run slowly or not at all on mobile phones if the mobile data service is slow, so I suggest you try the mobiles on wifi connection to see if this is the case

2) I also read about memory requirements of the mobile phones:
https://powerusers.microsoft.com/t5/PowerApps-Forum/New-Lumia-650-cannot-download-PowerApps-Not-enou...

3) Once you eliminate the above two issues, I suggest you substitute the Items property for simply this: TBDTimeSheet

This way you eliminate any of the funny stuff with filtering.

Alternatively just place a text box on the screen and set its Text property to this: CountRows(TBDTimeSheet)

If your data source has less than 500 rows it will show that number and if more then it should show 500, which is what is expected.  If you have a problem connecting to data it will show 0

Please let me know how you get on

[KarthikPrasanna]

I am using a 3gb Ram mobile and WiFi connection of 10MBps.

I got 500 on using CountRows(TBDTimeSheet)  this formula, I checked in SP list , i have 3500+ records in the list.

[Meneghino]

If you got the 500 on the mobile then it means that the mobile is able to see your SharePoint datasource correctly.

There must be another issue.

[KarthikPrasanna]

Is there any limitation with no of records here.?

[Meneghino · Accepted solution]

What do you mean by "no of records"?

You mean "number of records"?

If so, please see below from another post of mine...

That is a very good question, and the official answer is well explained here:
https://powerapps.microsoft.com/en-us/tutorials/delegation-overview/

I suggest you look at the official answer as well, since things will change from what I am about to write.

The following is my current understanding, and if I am wrong at the time of writing (Nov. 2016) someone please correct me.

It is all about delegable data sources and delegable PowerApps functions. Also, the 500 row limit may or may not apply to the number of rows in the data source that are queried (=considered/read) by the PowerApps function, but ALWAYS applies to the number of rows that are returned by that function. The limit on the returned rows makes sense and should not limit most applications, however the limit on the number of queried rows is the real issue for larger datasets.

Here are some cases to explain the above in more detail:

1. If your data source does not support delegation (currently delegation is supported only by CDS, Salesforce and SQL server (incl. Access Web Apps)), then any PowerApps function (i.e. Filter, LookUp, Sum etc.) will query only the first 500 rows of any table (i.e. any rows beyond the 500th will be ignored in the creation of the result)
   
   As an example, if you have a table in a SharePoint list (delegation is not yet supported for SharePoint lists), and it has a total of 1,200 rows with 33 rows where the Title column is "A" of which 22 in the first 500 and 11 in the remaining 700, then Filter(MySPlist, Title = "A") will return 22 rows only.
   Also, SortByColumns ( MySPlist, "Title", Ascending) will only return the first 500 rows sorted by Title, and the remaining 700 will be ignored.
   
   
2. If your data source supports delegation, then all the rows will be queried by any function that supports delegation (currently only Filter, Search, LookUp, Sort, SortByColumns). However, only a maximum of 500 rows will be returned
   
   As an example, if you have an Access Web App table with the same characteristics as in 1 above then Filter(MyAWAtable, Title = "A") will return all the 33 rows.
   However, if you have a table with 120,000 rows with 3,300 rows where the Title column is "A", then irrespective of where in the main table these 3,300 rows are, only the first 500 rows of the 3,300 will be returned by the following: Filter(MyAWAtable, Title = "A"). I have come to believe that this is a workable limit, assuming that with time more functions (i.e. Sum and CountRows) will also support delegation
   
   
3. If your function does not support delegation, then only the first 500 rows of any data source will be queried.
   
   As an example, if you have an Access Web App table with 1,200 rows and a column "Amount" then Sum(MyAWAtable, Amount) will return the sum of Amount only over the first 500 rows of data. However if in the same table you also have a column Title where the rows with "A" as a value are 345, then Sum(Filter(MyAWAtable, Title="A"), Amount) will give the sum over all the 345 rows irrespective of where they are in the table.

The cases I described above are simple on purpose. If you use a combination of functions or complex conditions then I suggest you look at the official documentation where a lot more is explained.

Also, there are workarounds to deal with non-delegable sources of more than 500 rows, for example by caching all the rows in a collection, and I have written about this in other posts.

One final comment about using galleries to display the data returned: initially only the first 100 rows are retrieved, and the following 100 rows (up to a total of 500) are only returned once you scroll down to the bottom of the currently retrieved set. Hence if you show the Sum of a field of all gallery items (Gallery1.AllItems) in a text box, this will change depending on how much scrolling you have done.