Well, the advice from Darren and I regarding a single row table isn’t very useful then if you want to keep a separate table with separate rows for each form submission. It looks like you are using a native form anyway, which isn’t what we tried to describe. What we were describing was a way to have the results from several users in one single row without a user seeing the results from another user.
Your home tab simply has a form button to open the form. The form submits to the calculation table. Your On Submit action on the form opens a new screen to the unfiltered calculation table. I see that you are passing in a calculated title into that new screen, but I’m not really sure I understand where that number is coming from. If it’s coming from the Home table, then how does it get populated in the home tab? (This part I’m really curious about because it may determine other ways to do this with your existing setup.)
So, I will ask again, what is it in your table that identifies that a particular row belongs to a particular user? Do you require users to sign in before using the app? Simply filtering to the last row would mean that every single user is going to see the results from the last row, regardless if it’s from the date they entered or not. I think it would be quite confusing if someone is viewing their results, and then someone else submits a form, which causes the original user’s results to change.
I will reiterate, that this entire app could be done with one single row in one single table. Basically your home tab would have user specific columns for month day and year. You could simply place entry components on the detail screen, or you could have a button that opens the Edit form, so a user can change the values in that single row. The home table would also contain the calculations.
You could have visibility conditions on components on your home tab. If you use entry components on directly on the detail screen, then you could have a submit button which will do nothing more than set a value, such as true, to another user specific column. This true value could be used to hide the the entry components and show the results of the calculation. If instead, you use the Edit form, then once it’s submitted, then you could set up your visibility conditions to look at month, day, and year to determine if the results of the calculation should be shown or not. It would all be one screen, one table, and one row. The user specific columns would allow the experience to be unique for each user regardless if they are signed in or not. That’s the way I would do it because it would be extremely efficient and save a ton on rows.
Now, if you want to stick with your existing method, then you need a reliable way to identify a user. That is the problem you have now. You are writing dates to you LP Calculations table, but you have no reliable way to identify which row belongs to which user.
You could also do a hybrid of of the single row method, but still write the results to a separate table, but the home table would ultimately do all the work and the LP table would just be a log of all of the results.
I hope I’m clear on why you are having problems. Also, I hope I’m clear on the alternative ways to set this up.
