I wanted to report a glitch that I observed recently. Trying to explain it from scratch is a bit confusing so I'll list the steps I took:
So far everything is working correctly. But here's the twist: I decide... I want the user to be able to select more than one emotion (e.g. people can now be "Happy" and "Meh" at the same time).
At this point, I try to resolve the issue. I try 4 things:
While I've managed to resolve the issue in a roundabout way using step #4, I couldn't help but think... what if I had hundreds of records at the time I decided to go from single- to multiple-select? I would have to go in and fat-finger all the records back in after deleting the column.
Is there an easier way to get around this?
Hi @tommyly,
Please be aware that in Sharepoint, complex field types like Choice, Lookup and Person columns violate one of the fundamental relational database principles, that of each cell in a table containing a single piece of data, also known as 1NF or 1st Normal form. IMHO, this is the reason why Powerapps developers have so much trouble trying to work around what I consider a flawed table. It is better to use a separate list and to have a Foreign key in that table that is the Primary key of the second table. Trying to represent what is a one-to -many relationship in a single table will inevitably lead to the problems that you have encountered. Please review the following reference for a good idea of database design principles. It will explain a lot of the problems we encounter in these forums.
https://support.office.com/en-us/article/database-design-basics-eb2159cf-1e30-401a-8084-bd4f9c9ca1f5
Yes, I'm aware of database normalization. Lacking Azure SQL license, I started building many of my apps based off of SharePoint lists. I'm sure many other people are in a similar situation. SharePoint, unfortunately, is very limited when it comes to structuring and querying data. For example, if I started creating many-to-many junction tables for every multiple-value field (to be normalized), trying to create a report would require filtering off of 4, 5, or even a dozen primary and junction tables. And then have to deal with managing delegation threshold not only in my primary tables, but also in my junction tables. SharePoint just isn't built to query data like a real database. Fortunately, PowerApps has a pretty dynamic and efficient way of delimiting and splitting multiple values in a text field.
So while I agree with you that data should ideally be normalized, it's just not feasible with SharePoint. That said, I would never build a large database in SharePoint. Many SharePoint-based apps are simply to track and manage data for small projects and tasks anyhow. Anything larger than that should require an application project, developer team, a real database (and hopefully proper, normalized database design).
And the problems that I'm encountering have nothing to do with data normalization. It has to do with PowerApps's inability to update its meta information about the SharePoint Online datatype. For example:
If you load a dataSource with field-column 'x' as an integer and then later change it to text (has nothing to do with data normalization), PowerApps does not receive that bit of instruction. You can refresh it a dozen times in several different ways (e.g. refresh data source, refresh form, restart program, restart PowerApps, restart browser, restart your computer, etc.) and it won't know a change has occurred. And since it doesn't know that the column has changed, it won't let you put text into the field (because text violates the number format). If you give it a number, PowerApps will allow it, but SharePoint will throw an error, and then PowerApps, at the behest of SharePoint, throws you that error. So you now have an error if you do, error if you don't.
@Drrickryp wrote:If you design your tables properly according to sound database principles you won’t have these issues.
I agree with you... that sound database principles is best practice and functionally sound. The problem is not about sound principles. The problem and the original post is about a very specific functional issue.
Once you do #5, which has absolutely nothing to do with data normalization, PowerApps and SharePoint become like two, old, bickering spouses.
PowerApps: "You said it was a SHORT TEXT!"
SharePoint: "It's a LONG TEXT!!!"
PowerApps: "QUIT CHANGING YOUR MIND!!!"
SharePoint: "I'll change your face!"
It would hypothetically take me one good afternoon to normalize my data. But that won't fix problem #5. Problem #5 is not a data architecture problem. It's a SharePoint-PowerApps relationship problem.
This training provides practical hands-on experience in creating Power Apps solutions in a full-day of instructor-led App creation workshop.
Come together to explore latest innovations in code and application development—and gain insights from experts from around the world.
User | Count |
---|---|
205 | |
70 | |
51 | |
49 | |
20 |
User | Count |
---|---|
262 | |
120 | |
85 | |
80 | |
68 |