Hi @krishnabnv ,
Do you mean that you will get error when you run the flow of SQL Stored Procedure in PowerApps?
I've made a similar test but not met the same error like your description.
My sql successfully was updated.
Here's flow configuration:
My formula in powerapps:
'PowerApp->Insertrow(V2)'.Run("aaaaabbbb") //'PowerApp->Insertrow(V2)' is my flow name "aaaaabbbb" is my paramater
1)whether your license is expired
Only premium license could use sql as data source.
2)whether you create this flow in default environment
Only in default environment, you could use gateway.
3)whether you have permission on this sql table
4)whether you use sql table or view
SQL view is read-only in flow and powerapps.
If the problem still exists, please show me your flow's configurations in details.
If you are very sure your flow has no problem and you think this is server problem, I suggest you open a ticket:
I am also facing the same issue. I am using Exec stored procedure step. It is throwing the same error. When i tried to insert to insert the same values in ssms, i can able to insert. So no issue in access or data.
I am also facing the same issue. I am using ExecuteProcedure_V2.
It is throwing the same error. When I tried to insert the same values in SSMS or using .NET code I can able to insert.
So, No issue in access or data.
But on MS Flow getting same error for parameters which are data type of VARCHAR(MAX) or NVARCHAR(MAX).
I changed data type of SP parameters to VARCHAR(500) OR NVARCHAR(500) and it is working fine now.
MS flow has some limitation on MAX length so mention fixed length for SP parameters as per your needs.
Just had the same issue with my flow.
I'm using PVA, triggering a PA flow which runs SQL SP V2, providing one string parameter (SQL SP expect an nvarchar(max)) and receiving INT output.
I experienced the same error as above.
My original flow received a string from PVA and used it in the SQL SP (with no variables) > didn't work.
Changed my Flow and initialised a variable to capture the string from PVA and then used it in the SQL SP.
Works like a charm.
Give it a go...
Same issue here.
Even using variables to fetch the data isn't working. We even tried to set a fixed string in the parameter and it still fails.
I hope this is fixed soon, because changing VARCHAR(MAX) or NVARCHAR(MAX) to a fixed value is not an acceptable solution.
My workaround for this issue was to use the 'Execute a SQL query (V2)' connector instead. This allowed me to pass a value to a varchar(max) parameter.
Is there a fix for this? I have flows working as expected that were created previously passing JSON data to PA flow, using Execute Stored Procedure V2. Added a new flow to my solution today using exact same pattern that works, and now I get the error mentioned above.
Error details: The API operation 'ExecuteProcedure_V2' requires the property 'parameters/Data' to be a string of maximum length '-1' but is of length '1110'.
My previously created flows still work, but anything new is failing.
Something in the connector broke!
I am having same issue just like you have.
I have flow which is passing JSON data to SQL Procedure, it was same as like i did it before and now i get the error following:
Error details: The API operation 'ExecuteProcedure_V2' requires the property 'parameters/Data' to be a string of maximum length '-1' but is of length '319'.
My previous flow is still working fine, but new flow is showing error.
I opened a ticket with MS and they confirmed there is an issue and they are working on it. Appears this has been going on for quite some time, so apparently stability is not a high priority.
The only workarounds I am aware of know are
a) if you do not think you will exceed a varchar(4000) then switch you parameter type and you are good, if not ...
b) you can chunk the parameter by splitting into multiple varchar(4000) parameters and then rejoining in SQL before using, super ugly, but will work until it's fixed, except if your string length will far exceeds having just a few of these chunked parameters .. and finally ...
c) build a customer connector that will write to your SQL DB correctly and use that instead of the "premium" SQL connector provided by MS, should not be required ...
What's really a shame is that SQL is Microsoft's premier data solution and very pervasive in the market, and some of us simply do not want to use CDS or SharePoint as our data store. Why can't they get this right?
Hope this helps, if I get any more info from support I will relay here. However, the ticket has been opened for almost 3 weeks and they can't seem to agree on a time to connect to discuss. Honestly, the whole experience has me questioning my decision on using Power Apps when stuff like this can just break. It's a huge issue they can't seem to provide any attention to.
Check out the on demand sessions that are available now!
Stay up tp date on the latest blogs and activities in the community News & Announcements.
Features releasing from October 2020 through March 2021