-
Don't make the buttons submit buttons, but use rules - set one to submit to the list, and the other to submit to email. Query fields don't have data in them, data fields do. :)
-
Attach a sample of your form under the options tab & I'll see if I can give you a hand.
-
That's a great solution! I use helper fields like this in repeating tables too. The behavior of buttons depends on their context (as you've found). If the button is sitting inside a section bound to a repeating group, it will affect just "this" instance. If it is outside the repeating group, it affects all instances. :)
-
Howdy - sorry this didn't get answered. Are you still working on this?
-
So - the newly entered row gets set to the same value as the prior row? See attached sample - right click & save target to save locally, right click local file and select Design to open in design mode.
-
These are straight SQL connections? To an Azure DB? Maybe try (in a test form) converting a data connection to UDCX if you are not already doing that.
-
Hey, Stuart - didn't realized you'd posted here as well. Again, I think your best bet is a REST connection to your SharePoint list. Then you can sort by multiple columns.
-
Maybe try setting a rule on hwprice & swprice to set the total?
-
That is strange. I notice when I preview it, if I type in the Hardware cost, it shows in the total (as expected).
-
Try this: substring-after(xdXDocument:GetDOM("Retreive Access Levels")/dfs:myFields/dfs:dataFields/d:SharePointListItem_RW/d:Approvers/pc:Person/pc:AccountId[current() = ../../../d:Title], "\")