I have to call a stored procedure in lookup activity of Azure Data Factory for mysql that takes azure pipeline variable as input but i dont know the exact syntax.
Like call stored_prpcedure("#variables('BAtchID')")
The variable is of string type
If anyone knows how exactly i can call it?
Please do share.
You cannot directly use call stored_prpcedure("#variables('BAtchID')") in your query section of Look up activity.
The query field expects a string value, when you use call stored_prpcedure("#variables('BAtchID')") directly, it will be parsed as is but not as a pipeline variable.
Instead, you need to concatenate the query with pipeline variable using #concat() function in data factory.
The following is a demonstration of how I used query field to execute stored procedure using dynamic content.
You can use the dynamic content below to successfully achieve your requirement (replace stored procedure name and variable name)
#concat('call demo("',variables('value_to_pass'),'")')
The above content will be parsed as call demo("Welcome") which is shown below (\ indicates escape character):
Note: The debug run in the above image failed because I don't have a stored procedure in mysql database.
Related
UPDATE 11.15.2022
I have conducted extensive testing and found the pattern of problem here. Once again, what's strange is this ONLY happens if you pass a function as a parameter to the originating Stored Procedure; passing a hardcoded value or variable works just fine.
The issue is when the Stored Procedure calls another Stored Procedure that checks ##read_only to see if it can WRITE to the database. I confirmed removing any code that writes data fixes the issue -- so ultimately it appears passing a STATIC value to the SP causes the procedure execution to bypass any writing (as expected) because of the IF ##read_only = FALSE THEN ...write...
It seems passing a function somehow causes MySQL to compile a "tree" of calls and subcalls to see if they CAN write rather than if they DO write.
It appears the only way to work around this is to pass the parameters as variables rather than function calls. We can do this, but it will require substantial refactoring.
I just wonder why MySQL is doing this - why passing a function is causing the system to look ahead and see IF it COULD write rather than if it does.
We have a Read Replica that's up and running just fine. We can execute reads against it without a problem.
We can do this:
CALL get_table_data(1, 1, "SELECT * from PERSON where ID=1;", #out_result, #out_result_value);
And it executes fine. Note it's READS SQL DATA tagged. It does not write anything out.
We can also do this:
SELECT get_value("OBJECT_BASE", "NAME");
Which is SELECT function that is READ ONLY.
However, if we try to execute this:
CALL get_table_data(1, get_value("OBJECT_BASE", "NAME"), "SELECT * from PERSON where ID=1;", #out_result, #out_result_value);
We get the error:
Error: ER_OPTION_PREVENTS_STATEMENT: The MySQL server is running with the --read-only option so it cannot execute this statement
We're baffled at what could cause this. Both the SP and function are read-only and execute individually just fine, but the second we embed the function result in the call of the SP, the system chokes.
Any ideas?
So AWS cannot figure this out. The issue only happens when a function is passed as a parameter to a stored procedure that calls another stored procedure (not even passing the value of the function) that has a ##read_only check before doing an INSERT or UPDATE. So for some reason, the system is doing a pre-scan check when a function is passed vs. a variable or hardcoded value.
The workaround is to pass the function value as a variable.
I'm going to report this issue to Oracle as it might be some sort of bug, especially given the function is DETERMINISTIC.
I need to execute sql task based on parameter.
Lets say if my #parameter = 1 then execute this sql if #parameter = 2 then execute this sql. I think of a work around but is there anything straight forward such as Len(?) or Len(#parameter1) ..
Bottom line: I need to execute sql query based on what's passed to parameter.
Let me know if that's possible.
If you want an Execute SQL Task to run a different stored procedure based on a variable, then there are a few options:
You could create a stored procedure that takes a parameter. The stored procedure would use IF ELSE code to execute the code as described in a comment by Lamak. This is a less than ideal solution if you want to execute different stored procedures. This could work if you only have a very small number of queries or stored procedures to execute.
You could write a variable that calculates the name of the stored procedure based on an expression. This could work well if you only have a few stored procedures to execute, but it does not scale for a large number of stored procedures. It also is hard to understand from a coding perspective, particularly if the expressions are complex.
You could write a query or stored procedure that generates a separate stored procedure call command. You could run an Execute SQL Task the loads a result set. The result set would map to a variable of Object data type. You could then iterate through the variable in a For Each Container to assign values to variables. Easier to manage than 100 expressions if you have a lot of code to vary.
Based on your comment to me it sounds like you want to try option 2. The following are detailed steps for option 2:
In the Variables window at the package-level scope create a variable called SqlCommand of data type String.
Set the EvaluateAsExpression property for the SqlCommand variable to True.
Click on the expression builder link.
The following is a sample IF THEN ELSE expression using the Conditional operator.
1 == 0 ? "SELECT SomeField = GETDATE();" : "SELECT SomeField = GETDATE() - 2;"
If 1 equals 0, then the first command will be returned. If 1 does not equal 0, then the second command will be returned. In this case, since 1 does not equal 0, the second command is returned. You can change the 1 == 0 section to be the condition you actually want to evaluate.
Add an Execute SQL Task to the control flow.
Open the Execute SQL Task Editor.
Set Connection to your desired database connection manager.
Set SQLSourceType = Variable.
Set SourceVariable to User::SqlCommand.
Close the editor and test the package.
user1810575 has asked this question again in ssis-execute-sql-task-based-on-parameter, see my answer (which is copied here as well).
You cannot use Execute SQL Task to run Transact-SQL statements.
For setting conditional SQL Statement based on what you are trying to achieve.
In Execute SQL Task editor
In general tab, leave the SQLStatement blank.
In parameter mapping tab, add parameter and map User::Parameter variable to Parameter Name 0.
In Expression tab, set the SQLStatementSource to
(DT_NUMERIC, 18, 0) #[User::Parameter]==1 ? ...query 1... : ...query
2...
I'm trying to call a stored procedure that takes one parameter on Mysql from ssrs. Connecting through ODBC. I use following syntax for calling using query designer:
`CALL test.ClientSelectExtract(?)`
And I'm getting following error.
`SQLBindParameter not used for all parameters`
I found the solution. Read from an article that MySql ODBC don't support named parameters.
So I called the stored proc like this
CALL test.ClientSelectExtract(?)
Added a parameter named parameter1 in the Parameters Folders then set the type and value, then explicitly created a parameter named parameter1 to reference the ? on the dataset also, then all worked fine.
Note: If I had more ? placeholders the next param would be parameter2, same steps and so on.
You should create linked server in SSMS from MYSQL then only we will call the stored procedure. syntax to call stored procedure:
EXEC ('CALL GASP_sales_aps(?, ?)', #dt_start, #dt_end)AT MySQL(Linked Server Name)
GASP_sales_aps ---->procedure Name
(#dt_start,#dt_end)------> are parameters .
I have recently joined a team where they are using JSON serialization to pass parameter arrays to SQL Server stored procedures where they are then deserialized and the required values extracted i.e. Each stored procedure has a '#Parameters' parameter of type VARCHAR(MAX). The framework creating and executing the command is written in C# and uses standard .NET types (SqlCommand, SQlParameter) etc.
It appears that when the serialized content is greater in length than a threshold that the stored procedure is not being properly executed but no exceptions are raised. Nothing appears to happen. Running SQL Profiler I have observed that there is no attempt to execute the stored procedure in SQL Server.
For example:
In one case there are just 30 instances of a type with no more than eight properties being serialized. The serialization succeeds and the value is assigned to the sql parameter in the parameters collection of a SqlCommand (there is only one parameter). The command is executed but nothing happens. If there are fewer occurrences of a type then it succeeds. When it does not succeed an exception is not being raised.
Using:
SQL Server 2008
C# .NET 4.0
JSON Serialization provided by Newtonsoft.
The SqlParameter in code is created as a varchar max.
Client Server architecture - there are no intermediary services.
Does anyone know of a limit for JSON serialized values being passed as a sql parameter with a SqlCommand or have any ideas as to what might be causing this behaviour?
I've figured out what was happening in my case. It had nothing to do with the serialziation of the value in a sql parameter as I found that if I waited long enough (5 -7 minutes in my case) that the procedure eventually executed.
In the stored procedure there is a cursor being used to extract the records of interest (this is a batch update procedure). This cursor was calling the CLR function to deserialize the Json for each value it required. By inserting the desirialized data into a temp table for use in the cursor the 'issue' was resolved.
Inside my stored function I have :
formula := "(10+10 * 1000)/12";
(a simple math formula, with numbers only, dynamically created as a string)
How do I eval this, and return the result ?
I can't use EXECUTE (not possible inside a stored function) and if I make it a stored procedure and call it from a stored function, I get "Dynamic SQL is not allowed in stored function or trigger" -as if I would have the eval directly inside the function.
I need a stored function, and not a procedure, because I need to call it inside a SELECT statement.
I don't see what using the formula is buying you. If you're writing a stored procedure, type in the formula and forget the string.
I don't think it's in your interest to make the stored proc that dynamic where the formula being evaluated has to be changing from call to call.
If you must, you'll have to write a parser to break that string up into its constitutive parts, create a parse tree, and then walk the tree to evaluate it. It's not a trivial problem. I'd rethink this.
Apparently there is no solution to this.
I have applied a "paintfull" workaround in PHP, which I will not display here as it is not the subject of the question.