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've created a package that gets some information from a sql database and inserts them into Dynamics CRM.
When testing the package from Visual Studio everything goes as expected and the task finishes without any errors and the rows get inserte . However , when I publish the package to SSISDB on Sql Server the package fails with this error :
KingswaySoft.IntegrationToolkit.DynamicsCrm.CrmServiceException : CRM service call returned an error : A password is required in order to establish the connection ...
I tried changing the package protection level to EncryptSensitiveWithUserKey but it still gives the same message as above , created the package again from scratch still doesn't work . This package was working before , maybe there's something I did the last time in configuration which made it work but I cannot replicate it anymore .
Also I tried the Integrated Authentication it says this :
KingswaySoft.IntegrationToolkit.DynamicsCrm.CrmServiceException : CRM service call returned an error : The caller was not authenticated by the service .
#Drinv, this is a typical SSIS runtime deployment issue. You need to make sure that you have provided a password for your job configuration for the connection manager. What you provided to the package doesn't count as far as sensitive fields are concerned (password being one) when you are using the EncryptSensitiveWithUserKey option since user key is not transferrable between different systems or different users. An easy workaround is to change your SSIS package/project's ProtectionLevel setting to encrypt using a password instead, although it may not be the best practice. If you still have trouble getting this going, please reach out to us directly, our team can walk you through the issue.
I found out what I was doing wrong .
My SSIS project was on Project Deployment Model and I was trying to deploy only the package. After making my connections available on project level and deploying the whole project everything worked as expected .
Attempting to compile a stored procedure in SSMS, which contains an open query to a linked server. The linked server is connected and in my 'Server Objects/Linked Servers' folder. I can do the open query in a query tab, but when the same query is ran within the procedure, I get the error
Encryption not supported on the client
This was just working yesterday, with no changes on my end, that I'm aware of.
I am using SQL Server 2014 locally on my machine, and the procedure is attempting to connect to a linked server with a "Pervasive" DB, located elsewhere. Not sure which version.
So far, I've tried rebooting and our SQL Server DBA is unaware of an issue on anyone else's machine.
I found the answer to this elsewhere... Not on Stack Overflow, so I wanted it here for convenience...
When this occurs, in regards to a linked server, it is due to the fact that the encryption required by the target server doesn't match that of the requesting server, so connection could not be established.
To remedy this issue, you can attempt to uninstall everything SQL related on your machine and reinstall... Or you can attempt the following:
Using Command Prompt / Powershell / Cortana, type, 'regedit' and hit enter.
In 'Registry Editor,' navigate to this location... 'HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\MSSQLServer\Client\SNIxx.x' (The 'x's represent your version of SNI... "Sql Network Interface")
Backup the folder at the following location first, by clicking, 'File/Export' and save it wherever, 'HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\MSSQLServer\Client\'
Whatever version of SNI you have, in my case 11.0, you will do a file level search and replace, in the file data below, for SNIxx.x, replacing the version number with your's.
Now in Registry Editor, click, 'File/Import' and navigate to the folder where you've saved your new file, double click it, or highlight it and click, 'open'.
Here is the data which needs to exist in that file...
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\MSSQLServer\Client]
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\MSSQLServer\Client\ConnectTo]
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\MSSQLServer\Client\DB-Lib]
"AutoAnsiToOem"="ON"
"UseIntlSettings"="ON"
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\MSSQLServer\Client\SNIxx.x]
"ProtocolsSupported"=hex(7):73,00,6d,00,00,00,74,00,63,00,70,00,00,00,6e,00,70,
00,00,00,76,00,69,00,61,00,00,00,00,00
"ProtocolOrder"=hex(7):73,00,6d,00,00,00,74,00,63,00,70,00,00,00,6e,00,70,00,
00,00,00,00
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\MSSQLServer\Client\SNIxx.x\GeneralFlags]
"NumberOfFlags"=dword:00000002
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\MSSQLServer\Client\SNIxx.x\GeneralFlags\Flag2]
"Label"="Trust Server Certificate"
"Value"=dword:00000000
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\MSSQLServer\Client\SNIxx.x\LastConnect]
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\MSSQLServer\Client\SNIxx.x\np]
"DLLname"="SQLNCLI"
"NumberOfFlags"=dword:00000000
"NumberOfProperties"=dword:00000001
"ProtocolName"="Named Pipes"
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\MSSQLServer\Client\SNIxx.x\np\Property1]
"Name"="Default Pipe"
"Value"="sql\\query"
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\MSSQLServer\Client\SNIxx.x\sm]
"DLLname"="SQLNCLI"
"NumberOfFlags"=dword:00000000
"NumberOfProperties"=dword:00000000
"ProtocolName"="Shared Memory"
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\MSSQLServer\Client\SNIxx.x\tcp]
"DLLname"="SQLNCLI"
"NumberOfFlags"=dword:00000000
"NumberOfProperties"=dword:00000003
"ProtocolName"="TCP/IP"
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\MSSQLServer\Client\SNIxx.x\tcp\Property1]
"Name"="Default Port"
"Value"=dword:00000599
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\MSSQLServer\Client\SNIxx.x\tcp\Property2]
"Name"="KEEPALIVE (in milliseconds)"
"Value"=dword:00007530
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\MSSQLServer\Client\SNIxx.x\tcp\Property3]
"Name"="KEEPALIVEINTERVAL (in milliseconds)"
"Value"=dword:000003e8
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\MSSQLServer\Client\SNIxx.x\VIA]
"DLLname"="SQLNCLI"
"NumberOfFlags"=dword:00000000
"NumberOfProperties"=dword:00000002
"ProtocolName"="VIA"
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\MSSQLServer\Client\SNIxx.x\VIA\Property1]
"Name"="Default Server Port"
"Value"="0:1433"
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\MSSQLServer\Client\SNIxx.x\VIA\Property2]
"Name"="Default Client NIC"
"Value"="0"
I had a similar problem. The issue was that I had old versions of the SQL tools installed and the computer PATH was still setup to reference the 100 version before the 110 version.
For example, both 2008 and 2012 were installed.
C:\Program Files\Microsoft SQL Server\100\Tools\Binn
C:\Program Files\Microsoft SQL Server\110\Tools\Binn
Reference folder versions here:
SQL Server file names vs versions
I simply referenced the newer version and the problem was resolved.
I need to disable the option to attach a report in an SSRS subscription in SQL 2016. The only option that should be available is to send the report URL.
SSRS Subscription Setup
I am curious how to perform the recommended method from MSDN to "configure the report server to send only a report server URL" found in this article https://msdn.microsoft.com/en-us/library/ms160334.aspx.
I tried excluding a render format in my rsreportserver.config like this, but it didn't seem to do anything.
<ExcludedRenderFormats>
<RenderingExtension>PDF</RenderingExtension>
</ExcludedRenderFormats>
I have a test SSRS 2016 environment installed using SSRS Native mode but if needed, I can uninstall and re-install if necessary with a non-default configuration.
I figured it out. In the rsreportserver.config, find this element:
<Extension Name="Report Server Email" Type="Microsoft.ReportingServices.EmailDeliveryProvider.EmailProvider,ReportingServicesEmailDeliveryProvider">
Inside of that element is an element to add excluded file types. Just add all the supported file types and then the attachment option is effectively disabled.
<ExcludedRenderFormats>
<RenderingExtension>HTMLOWC</RenderingExtension>
<RenderingExtension>NULL</RenderingExtension>
<RenderingExtension>RGDI</RenderingExtension>
<RenderingExtension>PDF</RenderingExtension>
<RenderingExtension>MHTML</RenderingExtension>
<RenderingExtension>WORD</RenderingExtension>
<RenderingExtension>EXCEL</RenderingExtension>
<RenderingExtension>PPTX</RenderingExtension>
<RenderingExtension>IMAGE</RenderingExtension>
<RenderingExtension>WORDOPENXML</RenderingExtension>
<RenderingExtension>EXCELOPENXML</RenderingExtension>
<RenderingExtension>CSV</RenderingExtension>
<RenderingExtension>XML</RenderingExtension>
<RenderingExtension>ATOM</RenderingExtension>
<RenderingExtension>HTML4.0</RenderingExtension>
</ExcludedRenderFormats>
Finally, restart the SQL Server Reporting Services services.
Desired end result:
Just followed the steps in https://msdn.microsoft.com/en-us/library/ms143724.aspx to migrate a Reporting Services installation onto a new server (from and to SQL 2012 Standard Edition)
But when I'm ready to verify my deployment using the Report Manager web interface I get the error:
The feature: "Scale-out deployment" is not supported in this edition of Reporting Services. (rsOperationNotSupported)
Indeed when I go back to the Reporting Services Configuration manager, under Scale-out Deployment I have 2 servers, the one on the local server (new machine) and a reference to the old Server that has a different name. Problem is when I try to remove it tells me the task has failed:
Microsoft.ReportingServices.WmiProvider.WMIProviderException: Unable to connect to the Report Server . ---> System.Runtime.InteropServices.COMException (0x800706BA): The RPC server is unavailable
I can understand why it's unavailable as it is on a different network all together. so my question is, how can I get rid of it so everything can finally work?
Found it. The way to remove the ghost server is to connect to the ReportServer database, and remove the old server from the dbo.Keys table.
After a restart of Reporting Services, the old server isn't in the list anymore.
USE ReportServer
go
select * from keys
--for safety added to the delete ghost machine if no recent executions in last 30 days.
delete from keys
where MachineName = 'YourGhostServer' --replace with your old server name, if multiple run one by one.
and MachineName not in (select substring(InstanceName,0,(charindex('\',InstanceName,0)))
from ExecutionLog
where timestart>getdate()-30
group by InstanceName)
CAREFUL, run the first part only with the select, analyze the output then copy the specific machine name value (old server name) you wish to delete into the where clause of the delete statement, replacing YourGhostServer verbiage.
Note, the Keys table may have legitimate machines that are network reachable and online. You can verify this by simply pinging them or checking if they run the SSRS Service, don't just simply delete from the table a server that's actually online, instead use the Report Server Manager to remove a Server that's online.
Deleting from the Keys table should only be done if the old machine is truly unreachable or has been decommissioned. At least, that's what I would do in my case. :)