Debugging BigQuery Stored procedure - sql

Is there any way I can use print statements within BigQuery stored procedure? I have a stored procedure like below, I like to see how SQL statement is generated to debug the issue or any other better way to debug what stored procedure is producing etc.
CREATE OR REPLACE PROCEDURE `myproject.TEST.check_duplicated_prc`(project_name STRING, data_set_name STRING, table_name STRING, date_id DATE)
BEGIN
DECLARE sql STRING;
set sql ='Select date,col1,col2,col3,count(1) from `'||project_name||'.'||data_set_name||'.'||table_name|| '` where date='||date_id ||' GROUP BY date,col1,col2,col3 HAVING COUNT(*)>1';
--EXECUTE IMMEDIATE (sql);
print(sql)
END;

There are number of approaches for debugging / troubleshooting stored proc
One of the simplest - to see how SQL statement is generated - slightly adjust your stored proc as in below example
CREATE OR REPLACE PROCEDURE `myproject.TEST.check_duplicated_prc`(project_name STRING, data_set_name STRING, table_name STRING, date_id DATE, OUT sql STRING)
BEGIN
-- DECLARE sql STRING;
set sql ='Select date,col1,col2,col3,count(1) from `'||project_name||'.'||data_set_name||'.'||table_name|| '` where date='||date_id ||' GROUP BY date,col1,col2,col3 HAVING COUNT(*)>1';
--EXECUTE IMMEDIATE (sql);
END;
Then, you can run below to see generated SQL
DECLARE sql STRING;
CALL `myproject.TEST.check_duplicated_prc`('project_name', 'data_set_name', 'table_name', '2020-11-24', sql);
SELECT sql;
with output
As you can see here - you are missing apostrophes here where date=2020-11-24 so you can fix your stored proc

Related

Create a query as a procedure in BigQuery

I am basically trying to do this MySQL script in BigQuery:
CREATE PROCEDURE `test` (IN tab_name CHAR(40) )
BEGIN
SET #query =
CONCAT(
'SELECT *
FROM ', tab_name );
PREPARE stmt FROM #query;
EXECUTE stmt;
DEALLOCATE PREPARE stmt;
END
In theory, this should let me run this script:
CALL test(`my_dataset.my_table`)
and it will perform my "SELECT * FROM" script on that table.
So far, this isn't working for me because BQ doesn't want to accept the quotation marks breaking across lines, so it says there is an "Unclosed string literal".
Any idea how I can accomplish this in BQ?
Here is my attempt:
CREATE OR REPLACE PROCEDURE `mydataset.test`(tableName STRING)
BEGIN
DECLARE queryString STRING;
SET queryString = " SELECT * FROM mydataset."||tableName||"";
EXECUTE IMMEDIATE queryString;
-- SELECT queryString;
END;
Execute the procedure:
CALL `mydataset.test`('mytable');

Cannot pass parameter inside stored procedure in redshift

I have written the procedure which calls the parameter in the select query, but it's not working. When I print that parameter it's working fine, but with the select query, it's not working.
I have used Aginity workbench for redshift to execute the stored procedure.
CREATE or replace PROCEDURE get_tbl_name(IN tablename varchar, IN columnname VARCHAR, IN mindate varchar) AS $$
Declare
evalmindate varchar;
BEGIN
Raise info 'tablename = %, columnname = %, mindate = %', tablename,columnname,mindate;
if mindate is null then
select min(columnname) into evalmindate from tablename;
else
evalmindate=mindate;
end if;
END;
$$ LANGUAGE plpgsql;
Calling Proc:
call get_tbl_name('test_bq', 'date',NULL);
Output:
tablename = test_bq, columnname = date, mindate = <NULL>
Error Message
42601: syntax error at or near "$2"
From the output, we can able to see the parameter inside the procedure when I print, but I can't pass the parameter to the select query, it throwing an error. Kindly help me with this.
You can't use the variable as a column or table name directly in a stored procedure query. Instead you need to compose a query string and execute that.
Also the INTO var syntax needs to come first in a plain query and last in an EXECUTE.
You have:
select min(columnname) into evalmindate from tablename;
Try this:
EXECUTE 'select min('|| columnname ||') from '|| tablename ||';' INTO evalmindate;

Teradata stored procedure with dynamic parameters called from R script

I need to extract some data from Teradata to process in R. I have around 84 Dep/sec keys with most of them having a different time span so my thought was to create a stored procedure in Teradata that will accept the Dep, Sec and Dates as parameters. I could then loop over the list in R calling the SP each time to create my data set.
The SP I have created to test this idea is a very simple one but I can't get it to work.
CREATE PROCEDURE procTest4 (IntN integer)
BEGIN
CALL DBC.SysExecSQL('SELECT top' || IntN || '*
from TableName');
END;
Teradata does create the SP but I don't know how to execute it and pass the paramters to it. When I try:
Call procText4(10)
I get the following error:
5568: SQL statement is not supported within a stored procedure.
The only other option for me is to create the SQL string in R and then run it from there but there is multiple passes of SQL which create volatile tables and the RODBC package doesn't seem to like them, plus it's a very messy way of doing it.
Any help is much appreciated.
The syntax for returning a result set from a Stored Procedure using Dynamic SQL is a bit complex:
CREATE PROCEDURE procTest4 (IntN INTEGER)
DYNAMIC RESULT SETS 1
BEGIN
DECLARE SqlStr VARCHAR(1000);
DECLARE rslt CURSOR WITH RETURN ONLY FOR stmt;
SET SQLStr = 'SELECT top ' || IntN || ' * from TableName';
PREPARE stmt FROM SqlStr;
OPEN rslt;
END;
But you should double check if you can rewrite those loops...

Stored procedure in DB2

I have a stored procedure that starts with the following:
CREATE PROCEDURE somename.tablename (IN P_DATE DATE,
OUT P_ROWS_TO_INSERT INTEGER)
Can someone please explain the purpose of the IN and OUT parameter calls?
So SQL OUT parameter allows the stored procedure to the pass data value back to invoker. IN param is param what you adding to your stored procedure.
Basic example:
DECLARE
V_OUT INTEGER;
BEGIN
EXECUTE SomeName('22.2.2000', V_OUT);
DBMS_OUTPUT.PUT_LINE('OUT is: ' || V_OUT);
END;

Oracle Stored Procedure with Alter command

I am trying to build an Oracle stored procedure which will accept a table name as a parameter. The procedure will then rebuild all indexes on the table.
My problem is I get an error while using the ALTER command from a stored procedure, as if PLSQL does not allow that command.
Use the execute immediate statement to execute DDL inside PL/SQL.
create procedure RebuildIndex(index_name varchar2) as
begin
execute immediate 'alter index ' || index_name || ' rebuild';
end;
I tested this code; it works.
Documentation.
Passing Schema Object Names As Parameters
Suppose you need a procedure that
accepts the name of any database
table, then drops that table from your
schema. You must build a string with a
statement that includes the object
names, then use EXECUTE IMMEDIATE to
execute the statement:
CREATE TABLE employees_temp AS SELECT last_name FROM employees;
CREATE PROCEDURE drop_table (table_name IN VARCHAR2) AS
BEGIN
EXECUTE IMMEDIATE 'DROP TABLE ' || table_name;
END;
/
Use concatenation to build the string,
rather than trying to pass the table
name as a bind variable through the
USING clause.
In addition, if you need to call a
procedure whose name is unknown until
runtime, you can pass a parameter
identifying the procedure. For
example, the following procedure can
call another procedure (drop_table) by
specifying the procedure name when
executed.
CREATE PROCEDURE run_proc (proc_name IN VARCHAR2, table_name IN VARCHAR2) ASBEGIN
EXECUTE IMMEDIATE 'CALL "' || proc_name || '" ( :proc_name )' using table_name;
END;
/
If you want to drop a table with the
drop_table procedure, you can run the
procedure as follows. Note that the
procedure name is capitalized.
CREATE TABLE employees_temp AS SELECT last_name FROM employees;
BEGIN
run_proc('DROP_TABLE', 'employees_temp');
END;
/
Here are a couple of possibilities. First, you would have to treat the SQL as dynamic SQL. Second, Oracle DDL statements cannot be run in a transaction (or, they terminate the current transaction and cannot themselves be rolled back). This may affect whether you can use them in stored procedures, or where you can use stored procedures that contain them.
If none of the above apply at all - there could easily be something else astray - I suggest posting some code.