PATCH Advice

[AustinC]

Hello!

I am trying to seek advice regarding a way to filter by table headings, rather than specific items within rows. I've been working on an attendance application for awhile, and I see some cool one's on YouTube that I'm curious as to how they created.

Some points/information:

1. I'm using OneDrive for Business as the data source.

2. Keiki = Children, Makua = Parent, Kumu = Teacher. These are Hawaiian words.

3. I have a Datepicker and also a text box that reflects it's selection via text.

4. The way I've written up the logic is incredibly tedious and I'm thinking there's a much easier way to do this.

Here's what I have: (note the dates are old as I've focused my time on other applications within the past few months. This will be changed to recent dates soon.) I'm sure the filter doesn't need a million things either, I definitely could probably reduce this to filtering 1-2 things?

I've also had to add a column for every single date that we need to track attendance for. Is there an easier way to do this?

If(Label1.Text = "1/22/2018",

Patch(Table2, First(Filter(Table2,

ProgramName = DataCardValue5.Text && KumuName = DataCardValue3.Text && NHEPCenter = DataCardValue4.Text && DayOfWeek= DataCardValue6.Text && MakuaLastName = DataCardValue8.Text && MakuaFirstName = DataCardValue7.Text)), {January_22: Dropdown3.Selected.Value, January_22_Curriculum: Dropdown4.Selected.Value}));

I would then have to write all that is above over every single time to reflect the next date.

Thanks for your help, the way I've written it up WORKS, however, it's super tedious and repetitive.

[timl]

Hi @AustinC

>> I've also had to add a column for every single date that we need to track attendance for.

If possible, I would encourage you NOT to add a column for every single date that you need to track attendance for. It's far better to store the dates as rows in a table. It isn't really possible to filter by table headings. The answer here by @CarlosFigueira highlights the complexity of the formulas we would need to use when the data values are in columns

https://powerusers.microsoft.com/t5/General-Discussion/Dynamic-Collect-column-name/m-p/60753/highlig...

I would recommend that you normalize your data structure to 'third normal form' - you'll find plenty of articles on the web that can do a better job of explaining this than I can. This article on 'first normal form' highlights the problems of a customer table that contains the columns 'Telephone number 1' and 'Telephone number 2', and also describes how you can fix this. Conceptually, this is the same as your 'Table2' with the columns 'January_22' and 'January_22_Curriculum'.

https://en.wikipedia.org/wiki/First_normal_form

If you post more details about your data structure (eg - what are you storing in the Jan_22 column, what data does Dropdown3 contain) , I'm sure someone here can offer more advice.

[SmartMeter]

Hi AustinC, What Timl says is spot on, however 3nf is a rather complex thing for a newbie to digest unless he is on a tropical island paradise surrounded by beaches sun and endless time. Let me jump to a closer answer from snowy Michigan because I envy your paradise and will join you in spirit here! Anything that repeats with frequency is a row, anything that is an "entity" (think major noun words) is a column. You make tables of these, then connect them with Junction records. Regardless of SQL or SharePoint or whatever backend (storage means) you are using, you want to do two things here. First, design your tables on a white board with all the stakeholders in session. You will need a "code definition table" to contain the unique list of students (student body table) at any point in time (semester, year, etc.) Make this have a date, the grade they are in, and all the master student info you will need. Make a simple dimple app to add/mod/delete students from this list. Sit back, crack a coconut, and enjoy your progress thus far. Once you have the basic student info. (Think Phone book of the student body as a list.) You will also need one of these "code" tables for teachers and then a third one for your classes. Boom, you now have your first three tables, and a little app to add/mod/delete all the data inside them. Next, you make join tables connecting these unique lists to add your "attendance" functionality. One essential join record will be the Teachers to all the classes and it will need a third and fourth field (Class start and end dates) Simple, done with table number four. Next, add a table for students connected to these class records (hint, table four was named "Classes") This table FIVE is your "Master list of students attending each and all of the classes in the semester." Table six is "the big island" you seek. It is the ATTENDANCE table. This is a junction record (connector) that joins your class table of students in classes, to a brand new piece of data - a simple check mark that the teacher strikes to say "in attendance or not". This should be a gallery based on the Fifth table (list of students in any particular class) and it is simply a list of those students by class name, and the daily check mark arbitrated by the teacher. So there you go, a free database schema, but you will need to flesh out the fields (entities, or nouns) that each of these six tables should properly contain, and the relationships (joined common data fields) that your school will need to use. Long story short (from a guy who was a DBA for a while!) You will need exactly six tables, and six teeny tiny apps to pull this design off optimally. As for a report, you can do this with PowerBI, or a simple-dimple report can be done with the power-apps charting components. Next time I'm in Hawaii (in my dreams) save me a beach, and if you ever make it to Michigan, I'll save you some snow! (PS, I would use SQL server for the backend if I were you, it does relationships very easily, and SharePoint is rather constrained to the depth of relational design that can be executed therein- aka Lookups are not at a par with primary and foreign keys in SQL.) Peace, SmartMeter.

[SmartMeter]

OOPS, I forgot something. "All I can say is Your Welcome!" SmartMeter 😉

[AustinC]

Thanks for all of your feedback and hilarious commentary. I'm not sure if First Normal Form would be the answer to tracking attendance, as every attendance entry would contain a new row with student attendance? Unless I am misunderstanding that. I do see how it would simplify the problem in it's entirety, because I could just have a PATCH function with the insertion of data into a Date Attended column... That would solve my problem, however, would create a new one by there being many entries.

@SmartMeter, I have some experience working with Heidi SQL, but mainly as a hobby. I have never tried to run strictly My SQL, though, so not sure how different it is.

I also never thought about multiple tables, as I thought Powerapps didn't support it. It seems like using SQL with multiple tables could definitely be the most beneficial in the long run: 

https://powerusers.microsoft.com/t5/General-Discussion/Syntax-for-joining-tables/td-p/61387 shows a way to join it. I just need to try and put it into practice.

Thanks for all of your help!

[AustinC]

I forgot to add. In the column curriculum, a teacher requested an option to select which week of curriculum they taught that day. They have 20-40 weeks of curriculum, and I couldn't think of a better way to track it.

Maybe you are right with First Normal Form... Maybe I should PATCH a new row with a simple date and curriculum column, rather than manually entering in every date for the rest of the year and future years.

[SmartMeter · Accepted solution]

@AustinC, You are well on your way to the solution just by thinking through this design! Yes, the multiplication of rows should be the attendance records, and you can patch these into existence every day, (or be smart, and simply implement exception reporting where the teacher ONLY calls out and actually stores a row for the lower population of data) This should be those students absent, unless you are like the Detroit schools and those in attendance are the lesser of the two populations! (Sarcasm aside), we don't want to make columns out of dates, this is really REALLY bad design mojo, and we will not be employed for long designing things like that. Think of it this way, the student body is a table, and it can live independent of all the other data info. Teacher is the same way, and so is the list of classes. This could be one single table, or SharePoint list object, or any type of backend storage scheme. The "Joins" are where you have a powerapp dropdown list to pick from, which is storing your brand spanking new "Attendance" table, which presents the class in a dropdown for the teacher to pick, then it presents the student list for them to pick the absentee from another dropdown, then, it lets them specify with an affirmative "Yes/NO" or checkbox selection, that this student is not present today (which is your date, and please use current date so they don't have to type one in. Be nice to teachers!) These few fields (the Teacher/Class/Students/Date/Attendance switch) are now your record for your penultimate table. This way, the PowerApps dropdowns get their data from data sources (The code tables, or stacks of students and teachers, etc) and your "Attendance" designation is the marriage of these fields in the logical order representing the attendance structure that fits your "business requirements." You know, the current day, the teacher, the class, the semester, the week, the student, and BANG, suddenly you have 2 or 5 entries in a class of 22 students who were not there on day 4/17/2018. You can join it all in the database for reporting, but the app is generally adding/modifying/deleting data from ONE TABLE at a time with one "page" of the app, or a gallery and detail page for each of these tables that are managed as independent code lists, leading up to your joined ATTENDANCE row. To cut to the chase, your teacher taps in her name (or her Azure AD login name is auto populated in the first field to be slick) then she picks the class she is teaching from a dropdown and selects the missing kids from another dropdown, then she checks the mark and saves the single ATTENDANCE table record exception for Moana since she is surfing today(or Bethany Hamilton perhaps?) With all the richness that the other dropdowns have collected from the other tables in the schema. Another way to put this, is that the dropdown selection fields have data sources that are "Item collections" from your code tables, and you ultimately store the ATTENDANCE with the goodies from the code tables. Do something for your own education on this item, look up how the items collections work on choice fields in PowerApps and you will be closer to the answer you seek. So, Yes, each ROW is a dated object, with a child name, and class name. This removes redundant data storage of teacher and class from your detailed records, and provides a unique class list of students per class per teacher. I Hope this makes sense, and I wish I could be there (boy do I) to help with this app, but I am stuck in Michigan today. PS (between us coconuts, it's THIRD normal form, not first! Bill Inmon is blushing at you!) Peace, and sunscreen my tropical friend! SmartMeter.