Share
Report
12hi folks
I can understand the mentality of "throw everything out the door when you approach this new low-code environment...", but your architects for Power Automate: Execute stored procedure (V2) have "missed the boat".
All commercial grade databases (SQL Server, Oracle, DB2, etc.) have the ability to use BOTH input and output parameters on stored procedure calls. This is kind of important, because in order to use the Power Platform as a transactional UI, there are no such mechanisms like Entity Framework, Hibernate, etc. available in the Power Platform (where a skilled developer can write this kind of logic into the model), so you have to fall back to an era that's been around for many decades now, where you use the native rowversionid mechanisms which are inherent in all commercial databases.
If you think about how commercial databases are designed, and how rowversionid is used to manage concurrency (and folks not overlaying each others database row(s)), the majority of the stored procedures become objects which do not return records, they simply return the updated (output) parameters and typically a return code (like successful update, duplicate update attempted, row in database newer than what you are trying to update in Power "X", record not found - key was probably updated, etc.).
So in order to keep things consistent (and working with other .Net, etc. technologies), it's important (recommend as an enhancement) to:
- know how to return the resulting (output) parameters of a stored procedure call without having to return any rows from the database (since the stored procedure already knows the logic to take care of the various database scenarios mentioned and the resulting parameter values)
- to keep it in sync with the rest of the MS technologies which already have this logic encapsulated into the design
All responses (
Answers (
