Unanswered

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

(0) Share

Report

Posted on by Community Power Pla...

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?

Categories:

Building Power Apps

I have the same question (0)

All responses (4)

Answers (0)

v-monli-msft on at

Like (0)

Report

Hi @Anonymous ,

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

Was this reply helpful? Yes No
Community Power Pla... on at

Like (0)

Report
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.....

Was this reply helpful? Yes No
Community Power Pla... on at

Like (0)

Report

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?

Was this reply helpful? Yes No
Community Power Pla... on at

Like (0)

Report

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.

Was this reply helpful? Yes No