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.
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 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.
I have a function that is defined as:
Where XXXXX is my schema YYYYY is my package.
PROCEDURE "XXXXX"."YYYYY.SPATIAL::SP_GA_PT_PATH_DISTANCE" (IN PID NVarChar(36))
LANGUAGE SQLScript
SQL SECURITY INVOKER
--DEFAULT SCHEMA <default_schema_name>
AS
BEGIN
I want to call a function and assign the result to a variable, I have tried the following two ways:
intIntersect := XXXXX.YYYYY.SPATIAL::GA_INTERSECT (32.925148, -117.020051,
32.924672, -117.019454,
32.924488, -117.020322,
32.924849, -117.019759);
SELECT XXXXX.YYYYY.SPATIAL::GA_INTERSECT (32.925148, -117.020051,
32.924672, -117.019454,
32.924488, -117.020322,
32.924849, -117.019759) INTO intIntersect FROM DUMMY;
I have played with different permutations of this, but nothing works.
Any ideas?
Thanks.
What you describe as a FUNCTION is really a PROCEDURE in your code example.
These differ in the ways you can call either of them.
Procedures need to be called via the CALL statement.
Functions can either be used as scalar function in all places where you can use expressions (i.e. the projection list of a SELECT-statement) or, for table-typed functions, like a table in the WHERE condition.
The parameters handed over to the procedure seem to be a list of data items.
The general way to pass "lists" of parameters is to use a table-type parameter:
CREATE FUNCTION "XXXXX"."YYYYY.SPATIAL::SP_GA_PT_PATH_DISTANCE"
(IN_PIDS TABLE (PID NVARCHAR(36)) )
RETURNS TABLE (DISTANCES DECIMAL)
AS
BEGIN
SELECT * FROM :IN_PIDS;
...
I am using Qt5 to access a MySQL database. It is easy to execute INSERT queries using QSqlQuery + prepare() + bindValue().
Now I noticed that bindValue() has an optional paramType parameter that can be set to QSql::Out and QSql::InOut.
Is it correct that the QSql::Out and QSql::InOut arguments are useful when CALLing procedures and that they have no use for lets say a SELECT statement? Are there other use cases than CALL?
It turned out that QSql::Out and QSql::InOut are actually intended for use with procedure calls only.
However it also turned out that Qt/MySQL parameter binding does not support the mentioned OUT and INOUT parameters types (see here).
I wanted to create a new table, but I have a syntax error somewhere.
However I do not see where, no matter how often I look over it.
Can anybody spot my error?
Dim cmdCreate As New MySqlCommand("CREATE TABLE inout (inout_seacher TEXT,inout_guid TEXT,inout_blob LONGBLOB,inout_inouttype INTEGER,inout_automaticallyparsed TINYINT(1)," & _
"inout_price DOUBLE,inout_companyguid TEXT,inout_datetime TEXT,inout_title TEXT,inout_catid INTEGER,inout_vat INTEGER,inout_banktype INTEGER," & _
"inout_banktransferprice DOUBLE,inout_expenseinvoiceexistsinguid TEXT,inout_orderguid TEXT,inout_inoutsubtype INTEGER,inout_outinvoicetype INTEGER)", g_CnWebDB)
Thank you for the help!
Bad luck. Believe it or not 'inout' is a reserved word in MySQL. Either wrap it in backticks (`) or (better) call it something else. Also, are you sure you want DOUBLE and not DECIMAL?
"inout" is reserved word. Try other name for the table.
You can also quote the table's name using (), so (inout`) becomes acceptable.
As Strawberry already said, is a reserved word used for procedures; directly from MySQL.com:
As of MySQL 5.0.30, stored procedures that take no arguments can be
invoked without parentheses. That is, CALL p() and CALL p are
equivalent.
CALL can pass back values to its caller using parameters that are
declared as OUT or INOUT parameters. When the procedure returns, a
client program can also obtain the number of rows affected for the
final statement executed within the routine: At the SQL level, call
the ROW_COUNT() function; from the C API, call the
mysql_affected_rows() function.