We have lots of SQL scripts in our codebase, which produce dynamic SQL statements, and we execute these statements against the database with
EXEC (#FINALSQL)
It is declared like this
DECLARE #FINALSQL NVARCHAR(MAX);
In one of our scripts, we now get an error when executing the dynamic SQL:
Error Number: 2812
Error Severity: 16
ErrorState: 62
ErrorMessage: Could not find stored procedure
with the SQL statement following.
The error number is related to the the error message but still couldn't find any related issue of how to resolve this problem.
I have also read this question but it didn't help because I already enclosed dynamic SQL in brackets
calling EXEC() generates error: could not find stored procedure
Any ideas what could have caused the problem?
Update: the use of #FINALSQL is to create Updates for an amount on tables based on condition in the script.
The answer to almost anything dynamic can be found in Erland Sommarskog's
tour de force.
http://www.sommarskog.se/dynamic_sql.html
"Execute" is optional for the first statement in a batch when executing a stored procedure. There is likely some formatting error in the string and the parser is trying to interpret the first word as a procedure name after failing to parse it otherwise.
If you have no option to capture the string, then use an Extended Event session or trace to capture the query for errors.
If it was a real procedure, then I 'd suspect that current database is wrong. A "USE mydatabase;" as the first thing in the string would fix that. But you state this is not the case. Also, the procedure name was not listed in the error message.
Related
I come from a heavy T-SQL background, have been familiarizing myself with IBM Netezza appliance for a customer. I have played with the Netezza emulator 7.1 on Windows, ran DDL, DML, Control, and Transaction statements. Also, I signed up for a trial DashDB on Bluemix cloud.
ISSUE:
I am facing hurdles with the syntax on both Aginity workbench for DashDB and also the RunSQL on Bluemix
These prevent me from writing more complex SQL beyond simple DDL, DML statements. I am quite frustrated about this.
variable declarations
T-SQL:
DECLARE #I AS INTEGER;
I tried this
DECLARE VARIABLE i INTEGER ;
ERROR [42601] [IBM][DB2/LINUXX8664] SQL0104N An unexpected token "INTEGER" was found following "DECLARE i ". Expected tokens may include: "END-OF-STATEMENT".
DECLARE i AS INTEGER;
ERROR [42601] [IBM][DB2/LINUXX8664] SQL0104N An unexpected token "INTEGER" was found following "DECLARE i AS ". Expected tokens may include: "END-OF-STATEMENT".
DECLARE i INTEGER;
ERROR [42601] [IBM][DB2/LINUXX8664] SQL0104N An unexpected token "INTEGER" was found following "DECLARE i ". Expected tokens may include: "END-OF-STATEMENT".
none of these work...I am simply baffled!
this very simple stored procedure sample from does not compile for me
Code:
CREATEPROCEDURE DASH6441.FOO (IN ORDER_DETAIL_CODE_IN VARCHAR(16), IN SALES_STAFF_CODE_IN INTEGER)
LANGUAGESQL
BEGIN
SELECT*FROM DASH6441.EMP;
END;
Error:
ERROR [42601] [IBM][DB2/LINUXX8664] SQL0104N An unexpected token "EMP" was found following "ECT * FROM DASH6441.". Expected tokens may include: "END".
Questions:
is there anything I am missing?
like T-SQL is there any structure for a SQL script, or preliminary directives (e.g. USING <db_name> in T-SQL) the compiler is expecting? I doubt it, but just asking
If you can share a skeleton of a variable declaration, stored procedure, or generic script with all those elements, which you know compiles successfully for you? Maybe I can inspire myself from that
I am facing a showstopper right now with this syntax issue.
You might need to change the default statement separator in runSQL to be something other than the ; character, so that procedures will be processed correctly.
More info on the use of SQL PL in dashDB is here.
for the create procedure issue the problem is as Margriet described the ambiguous statement delimiter. Just use e.g. delimiter '#' after the END statement and set this character in the RunSQL Page before executing the statement.
Regarding your problems with variable declarations: RunSQL allows to run individual SQL statements. Variable declarations are not valid as standalone SQLs, but only within the context of routines, e.g. within the BEGIN..END block of a stored procedure that you create. E.g. see the examples here: https://www.ibm.com/support/knowledgecenter/SS6NHC/com.ibm.swg.im.dashdb.sql.ref.doc/doc/r0004239.html
My real stored procedure is much more complex, but DB2 can't even seem to create a dummy stored procedure that does absolutely nothing (that's why I'm posting this dummy procedure). The procedure is as follows
CREATE PROCEDURE SIMPLE_DECL_PROC()
LANGUAGE SQL
BEGIN
DECLARE v varchar(16);//the problem is here
END
I'm getting the following error:
2:59:31 [CREATE - 0 row(s), 0.000 secs] [Error Code: -104, SQL State: 42601]
DB2 SQL Error: SQLCODE=-104, SQLSTATE=42601, SQLERRMC=END-OF-STATEMENT;ECLARE v varchar(16);<psm_semicolon>, DRIVER=3.57.82
The error complains about the declare statement although I can't see anything wrong with it (tried removing the ; at the end but it didn't work).
If I remove the declare statement, the procedure is created successfully.
I tried to do this with DBVisualizer as well as SQL Squirrel.
I'm sure it's something simple that I'm missing but I can't find it. Needless to say, I've checked similar questions here on SO and elsewhere.
And finally, we're using DB2 9.7.
Thanks
Most SQL clients allow to set a so-called statement terminator. This is the character that is at the end of the entire statement. By default most clients use the semicolon (";"). For stored procedures often a different statement terminator needs to be chosen and set. This is because a stored procedure can include multiple SQL statements which are terminated, but only that ouf the entire stored procedure is relevant.
I want to alter the procedure sys.sp_executesql in the master database (in the enhanced procedures folder or whatever that's called in English) because I want the procedure to print everything I pass to it.
My code is getting a bit ugly and bloated with all the...
if #d=1 print #sqlstatement (#d für debug)
...statements in front of my dynamic SQL execute statements. I have to do this because SSMS will not tell be the line number of an error of dynamic SQL. I print all the dynamic SQL before execution so that I know exactly what dynamic sql came before the error.
How I get rid of all the print statements to clean my code?
Simply find them all and erase, what else?
Or find the code, which produces this dynamic sql and modify it for non-producing such a code.
While running a procedure it gives error like Insert Error: Column name or number of supplied values does not match table definition. But when I run same set of queries without any procedure it run fine. Can someone tell me what 's the problem
I'm going to guess that your stored procedure is asking for a certain set of parameters, but you are supplying a different set of arguments. When you call the stored procedure, make sure any arguments given are correct for what is expected.
Either that or the stored procedure itself has an error trying to talk to a database table and getting the schema wrong.
I'm getting a SQL Server error on a stored procedure (although it appears to run and run correctly). When I view the stored procedure call in my code, it is underlined, and the highlighted error message says: "Procedure sp_ReferenceSite has no parameters and arguments were supplied."
My procedure is called like this:
execute dbo.sp_ReferenceFieldwork #refColumnName='Comment', #FldWkID=#FieldInvId, #reference=#ref output
and the procedure is defined as
CREATE PROCEDURE [dbo].[sp_ReferenceFieldwork]
#refColumnName varchar(100),
#FldWkID int,
#reference varchar(8000) output
AS
As far as I can tell, all the cases are correct, the number of parameters are correct, the field types are correct. What's the problem? Or, at least, what might be the problem?
If it runs OK, then it's probably the Intellisense cache.
How to refresh it
It's brain dead: take it outside and shoot it. Replace with Redgate SQL prompt or similar.