I'm trying to create the following stored proc with table-valued type as one of the parameter. However, I'm getting error as
Incorrect syntax near 'READONLY'.
I've checked many stackoverflow responses which mentions that the reasons could be sql server version. This is what my ##version tells me and looks fine to me
Microsoft SQL Server 2014 (RTM-CU14) (KB3158271)
Create PROCEDURE [dbo].[Customer_Select](
#variableTable dbo.CustomVariableType READONLY,
#return BIT = NULL OUTPUT)
AS
BEGIN
SELECT * FROM Customer
SET #return=1
END
Appreciate your help in this regard
It started to work after I restarted SSMS. Weird!!
Related
I read (and tried) that I cannot use WITH UR in DB2 stored procedures. I am told that I can use SET OPTION to achieve the same. However, when I implement it in my stored procedure, it fails to compile (I moved around its location same error). My questions are:
Can I really not use WITH UR after my SELECT statements within a procedure?
Why is my stored procedure failing to compile with the below error
message?
Here is a simplified version of my code:
CREATE OR REPLACE PROCEDURE MySchema.MySampleProcedure()
DYNAMIC RESULT SETS 1
LANGUAGE SQL
SET OPTION COMMIT=*CHG
BEGIN
DECLARE GLOBAL TEMPORARY TABLE TEMP_TABLE AS (
SELECT 'testValue' as "Col Name"
) WITH DATA
BEGIN
DECLARE exitCursor CURSOR WITH RETURN FOR
SELECT *
FROM SESSION.TEMP_TABLE;
OPEN exitCursor;
END;
END
#
Error Message:
SQL0104N An unexpected token "SET OPTION COMMIT=*CHG" was found
following " LANGUAGE SQL
Here is code/error when I use WITH UR
CREATE OR REPLACE PROCEDURE MySchema.MySampleProcedure()
LANGUAGE SQL
DYNAMIC RESULT SETS 1
--#SET TERMINATOR #
BEGIN
DECLARE GLOBAL TEMPORARY TABLE TEMP_TABLE AS (
SELECT UTI AS "Trade ID" FROM XYZ WITH UR
) WITH DATA;
BEGIN
DECLARE exitCursor CURSOR WITH RETURN FOR
SELECT *
FROM SESSION.TEMP_TABLE;
OPEN exitCursor;
END;
END
#
line 9 is where the DECLARE GLOBAL TEMPORARY ... is
DB21034E The command was processed as an SQL statement because it was
not a valid Command Line Processor command. During SQL processing it
returned: SQL0109N The statement or command was not processed because
the following clause is not supported in the context where it is
used: "WITH ISOLATION USE AND KEEP". LINE NUMBER=9. SQLSTATE=42601
Specifying the isolation level:
For static SQL:
If an isolation-clause is specified in the statement, the value of that clause is used.
If an isolation-clause is not specified in the statement, the isolation level that was specified for the package when the package was bound to the database is used.
You need to bind the routine package with UR, since your DECLARE GTT statement is static. Before CREATE OR REPLACE use the following in the same session:
CALL SET_ROUTINE_OPTS('ISOLATION UR')
P.S.: If you want to run your routine not only 1 time in the same session without an error, use additional WITH REPLACE option of DECLARE.
If your Db2 server runs on Linux/Unix/Windows (Db2-LUW), then there is no such statement as SET OPTION COMMIT=*CHG , and so Db2 will throw an exception for that invalid syntax.
It is important to only use the matching Db2 Knowledge Centre for your Db2 platform and your Db2-version. Don't use Db2-Z/OS documentation for Db2-LUW development. The syntax and functionalities differ per platform and per version.
A Db2-LUW SQL PL procedure can use with ur in its internal queries, and if you are getting an error then something else is wrong. You have to use with ur in the correct syntax however, i.e in a statement that supports this clause. For your example you get the error because the clause does not appear to be valid in the depicted context. You can achieve the desired result in other ways, one of them being to populate the table in a separate statement from the declaration (e.g insert into session.temp_table("Trade ID") select uti from xyz with ur; ) and other ways are also possible.
One reason to use the online Db2 Knowledge Cenbtre documentation is that it includes sample programs, including sample SQL PL procedures, which are also available in source code form in the sample directory of your DB2-LUW server, in addition to being available on github. It is wise to study these, and get them working for you.
I have a master script that runs and create all stored procedures, but when I run the script I error out at the only two places that use the syntax CREATE OR ALTER PROCEDURE
The code is below:
CREATE OR ALTER PROCEDURE [dbo].[P_ReinitializeStorePlans]
#storeId INT
AS
BEGIN
RETURN;
END
GO
And the error is as follows, I have another CREATE OR ALTER PROCEDURE later at line 2713 as well with the same error.
I have checked my ##VERSION which returns SQL 2016 as well as 130 for the compatibility version. Any idea why this is giving me an error? I am assuming its a compatibility setting or flag for the syntax?
I believe this one comes with SP1 installed, this has a version of
13.0.4001.0 KB3182545
https://support.microsoft.com/en-us/help/3177312/sql-server-2016-build-versions
I suggest you go straight to SP2 you can get it from here https://go.microsoft.com/fwlink/?linkid=869608
I'm writing a script in Sybase ASE where I call a stored procedure in SQL Server. The problem I have is that I'm getting an error from Sybase but not from SQL Server.
The Script in Sybase is as follows:
declare #input varchar(4000)
select #input = '111,222,333,444,555'
exec GATEWAY.MyDataBase..MyStoredProcedure #input
And this is the error:
[Error] Script lines: 1-5 --------------------------
Conversion failed when converting the varchar value '555.............................................................................................................................................' to data type int.
Msg: 245, Level: 16, State: 1
Server: GATEWAY, Line: 0
My stored procedure in SQLServer
I don't know why Sybase adds that right padding. The only way I can get it work is declaring the variable #input as varchar(255) or shorter.
What I tried without luck:
Adding a rtrim and ltrim in sybase
Setting the variable as TEXT
Adding rtrim and ltrim in SQLServer
adding a replace(#input,' ', '')
Wanted to replicate the problem in SQLServer adding the pad to the right but it still works.
The important thing is that: I can excecute it from SQLServer but it throws error from Sybase with the same input data.
Any help would be very appreciated. I guess it has something to do with the size of the varchar but no clue yet.
You can create a remote procedure in Sybase like this:
CREATE PROCEDURE "DBA"."uspSQL_CreateTicketsByCaseNo;1"( in #caseNo varchar(8) )
at 'SQL;dbName;dbo;uspSQL_CreateTicketsByCaseNo'
You can also right-click the Procedures & Functions and use the wizard to create a remote procedure. Then call the remote procedure like this:
CALL "DBA"."uspSQL_CreateTicketsByCaseNo;1"( caseNo )
It works for me.
I have written an SQL script which runs fine when executed directly in SQL Management Studio. However, when entering it into Power BI as a source, it reports that it has an incorrect syntax.
This is the query:
EXEC "dbo"."p_get_bank_balance" '2'
However, the syntax is apparently incorrect? See Picture:
Any help is much appreciated.
EDIT ***
When the double quotes are removed (as per Tab Alleman's suggestion):
I found time ago the same problem online on power bi site:
http://community.powerbi.com/t5/Desktop/Use-SQL-Store-Procedure-in-Power-BI/td-p/20269
You must be using DirectQuery mode, in which you cannot connect to data with stored procedures. Try again using Import mode or just use a SELECT statement directly.
In DirectQuery mode, PowerBI automatically wraps your query like so: select * from ( [your query] ), and if you attempt this in SSMS with a stored procedure i.e.
select * from (exec dbo.getData)
You get the error you see above.
The solution is you have to place your stored procedure call in an OPENQUERY call to your local server i.e.
select * from OPENQUERY(localServer, 'DatabaseName.dbo.getData')
Prerequisites would be: enabling local server access in OPENQUERY with
exec sp_serveroption #server = 'YourServerName'
,#optname = 'DATA ACCESS'
,#optvalue = 'TRUE'
And then making sure you use three-part notation in the OPENQUERY as all calls there default to the master database
With "Import" data connectivity mode Stored Procedures work
With "Direct Query" data connectivity mode, the query syntax must be like below:
declare #sqlCommand varchar(100) = 'dbo.p_get_bank_balance'
declare #p1 int = 2
exec #sqlCommand #p1 = #p1
Remerber: max one data source connection with Direct Query. If you want to call much SP, only one can be in Direct Query mode, the others in Import mode
Try using Import instead of Direct Query. It may be showing error cause you are using Temp table in it. Create query using sub query and remove Temp table and try it. Or you can use as Import instead of Direct Query it will work.
I've got an Informix machine I've configured as a linked server in SQL Server.
I can remotely send, and receive the results of, a query for, say
SELECT * FROM linkedServer.instanceName.database.myTable
but can't run the
linkedServer.instanceName.database.selectAllFromMYTABLE
stored procedure.
The error message I'm getting returned is "[Informix][Informix ODBC Driver][Informix]A syntax error has occurred." which is not massively helpful, except that it tells me that my request was received in some form...
Could someone tell me what the correct calling syntax would be to execute an Informix stored procedure via SQL Server? Presumably I'm screwing up the stored procedure call, because the stored procedure can be verified to be working fine on the Informix server.
EDIT: Adding the full text of a stored procedure I am testing, in order to verify I'm not doing something stupid in Informix which is causing a knock-on problem with the SQL Server execution:
CREATE FUNCTION sp_testSP()
RETURNING char(20) as item_no
DEFINE item_no char(20);
FOREACH
SELECT table_name.item_code
INTO item_no
FROM table_name
WHERE table_name.item_code LIKE 'test%'
RETURN item_no WITH RESUME;
END FOREACH;
END FUNCTION
As I've mentioned, this appears to work fine in RazorSQL, which I have connected to Informix, but maybe seeing this will jog someone's memory with some reason why SQL Server can't work with this return method...
Have you tried using OpenQuery?
http://msdn.microsoft.com/en-us/library/ms188427.aspx
In native Informix, you would write (approximately):
EXECUTE PROCEDURE database#linkedServer:selectAllFromMYTABLE();
I'm not sure quite where you'd fit an instance name into that - the 'linkedServer' corresponds to an instance name (to my way of thinking). The nearest approaches would be:
database#linkedServer:instancename.selectAllFromMyTABLE()
instancename#linkedServer:database.selectAllFromMyTABLE()
However, that is via the native Informix interfaces. If you go via SQL Server, then the syntax probably needs to be the native SQL Server syntax for invoking a procedure. In theory, I believe, the API used (ODBC or whatever) should be able to translate to the native Informix syntax.