I'm curious of what the community thinks is the best approach for the following scenario:
Should changes be made to SQL table to allow null values or should all of the fields be inserted into powerapp screen, and set 285 fields visible property to false?
Solved! Go to Solution.
Unless the SQL is on-premises, where stored procedures won't work with PowerApps, I would load just the fields you need to change into PowerApps and then use Flow to call a stored procedure with the 20 or so fields that need to be edited when writing back to SQL. The stored procedure can pick up the values for the rest of the fields from SQL and leave them on the server.
But I tend to agree with @mdevaney , 300 required fields is too many. Required fields should be driven by the business requirements, not because you want to guide the user's behavior.
@mdevaney I share your concern. The architecture of the database is the result of our software provider. I'm a bit hesitant to begin altering the underlying table. If that's what needs to be done so be it.
Unless the SQL is on-premises, where stored procedures won't work with PowerApps, I would load just the fields you need to change into PowerApps and then use Flow to call a stored procedure with the 20 or so fields that need to be edited when writing back to SQL. The stored procedure can pick up the values for the rest of the fields from SQL and leave them on the server.
But I tend to agree with @mdevaney , 300 required fields is too many. Required fields should be driven by the business requirements, not because you want to guide the user's behavior.
@Pstork1 That's a great idea (SQL is on-prem). I hadn't thought to use a stored procedure to handle the heavy lifting. I appreciate your responses I'm going to mark this issue as solved.
Unfortunately, the last time I looked there were limitations on the use of stored procedures with On-premises SQL. So that may not be a solution.
If you use SQL Profiler you will notice it does a few queries to make sure required fields are defined on page. I doesn't seem to cache the result so it performs test on every INSERT/UPDATE. I do make bit fields required. I want it to be either 1 or 0. I have several programs accessing table. I want to avoid nulls.
User | Count |
---|---|
202 | |
92 | |
83 | |
47 | |
42 |
User | Count |
---|---|
252 | |
105 | |
103 | |
62 | |
57 |