I am translating procedure from Oracle to Snowflake and getting an error:
The procedure is:
https://github.com/santas-little-helper-13/sql/blob/main/sp.sql
I see that ":" is missed when using variables in a SQL statement or assigning the result of a SQL statement to a variable. Please check this part:
https://docs.snowflake.com/en/developer-guide/snowflake-scripting/variables.html#using-a-variable-in-a-sql-statement-binding
https://docs.snowflake.com/en/developer-guide/snowflake-scripting/variables.html#setting-variables-to-the-results-of-a-select-statement
This is a long SP so you may probably hit other errors. Good luck with the rest of the code.
Related
I am using powerbuilder with Sybase ASE database. I am calling a stored procedure while doing an update from my application but I am getting an error in the stored procedure. I want to put some print statements in the stored procedure to check what the error is. How can I see the output of this print statement? How can I log the stored procedure?
Thanks in advance
Sharmistha
There is no log of these print statements and they are not considered part of the result set. They are in the same channel as the Sybase ASE error messages.
They should be returned to PowerBuilder, in the SQLCA, sqlerrortext is the field.
That's not how I used to debug stored procedures though. I found it easier to capture the parameters being passed to the stored procedure and use Sybase's ISQL command line tool, not the Java GUI, to see the error messages.
You can use function which will return the status code. Add "ON EXCEPTION RESUME" clause inside function and return global variable ##error to your application.
Use a custom error logging procedure to store data in a log table and read errors from it during or after execution.
Alternatively, you can try the PRINT statement inside the procedure to see if you can get the stdout output into PB.
Thank you all, I added some logs in powerbuilder instead to check for my problem.
I'm working on a quick ASP Classic form that calls a TSQL proc. The first one that I created works great since it doesn't send any values in. Now I'm working on my second one and it looks a bit like this:
exec update_allocation(#Anum='164360',#mTeam='5',#Team='9',#Perc='14',#Bill=140000,#Mons=164360)
Also tried as:
exec update_allocation('164360','5','9','14',140000,164360)
First one gives me an error of:
Microsoft OLE DB Provider for SQL Server error '80040e14' Incorrect
syntax near '#Anum'.
The second gives me:
Microsoft OLE DB Provider for SQL Server error '80040e14' Incorrect
syntax near '164360'.
I'm not sure what to make of these errors. The issue must be the parameters, but not sure how they should be sent in.
The comments are correct but here is a bit of explanation as to why that is the case.
Both errors;
Microsoft OLE DB Provider for SQL Server error '80040e14' Incorrect syntax near '#Anum'.
and
Microsoft OLE DB Provider for SQL Server error '80040e14' Incorrect syntax near '164360'.
are actually quite descriptive and pinpoint where the issue is. Usually in a situation like this an error is highlighting a problem just before the word or phrase in an error description in these cases the #Anum parameter and the 164360 value. If we follow this through the previous character in both cases is an open bracket (.
Unlike functions in T-SQL, Stored Procedures do not require brackets around their parameters and doing so will raise an error (like the ones above) to correct this remove the brackets from both statements.
With named parameters;
EXEC update_allocation #Anum='164360', #mTeam='5', #Team='9', #Perc='14', #Bill=140000, #Mons=164360
Without named parameters;
EXEC update_allocation '164360', '5' ,'9' ,'14' ,140000 ,164360
Either method is acceptable syntax but personally I find it more useful to use the named parameter approach as that allows you to pick and choose what parameters to pass and even exclude ones that have defaults. You can still do this with the nameless approach but ordinal position of the values is more important.
#sean-lange makes a valid point here about SQL Injection vulnerability, consider using the ADODB.Command object to execute stored procedures rather then just calling the Execute() method on a ADODB.Connection object.
Here is an example of calling Stored Procedures using Classic ASP and the ADODB.Command object.
Answer to Using Stored Procedure in Classical ASP .. execute and get results
Answer to How to use ASP variables in SQL statement
I have a table that is storing SQL as one of its elements. I need to be able to run that stored SQL query, but can't figure out how to do it. So far, I'm using the following method:
<cfquery name="qDynamicTag" datasource="#myDSN#">
#PreserveSingleQuotes(arguments.sql)#
</cfquery>
If I dump the value of #PreserveSingleQuotes(arguments.sql)# before executing the cfquery I see the correct SQL statement. However, when I try to run the above cfquery I get a SQLException with the message:
Syntax error at token 0, line 0 offset 0
An example of one of the SQL statements that I'm trying to run:
select productid from catalog.producttag where tag = 'case' or tag = 'cases'
Any ideas on what I'm doing wrong?
Ha! Thanks for all your comments. The suggestion to check the debugging output of the DB activity made me realize that I wasn't seeing the DB activity in the debug section of the page because the query was executing through an AJAX call. After calling the page with the query directly, the DB debug output revealed that the code was good, but the data in the database was bad. One of the records with SQL didn't exist. Thus, cfquery was trying to run a blank string.
I am struggling to pass though parameter to a stored procedure I have written.
I’m really not sure what I am doing wrong here, but I’m struggling to get VB to pass parameters to SQL Server.
I am setting the #m_id above??
I would go out on a limb (because I don't see it in the above code) and say it's because you didn't set the cmd2.CommandType to StoredProcedure. By default, the command type is Text, which is used for inline SQL.
I am maintaining a classic ASP website that has a SQL Server 2005 backend. For a small piece of new functionality I wrote a stored procedure to do an insert. This is the only user stored procedure in the database.
When I attempt to call the stored procedure from code I get the following error:
Microsoft OLE DB Provider for SQL Server error '80040e14'
Could not find stored procedure 'InsertGroup'.
/newGroup.asp, line 84
The DB uses SQL Server authentication. When I connect to the DB server in Visual Studio using the same user/pw as in the connection string the stored procedure is not visible but all tables are.
The user has datareader and datawriter roles and explicit execute permission on the stored procedure.
What am I missing?
UPDATE: My apologies, the server admin misinformed me that it was a 2000 server when it is actually a 2005 server (running on Windows Server 2003 x64).
Walk of shame:
The connection string was pointing at the live database. The error message was completely accurate - the stored procedure was only present in the dev DB. Thanks to all who provided excellent answers, and my apologies for wasting your time.
You may need to check who the actual owner of the stored procedure is. If it is a specific different user then that could be why you can't access it.
Sometimes this can also happen when you have a stored procedure being called with parameters. For example, if you type something like:
set #runProc = 'dbo.StoredProcedure'
exec #runProc
This will work, However:
set #runProc = 'dbo.StoredProcedure ''foods'''
exec #runProc
This will throw the error "could not find stored procedure dbo.StoredProcedure 'foods'", however this can easily be overcome with parantheses like so:
set #runProc = 'exec dbo.StoredProcedure ''foods'''
exec (#runProc)
make sure that your schema name is in the connection string?
There are 2 causes:
1- store procedure name
When you declare store procedure in code make sure you do not exec or execute keyword
for example:
C#
string sqlstr="sp_getAllcustomers";// right way to declare it.
string sqlstr="execute sp_getAllCustomers";//wrong way and you will get that error message.
From this code:
MSDBHelp.ExecuteNonQuery(sqlconexec, CommandType.StoredProcedure, sqlexec);
CommandType.StoreProcedure will look for only store procedure name and ExecuteNonQuery will execute the store procedure behind the scene.
2- connection string:
Another cause is the wrong connection string. Look inside the connection string and make sure you have the connection especially the database name and so on.
I had:
USE [wrong_place]
GO
before
DECLARE..
Could not find stored procedure?---- means when you get this.. our code like this
String sp="{call GetUnitReferenceMap}";
stmt=conn.prepareCall(sp);
ResultSet rs = stmt.executeQuery();
while (rs.next()) {
currencyMap.put(rs.getString(1).trim(), rs.getString(2).trim());
I have 4 DBs(sample1, sample2, sample3) But stmt will search location is master Default DB then we will get Exception.
we should provide DB name then problem resolves::
String sp="{call sample1..GetUnitReferenceMap}";
One more possibility to check. Listing here because it just happened to me and wasn't mentioned;-)
I had accidentally added a space character on the end of the name.
Many hours of trying things before I finally noticed it. It's always something simple after you figure it out.
I had the same problem. Eventually I found why. I used a code from web to test output of my procedure. At the end it had a call to Drop(procedure) so I deleted it myself.
If the error message only occurs locally, try opening the sql file and press the play button.