cancel
Showing results for 
Search instead for 
Did you mean: 
Reply
ianf1969
Level: Powered On

Cascading lists - Should tables be individual OR can 1 table work with OData connector

Hi,

I have set up an 80 row cascading list, that DOES work perfectly, i.e. with 4 levels.

 

However, whats not working and seem in loop of depair, is the O data write back. I have had it working on one column writing back from the list to a record list.

 

The thing I dont understand or know what its called is related to UpdateItem. When you add code to the Update item, in the code that works, the table and columns name all appear as per "normal" PowerApps. On on the none working, I see no column names and ONLY result or value?

 

I assume the OData connection takes the ID and Value (Lookup column name) and simply looks at the ROW and says "for this ID row, go an "write" the value from the name of the column from cascading list INTO the main SP List etc.....

 

Do I need to set up lots of little tables and break up the big table? 

4 REPLIES 4
Community Support Team
Community Support Team

Re: Cascading lists - Should tables be individual OR can 1 table work with OData connector

Hi @ianf1969 ,

 

Were you using a custom connector to  OData in powerapps? 

Would you please share more details of your app? Like explanation with the related formulas that are relted to your issue? 

 

Regards,

Mona

Community Support Team _ Mona Li
If this post helps, then please consider Accept it as the solution to help the other members find it more quickly.
ianf1969
Level: Powered On

Re: Cascading lists - Should tables be individual OR can 1 table work with OData connector

Hi - am just after an holistic high level overview as it were.....lets take something familiar, like the world....

 

  • 3 columns of Regions (americas/europe/asia), then countries, then cities
  • So in the above, I could either have 1 big table, where obviosuly the regions would be repeated as many times as there were countries etc
  • OR is it "better" practice to have 3 x "smaller" tables, whereby, each table has an "overlapping" duplicate/mapping column to the previous one.

I have spent weeks with mixed success, tyring to get the odata code bit of code to work. It seems very random when it does work. There do not seem to be any really detailed do nots or whys on any explanations and most drop down demos, do not include the "write back" of data to the SharePoint list.

 

I have "roughly" concluded that it seems better to have smaller tables for the lookups, that they themselves ONLY contain single line of text and are themselves do NOT have a choice drop down in them. I think having many small tables though is harder for table maintenance and leads to great chance of error compared to one big table. However, whilst I have been able to get the bit table solution to work from drop down to drop down perfectly, the O data write back to SharePoint does not work.

 

I also notice that sometimes the values of a box seem to differ, so sometimes I see one with max length below the update item. When this appears, this typically means that when you type in the odata connector, you only see value and result and not the drop down table names or the lookup column name.

 

Also, when you first create a form, it tends to default in with combos, that I then delete and add a drop down, then selecting the allowed values. Again, I am assuming this is correct practice. i.e. you then use the 3 way wizard in values to link the dependancies up, whiich makes sense and is a good feature.

 

I really dont see the point of people adding all these tips on drop downs if it does NOT cover the odata write back as thats the main thing that you need it to do, right?!

 

So in short, should one big table be do-able to write back to your row by row list, that holds the value OR is it designed to work as little tables? Please advise, thanks.....

 

 

ianf1969
Level: Powered On

Re: Cascading lists - Should tables be individual OR can 1 table work with OData connector

ExpectedTextValue.JPG

 

This is a working piece of code from one place, which then does not work somewhere else

 

{'@odata.type':"#Microsoft.Azure.Connectors.SharePoint.SPListExpandedReference",
Id:FLDDDepot.Selected.ID,
Value:FLDDDepot.Selected.Depot}

 

I get an error message saying "Expected Text Value"

 

I have no idea why this happens as I seemed to have followed the steps etc - i.e. its working on one so why not the other.....

 

Also, to clarify, should the main table in Sharepoint be a lookup to the sub list (with the cascades), OR should the main SharePoint site simply have a receiving "single text field", whereby the powerapp config sends the value to the text from the lookup to the main site - Both seem to work?

 

 

ianf1969
Level: Powered On

Re: Cascading lists - Should tables be individual OR can 1 table work with OData connector

I dont understand why I can write "result" in the formula below and NOT "ID" or "NameOfLookUp" after the selected? I have both single text OR look up values working in PowerApps, but when published they will not update the list.

 

OdataConnect.JPG

Helpful resources

Announcements
New Ranks and Rank Icons in April

'New Ranks and Rank Icons in April

Read the announcement for more information!

Better Together’ Contest Finalists Announced!

'Better Together’ Contest Finalists Announced!

Congrats to the finalists of our ‘Better Together’-themed T-shirt design contest! Click for the top entries.

Power Platform 2019 release wave 2 plan

Power Platform 2019 release wave 2 plan

Features releasing from October 2019 through March 2020

thirdimage

Community Summit North America

Innovate, Collaborate, Grow - The top training and networking event across the globe for Microsoft Business Applications

Top Solution Authors
Top Kudoed Authors
Users online (3,813)