I have a simple query (included below). It's used inside a loop with two parameters. It works as a charm on one server, but when I use it with another server, it fails with "Parameters cannot be extracted from the SQL command".
DECLARE #Tagnavn As varchar(250)
DECLARE #HentEnergiNiveauEfter As datetime2(7)
set #Tagnavn = ?
set #HentEnergiNiveauEfter = ?
EXEC [FDTV_PUMP_AVERAGE_CONSUMPTION_FROM_DATE] #Tagnavn ,#HentEnergiNiveauEfter
I've seen the workaround with putting the query in a variable, but this doesn't work for me. And I really don't understand why the above works on one server but not another :-)
The working set-up consists of:
-Microsoft SQL Server Data Tools for Visual Studio 2017, v15.3.3
-the stored procedure is on an SQL Server v11
The non-working set-up consists of:
-Visual Studio Community 2017 - Tools for Applications 2017, v15.7.3
-the stored procedure is on an SQL Server v10
Thanks!
Palle
Problem solved. Permission problems with the server holding the stored procedure. Thanks for your input. And #Larnu: now it works without the temp. variables :-)
Thanks again,
Palle
Related
I regularly end up developing on projects where either the Central Test server, or Prod server is an older version of SQL Server than my local install.
e.g. Prod is SQL Server 2014. Local install in SQL Server 2019.
Mostly that's fine, it just means I have to remember to only use old syntaxes. (:cry:)
But occasionally I forget which syntaxes are old. Ooops.
Obviously our test environments catch this, but it would be great to be able to tell my Local Server ... "only accept SS2014 syntax", and have these mistakes caught before they're committed/pushed.
I thought this was what CompatibilityLevel was supposed to do. But either it doesn't, or I'm using it wrong. (See below)
How should I achieve this? (other than just installing a different SQL version!)
Attempt so far:
Run ALTER DATABASE MyLocalProjectDB SET COMPATIBILITY_LEVEL = 120; (120 represents SS2014)
Run SELECT name, compatibility_level FROM sys.databases WHERE name = db_name(); to confirm that the previous command "worked".
Run DROP TABLE IF EXISTS [ATableThatDoesExist], to see if the syntax is accepted. It was.
DROP IF EXISTS was new to SS2016:
MSDN: IF EXISTS ... Applies to: SQL Server ( SQL Server 2016 (13.x) through current version).
Additional Source
Why hasn't this worked?
I have an issue whereby I can execute an SSRS report which calls an Oracle Stored Procedure in VS2017, but when I deploy to the SSRS Server and run, it returns the following message:-
• An error has occurred during report processing. (rsProcessingAborted)
o Query execution failed for dataset 'spTestSubDet'. (rsErrorExecutingCommand)
For more information about this error navigate to the report server on the local server machine, or enable remote errors
The dataset 'spTestSubDet' is the Oracle Stored Proc.
Some configuration details:-
Oracle Database 19c Standard Edition 2 Release 19.0.0.0.0 - Production
SSRS version is 15.0.19528.0.
SQL Server version is 2014.
I can execute SQL code and Views against the Oracle server with the same DSN from the deployed report (without the oracle stored proc being present), so I know the DSN configuration is not the issue.
I have also check marked the "Use single transaction when processing the queries" box in the DS Properties.
I’m guessing that it might be some form of “Execute” permissions issue on Oracle, rather than the Report Server, where the Stored Proc is concerned.
As a developer, I don’t have any DBA permissions to interrogate how the SSRS Server is set up, or the Oracle DB, so any suggestions will have to be passed on to my ICT dept.
I also can't enable "remote errors" on the Report Server, but have requested that with the ICT dept.
Any help greatly appreciated.
Seems I got lucky with enabling “Remote Errors” on the report server and not personally having to restart the service.
I now have a more explicit error message from the SSRS report:-
“ORA-06550: line 1, column 7: PLS-00306: wrong number or types of arguments in call to 'SPTESTSUBDET' ORA-06550: line 1, column 7: PL/SQL: Statement ignored”
As mentioned in my original post, the report works fine locally from VS2017, so I don’t know why it’s telling me when deployed and run from the server that there seems to be a problem with the SQL code:-
create or replace
PROCEDURE SPTESTSUBDET
(s1 OUT SYS_REFCURSOR)
IS
BEGIN
OPEN s1 FOR
SELECT
*
FROM
onemain.sbceysubmitted sbceysub
WHERE
sbceysub.STUD_ID = 167071
;
END SPTESTSUBDET;
It’s as simple a test as I can put together and doesn’t use any parameters to complicate things.
I’m wondering if it might be a driver issue, though why it works locally and not on the server is baffling me.
I have Oracle Developer tools “ODAC v18.3.0” installed for VS2017.
The user in the referenced post below had what looked like to be the same problem, but it's not clear what version of the ODAC tools has been used to resolve the issue:-
https://stackoverflow.com/a/60569788/2053847
Any thoughts/help greatly appreciated.
The easiest thing to do is check the log files. I bet this is a SQL exception and it is related to something wrong with the way you are calling the stored procedure or within the stored procedure itself. The log files reside on the SSRS instance at -> SQL SERVER INTALL DIR\MSSQL.15(OR OTHER SSRS VERSION DIR)\Reporting Service\Log Files. Log files for the SSRS manager and SSRS service are saved here. Open the log for the SSRS Service after you encounter the error search for "spTestSubDet" and you should see the detail of the exception that is causing your problems.
I'm checking out the SQL Debugger using Visual Studio 2010 (connecting to a SQL 2005 Enterprise Server), and I can successfully debug a stored procedure by going to Server Explorer -> Right clicking on the procedure -> "Step Into Stored Procedure".
However, once I'm in, I can't step into or set any breakpoints inside any subsequent function or stored procedure calls. See the example below:
esp_StoredProc calls esp_AnotherStoredProc, but I can't set a breakpoint inside of esp_AnotherStoredProc or step into it during my debug session.
Is this a limitation of SQL debugging, or perhaps a limitation of my configuration or how I'm debugging things?
esp_StoredProc:
-- do something
-- do something else
-- call esp_AnotherStoredProc
I think that in sql server 2005 this was a limitation of SQL debugging. I could be wrong though.
I work with Crystal Report 2008 sp2, and during creation of a new report template I've encountered a problem. I created a stored procedure, which prepares and pivots needed data on the server side, and filters it using a parameter.
When I try to add this stored procedure to the report template in Crystal Editor, I receive SQL error 102 - incorrect syntax near ')'. Although I can easily add user defined function to my report with exactly the same parameter.
What could be the source of the problem?
P.S. Stored procedure does run and return correct data if I run it in the SSMS.
As long as you are returning a record set from the store procedure try using a command object
in the command object:
EXEC mystoredProc ({?variable1}, {?variable2})
The "exec mystoredProc()" was a good try, but didn't work for me.
Crystal to/from Oracle 10g SPs is kicking MY butt... I've worked every example from BOXI/SAP, a couple from the web, and from "Crystal Reports 9 on Oracle", and all I get are Crystal's/Oracle's error messages.
The latest is "Object Specified is incompatible with the flag specified." ORA-04047, with an ORA-20004 and an Ora-06512 thrown in for good measure.
I'm trying to get the simplest SP return for a beginning... Just give me the Select * results from a table.
Any hints?
I've tried the Oracle native (client) drivers, The Oracle ODBC drivers... I haven't gotten the Crystal Oracle drivers to work, tho'.
Depending upon the driver I'm using, I can get PLS-00302 - Component must be declared.
I've written and re-written these things over and over. Right now, I'm not a happy Oracle camper. MS SQL was sooo much easier.
I have a weird problem here.
In short to the environment we have:
There is a (newly set up) Win2003 Server with a SQL Server 2005 Express database. I connect to it via a MS Access application.
Since I switched to the new server (restored a backup from the former server on it) all SPROCs (only in Access) have a ;1 after their name, hence cannot be found.
If I try to open a SPROC in Access (dbl click in overview), it asks for the parameter, then says cannot be found.
If I try to open, say, a report based on it, same result. If I change the name of the SPROC the report is based on to the name shown in the overview ( [sprocnam];1 ) it says "cannot be found" (of course, because the names did not change as one can see in Management Studio).
?!?
keep in mind that the Access-application worked fine with the database that I backed up on another server and restored to the newly set up server ...
Your help is greatly appreciated!
edit: I found a thread on SAP.com with someone experiencing the same problem, but without a solution: https://forums.sdn.sap.com/message.jspa?messageID=7947957
I can't tell why you have got this issue, but in In SQL Server you have the ability to create Numbered stored procedures. The procedures have the same name but may contain completely different code, look at this:
CREATE PROCEDURE [dbo].[spTest]
AS
BEGIN
SELECT ##MICROSOFTVERSION
END
GO
CREATE PROCEDURE [dbo].[spTest];2
AS
SELECT ##version
GO
EXEC spTest;1
EXEC spTest;2
I resolved the issue with an update of the clients office-installation to the latest service pack.
The one employee that notified me of the problem and me got new computers last week, and thus did not have the latest updates.