Is it possible to execute SQLScript without creating a procedure? I would like to write ad-hoc queries using cursors, but by default, the "SQL Console" within HANA Studio uses HANA SQL instead of HANA SQLScript, which does not support cursors.
Since HANA SP10 there is the possibility to use anonymous blocks:
DO BEGIN
-- your logic
END
http://scn.sap.com/community/developer-center/hana/blog/2015/06/29/new-sqlscript-features-in-sap-hana-10-sps-10
At least you do not need to create the procedure as hdbprocedure file.
You can type in the SQL Console e.g. the following:
DROP PROCEDURE test; //from previous execution
CREATE PROCEDURE TEST()
LANGUAGE SQLSCRIPT
SQL SECURITY INVOKER
AS
BEGIN
--- Type your procedure code here. All features of procedures should be available
END;
CALL TEST();
Related
We are trying to execute multiple statements in BigQuery using stored procedures. This is a generic stored procedure which can invoked for any table, hence need to execute dynamic statements on any table.
Is there EXEC() like thing in BigQuery to execute dynamically generated queries?
Yes. As of 5/20/2020, BigQuery released dynamic SQL feature for you to achieve the goal.
Dynamic SQL is now available as a beta release in all BigQuery regions. Dynamic SQL lets you generate and execute SQL statements dynamically at runtime. For more information, see EXECUTE IMMEDIATE.
For your scenario, you could have a generic procedure:
CREATE PROCEDURE myTableOperations(tableName STRING)
BEGIN
EXECUTE IMMEDIATE CONCAT("SELECT col1 FROM ", tableName, " WHERE ...");
...
END
I have the following stored procedure
CREATE OR REPLACE PROCEDURE MyProcedure(nKey IN INTEGER, pcResult OUTCustomType) IS
BEGIN
OPEN pcResult FOR
SELECT MyPackage.IsBool1(nKey) AS IsBool1,
MyPackage.IsBool2(nKey) AS IsBool2,
MyPackage.IsBool3(nKey) AS IsBool3
FROM DUAL;
END;
We have an external team to test security, they use a tool to achieve that.
Our procedure is consumed in our .Net app via EF.
The security report shows that all procedures with a cursor as output have a risk for SQL injection.
Could you please explain me how SQL injection could be exlpoited on pcResult ?
Thank you for your help,
Bile
i have created an application in which i m calling xsjs file from the browser and in that xsjs file i am calling a normal sql procedure.In that procedure after some validations i m calling R procedure. My requirement is to create that R procedure in the user schema when the user call the xsjs file.And call statement for that R procedure should be updated in sql procedure.So basically everytime a user calls xsjs file the R procedure should be dropped and created again in the user schema.I am using SAP hana studio latest version.
If you want to execute dynamic SQL in SAP HANA, you can use EXECUTE IMMEDIATE SQL command that will work in read and write procedures. You can build SQL query to create a new procedure in xsjs, send this query to a read and write procedure in which you have to use EXECUTE IMMEDIATE QUERY to get your procedure created and same can be done for deletion as well.
I am new to the stored procedure in oracle and my simple code wont compile in oracle toad.
Here is my code:
code
There is a readline under the ALTER, and it says "Found: "ALTER", expecting select or (: BEGIN BASE COSE...) " why is that?
Oracle doesn't allow you to use DDL natively in PL/SQL. To work around this, you can use EXECUTE IMMEDIATE to run the DDL as a dynamic query.
Should we end stored procedures with GO statement, if so what are the advantages of using GO?
CREATE PROCEDURE uspGetAddress #City nvarchar(30)
AS
SELECT *
FROM AdventureWorks.Person.Address
WHERE City = #City
GO
The statement go, per the documentation
Signals the end of a batch of Transact-SQL statements to the SQL Server utilities.
...
GO is not a Transact-SQL statement; it is a command recognized by the sqlcmd and osql
utilities and SQL Server Management Studio Code editor.
SQL Server utilities interpret GO as a signal that they should send the current batch
of Transact-SQL statements to an instance of SQL Server. The current batch of statements
is composed of all statements entered since the last GO, or since the start of the
ad-hoc session or script if this is the first GO.
A Transact-SQL statement cannot occupy the same line as a GO command. However, the line
can contain comments.
Users must follow the rules for batches. For example, any execution of a stored procedure
after the first statement in a batch must include the EXECUTE keyword. The scope of
local (user-defined) variables is limited to a batch, and cannot be referenced after a
GO command.
A stored procedure definition, per the documentation for create procedure, comes with restrictions. it must be the first (and only) statement in the batch:
The CREATE PROCEDURE statement cannot be combined with other Transact-SQL statements in
a single batch.
That means the body of stored procedure ends with the batch. Adding GO in your source file is good practice. Especially since it's common to do things prior to and following the creation of a stored procedure. You'll often see source files that look something like this:
if (object_id('dbo.foobar') is not null ) drop procedure dbo.foobar
GO
-- dbo.foobar --------------------------------------------
--
-- This stored procedure does amazing and wonderful things
----------------------------------------------------------
create procedure dbo.foobar
as
...
{a sequence of amazing and wonderful SQL statements}
...
return 0
GO
grant execute on dbo.foobar to some_schema
GO
And the value for GO is adjustable in Sql Server Management Studio's options. If you'd like to use something like jump instead of go, you can (bearing in mind that you're almost certainly going to give yourself grief in doing so.).
No, you should end your procedure with RETURN.
CREATE PROCEDURE uspGetAddress #City nvarchar(30)
AS
SELECT *
FROM AdventureWorks.Person.Address
WHERE City = #City
RETURN
The GO is really meant to separate commands in a sql script.
Just wanted to point out that without a GO at the end of your stored procedure, any T-SQL after the supposed end of the procedure body will still be included in the body of the proc.
For example
CREATE PROCEDURE Foo
BEGIN
SELECT * FROM dbo.Bar;
END
DROP TABLE dbo.Bar;
In this example, running EXEC dbo.Foo will end up dropping the table even though it is after the END. To avoid that, you need to place a GO after the END.
I prefer to surround the body of the stored procedure with begin and end statements:
CREATE PROCEDURE uspGetAddress (
#City nvarchar(30)
) AS
BEGIN
SELECT *
FROM AdventureWorks.Person.Address
WHERE City = #City;
END;
GO is a not a T-SQL command. It is understood by the tools that run scripts. As the documentation describes:
GO is not a Transact-SQL statement; it is a command recognized by the
sqlcmd and osql utilities and SQL Server Management Studio Code
editor.
SQL Server utilities interpret GO as a signal that they should send
the current batch of Transact-SQL statements to an instance of SQL
Server. The current batch of statements is composed of all statements
entered since the last GO, or since the start of the ad hoc session or
script if this is the first GO.
By the way, in your case, a user-defined table function might be more appropriate than a stored procedure.