I have created Main report and sub-report in Visual Studio 2017.
Sub-report "preview" works fine with dataset based on stored procedure.
Main report has a stored procedure that brings all "project numbers" which are the parameters for sub-reports. Both stored datasets are based on the same(shared) datasource which has specific credentials for the database. Both datasets have the same name.
Preview of Main report brings the correct number of sub-reports, but instead of data, displays "Data retrieval failed for the subreport" for both of them.
Now the worst part: I'm running windows 11 and there is NO Log files for ReportServices in the directory everybody is pointing to. The path looks like this "C:\Program Files\Microsoft SQL Server\80 or 90 or 110 or 120 or 130 or 150 or ClientSDK"
There is no ReportingServices Folder on my hard drive.
So I do not know WHAT causes the error.
Thank you.
Related
SQL Developer 2019
SSRS 2019
I restored my reporting database, SQL services to a new computer, restored databases, etc. I'm running everything on my localhost.
I have 20 reports I can access from the web SSRS ReportServer URL; only 1 of the 20 is prompting me for a user/pass before running the report.
I created copies of a working report and copies of the broken report with new names to test to see if something was cached. The broken copy is still broken (different name) and the working copy (different name) works.
I managed the reports, compared database sources and credentials between working an broken and they match.
I deleted the broken report, added it net new again, still prompts for the user/pass before opening the report.
Any idea why a single report would be corrupt like this; is there anything I can look at within the RDL?
I've got a report running the data I want - from the Preview tab, that is, or when run using F5 in VS 2010. But when I upload the report (.rdl file) to SQL Server Reporting Services, and run the updated report from there, it still shows the old bunch of (restricted) data.
Am I missing a step - does something need to be done other than uploading the .rdl file from the project? It did tell me the DataSource was wrong, but once I specified the right one, it ran without a hitch (except for the missing data).
I made sure that the updated report was truly being used by SQL Server Reporting Services by adding a bogus addition to a label, and sure enough, I do see that when I run the report, so the updated report is getting there.
I also verified that both the design time and runtime reports (same file, but copied to a different location) use the same data source: the SharedDataSource reference in the project, which I see when I select View > Report Data > Data Sources is the same being used In SQL Server Reporting Services, where I set the data source by selecting the yellow right down-arrow on the report name, then "Manage" > "Data Sources" > "A shared data source" > Browse > Home > Data Sources > and selected the shared data source with the same name as the one seen in the project. Finally, I selected OK > Apply in SQL Server Reporting Services, but only a subset of the data is generated.
Why would that be? What can I do to retrieve all the data?
UPDATE
To clarify what happens, in answer to yelxe's comment:
When I delete the previous version of the report in SSRS and upload a "new" one (.rdl file - the new version of the report just deleted), and then click the report link to try to run it, I get, "The report server cannot process the report or shared dataset. The shared data source 'CPSData' for the report server or SharePoint site is not valid. Browse to the server or site and select a shared data source. (rsInvalidDataSourceReference)"
So I click the yellow down-arrow to the right of the report and select Manage.
From there, I select Data Sources > A shared data source > Browse > Home/Data Sources/CPSData ("CPSData" is the same Shared datasource selected in the project) > OK > Apply, and then run the report.
This is where I do that:
It runs, but the data returned to the report is a subset of what I get when I run it from the IDE (VS 2010).
UPDATE 2
As for the data that is there when the report is run from SSRS, it is identical - IOW, the rows that are common to both the superset and the subset of data are identical; it's just that many rows are missing from the subset. And there doesn't appear to be anything "odd" about the data that exists in the superset - it's not 0 or negative or anything special or striking.
UPDATE 3
To reply to Eric's comment in more detail, the report's "Subscriptions", "Cache Refresh Options" and "Report History" pages shows "There are no items to show in this view. Click Help for more information about this page."
The report's Processing Options page shows
...and the report's "Snapshot Options" page shows
UPDATE 4
I noticed that the name of my Data Source was the same name as the name of my primary Dataset (they were both "CPSData"). The dataset name is just a label (it could be named "duckbilledplatypus" or whatever) but still I wondered if this confusing/misleading name for the dataset might have been problematic. So, I changed the name of the dataset to something more reasonable (I renamed it "VPM_V_RockBottom" as the Stored Procedure is named "sp_ViewPriceMatrix_Variance_RockBottom").
This made no difference, though. I replaced the new version of the report (.rdl file) in SSRS, re-ran the report, and still (don't) see the missing data.
Using the same parameters (date range and Unit name), this is what I see when run from my project's Preview tab:
...and here it is when run in SSRS:
So the "Hass"* Avocados show 18 members when run from VS 2010 (as it should be), and only 3 when run from SSRS. In both cases/places, "Asparagus Standard 11/1#" show 18 members, as they should.
Why would there be a difference, and how can I rectify this anomaly?
(sic - should be "Haas", not "Hass" (the German word for "hate"))
I have tried to remove the Dataset in SSRS and again create a new one same as the previous one.
It worked for me.
We have an SSRS Report Server (I don't know if the name "Report Sever" is peculiar to us or common to SQL Server report services (IOW, I don't know if we chose it, or Microsoft did)) that hosts various queries that users can run against our data.
I need to find out which query is being run, probably which Stored Proc, for a given report that is available.
I thought I could suss that out via the "View Source" from the page, but I see no "data source," nor the name of our connection, or such. In fact, I looked through the entire source and saw nothing helpful.
The "View Report" button is:
<td><input type="submit" name="ReportViewerControl$ctl04$ctl00" value="View Report" id="ReportViewerControl_ctl04_ctl00" />
...and the only other reference to it is here:
Sys.Application.add_init(function() {
$create(Microsoft.Reporting.WebFormsClient._PromptArea, {"CredentialsLinkId":"ReportViewerControl_ctl04_ctl01","ParameterIdList":["ReportViewerControl_ctl04_ctl03","ReportViewerControl_ctl04_ctl05","ReportViewerControl_ctl04_ctl07","ReportViewerControl_ctl04_ctl09"],"ParametersGridID":"ParametersGridReportViewerControl_ctl04","ReportViewerId":"ReportViewerControl","ViewReportButtonId":"ReportViewerControl_ctl04_ctl00"}, null, null, $get("ReportViewerControl_ctl04"));
});
Is there a way, either from the "View Source" or otherwise, where I can coax out the SP used to generate the report?
UPDATE
Spurred on by Steve Mangiameli's comment, I see that I have the following in my Start menu:
MS SQL Server 2005
SQL Server Business Intelligence Development Studio (BIDS)
MS SQL Server 2008
SQL Server Installation Center
MS SQL Server 2012
SQL Server Data Tools
I don't know which, of any, of these has value for me in this quest.
UPDATE 2
We do have a Visual Studio 2005 project named "Report Server" project with many .rdl files beneath the "Reports" folder. I thought this was a unique-to-us solution, but maybe not.
Even if this is the "Report Server" mentioned, though, I still don't know which .rdl file is the one that drives the report I can generate via our online Report Viewer page.
It would be nice if the report, when generated, had some reference to the name of the related .rdl file.
You're going to want to navigate either Report Manager or the Report Server to download the report. Once you have the .rdl file, open it in a text editor...it's just an xml file. Simply perform a find for "dataset" and inspect the dataset values. You will see the datasource, parameter and SP. Use this link to help you navigate the site.
Adding a better link with pictures. I'd do it myself but don't have access to cloud services here at work.
http://sql-articles.com/articles/general/download-export-rdl-files-from-report-server/
The easiest way is to use Sql Profiler. Run Sql Profiler, put a trace on your Sql Server and run your report. You'll then see the exact SQL statement that is hitting the server.
Assume one fine day an admin comes to the office like he always does to do his admin tasks on Sql Server Databases and to his surprise finds a database missing. He has no clue of who dropped it or was it from an external batch or SQL injection etc ... where do one start an investigation and what are the important parameters/ findings that should happen to find the root cause of the Drop DB. Like what logs shud be checked and what information shud be investigated ?
There is a defaul trace managed by SQL Server in a log file under c:\Program Files...
You can view this file by SQL command. For example to see the file log_19.trc you can fire command like
SELECT *
FROM fn_trace_gettable
('C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\LOG\log_19.trc', default)
This will probably show when and who dropped the database.
More information can be found Here...
I have an SSIS package that exports data to a couple of Excel files for transfer to a third party. To get this to run as a scheduled job on a 64-bit server I understand that I need to set the step as a CmdExec type and call the 32-bit version of DTExec. But I don't seem to be able to get the command right to pass in the connection string for the Excel files.
So far I have this:
DTExec.exe /SQL \PackageName /SERVER OUR2005SQLSERVER /CONNECTION
LETTER_Excel_File;\""Provider=Microsoft.Jet.OLEDB.4.0";"Data
Source=""C:\Temp\BaseFiles\LETTER.xls";"Extended Properties=
""Excel 8.0;HDR=Yes"" /MAXCONCURRENT " -1 " /CHECKPOINTING OFF /REPORTING E
This gives me the error: Option "Properties=Excel 8.0;HDR=Yes" is not valid.
I've tried a few variations with the Quotation marks but have not been able to get it right yet.
Does anyone know how to fix this?
UPDATE:
Thanks for your help but I've decided to go with CSV files for now, as they seem to just work on the 64-bit version.
This step-by-step example is for others who might stumble upon this question. This example uses SSIS 2005 and uses SQL Server 2005 64-bit edition server to run the job.
The answer here concentrates only on fixing the error message mentioned in the question. The example will demonstrate the steps to recreate the issue and also the cause of the issue followed by how to fix it.
NOTE: I would recommend using the option of storing the package configuration values in database or using indirect XML configuration with the help of Environment Variables. Also, the steps to create Excel file would be done using a template which would then archived by moving to a different folder. These steps are not discussed in this post. As mentioned earlier, the purpose of this post is to address the error.
Let’s proceed with the example. I have also blogged about this answer, which can be found in this link. It is the same answer.
Create an SSIS package (Steps to create an SSIS package). This example uses BIDS 2005. I have named the package in the format YYYYMMDD_hhmm in the beginning followed by SO stands for Stack Overflow, followed by the SO question id, and finally a description. I am not saying that you should name your package like this. This is for me to easily refer this back later. Note that I also have a Data Sources named Adventure Works. I will be using Adventure Works data source, which points to AdventureWorks database downloaded from this link. The example uses SQL Server 2008 R2 database. Refer screenshot #1.
In the AdventureWorks database, create a stored procedure named dbo.GetCurrency using the below given script.
CREATE PROCEDURE [dbo].[GetCurrency]
AS
BEGIN
SET NOCOUNT ON;
SELECT
TOP 10 CurrencyCode
, Name
, ModifiedDate
FROM Sales.Currency
ORDER BY CurrencyCode
END
GO
On the package’s Connection Manager section, right-click and select New Connection From Data Source. On the Select Data Source dialog, select Adventure Works and click OK. You should now see the Adventure Works data source under the Connection Managers section.
On the package’s Connection Managers section, right-click again but this time select New Connection…. This is to create the Excel connection. On the Add SSIS Connection Manager, select EXCEL. On the Excel Connection Manager, enter the path C:\Temp\Template.xls. When we deploy it to the server, we will change this path. I have selected Excel version Microsoft Excel 97-2005 and chose to leave the checkbox First row has column names checked so that the create the Excel file is created column headers. Click OK. Rename the Excel connection to Excel, just to keep it simple. Refer screenshots #2 - #7.
On the package, create the following variable. Refer screenshot #8.
SQLGetData: This variable is of type String. This will contain the Stored Procedure execution statement. This example uses the value EXEC dbo.GetCurrency
Screenshot #9 shows the output of the stored procedure execution statement EXEC dbo.GetCurrency
On the package’s Control Flow tab, place a Data Flow task and name it as Export to Excel. Refer screenshot #10.
Double-click on the Data Flow Task to switch to the Data Flow tab.
On the Data Flow tab, place an OLE DB Source to connect to the SQL Server data to fetch the data from the stored procedure and name it as SQL. Double-click on the OLE DB Source to bring up the OLE DB Source Editor. On the Connection Manager section, select Adventure Works from the OLE DB connection manager, select SQL command from variable from Data access mode and select the variable User::SQLGetData from the Variable name drop down. On the Columns section, make sure the column names are mapped correctly. Click OK to close the OLE DB Source Editor. Refer screenshots #11 and #12.
On the Data Flow tab, place an Excel Destination to insert the data into the Excel file and name it as Excel. Double-click on the Excel Destination to open the Excel Destination Editor. On the Connection Manager section, select Excel from the OLE DB connection manager and select Table or view from Data access mode. At this point, we don’t have an Excel because while creating the Excel connection manager, we simply specified the path but never created the file. Hence, there won’t be any values in the drop down Name of the Excel sheet. So, click the New… button (the second New one) to create a new Excel sheet. On the Create Table window, BIDS automatically provide a create sheet based on the incoming data source. You can change the values according to your preferences. I will simply click OK by retaining the default value. The name of the sheet will be populated in the drop down Name of the Excel sheet. The name of the sheet is taken from the task name, here in this case the Excel Destination, which we have named it as Excel. On the Mappings section, make sure the column names are mapped correctly. Click OK to close the Excel Destination Editor. Refer screenshots #13 - #16.
Once the data flow task is configured, it should look like as shown in screenshot #17.
Execute the package by pressing F5. Screenshots #18 - #21 show the successful execution of the package in both Control Flow and Data Flow Task. Also, the file is generated in the path C:\Temp\Template.xls provided in the Excel connection and the data shown in the stored procedure execution output matches with the data written to the file.
The package developed on my local machine in the folder path C:\Learn\Learn.VS2005\Learn.SSIS. Now, we need to deploy the files on to the Server that hosts the 64-bit version of the SQL Server to schedule a job. So, the folder on the server would be D:\SSIS\Practice. Copy the package file (.dtsx) from the local machine and paste it in the server folder. Also, in order for the package to run correctly, we need to have the Excel spreadsheet present on the server. Otherwise, the validation will fail. Usually, I create a Template folder that will contain the empty Excel spreadsheet file that matches the output. Later, during run time I will change the Excel output path to a different location using package configuration. For this example, I am going to keep it simple. So, let’s copy the Excel file generated in the local machine in the path C:\Temp\Template.xls to the server location D:\SSIS\Practice. I want the SQL job to generate the file in the name Currencies.xls. So, rename the file Template.xls to Currencies.xls. Refer screenshot #22.
To show that I am indeed going to run the job on the server in a 64-bit edition of SQL Server, I executed the command SELECT ##version on the SQL Server and screenshot #23 shows the results.
We will use Execute Package Utility (dtexec.exe) to generate the command line parameters. Log into the server which will run the SSIS package in an SQL job. Double-click on the package file, this will bring the Execute Package Utility. On the General section, select File system from Package source. Click on the Ellipsis and browse to the package path. On the Connection Managers section, select Excel and change the path inside the Excel file from C:\Temp\Template.xls to D:\SSIS\Practice\Currencies.xls. The changes made in the Utility will generate a command line accordingly on the Command Line section. On the Command Line section, copy the Command line that contains all the necessary parameters. We are not going to execute the package from here. Click Close. Refer screenshots #24 - #26.
Next, we need to set up a job to run the SSIS package. We cannot choose SQL Server Integration Services Package type because that will run under 64-bit and won’t find the Excel connection provider. So, we have to run it as Operating System (CmdExec) job type. Go to SQL Server Management Studio and connect to the Database Engine. Expand SQL Server Agent and right-click on Jobs node. Select New Job…. On the General section of the Job Properties window, provide the job name as 01_SSIS_Export_To_Excel, Owner will be the user creating the job. I have a Category named SSIS, so I will select that but the default category is [Uncategorized (Local)] and provide a brief description. On the Steps section, click New… button. This will bring Job Step properties. On the General section of the Job Step properties, provide Step name as Export to Excel, Select type Operating system (CmdExec), leave the default Run as account as SQL Server Agent Service Account and provide the following Command. Click OK. On the New Job window, Click OK. Refer screenshots #27 - #31.
C:\Program Files (x86)\Microsoft SQL Server\90\DTS\Binn\DTExec.exe /FILE
"D:\SSIS\Practice\20110723_1015_SO_21448_Excel_64_bit_Error.dtsx"
/CONNECTION Excel;"\"Provider=Microsoft.Jet.OLEDB.4.0;Data
Source=D:\SSIS\Practice\Currencies.xls;Extended Properties=""EXCEL 8.0;HDR=YES"";\""
/MAXCONCURRENT " -1 " /CHECKPOINTING OFF /REPORTING EWCDI
The new job should appear under SQL Server Agent –> Jobs node. Right-click on the newly created job 01_SSIS_Export_To_Excel and select Start Job at Step…, this will commence the job execution. The job will fail as expected because that is the context of this issue. Click Close to close the Start Jobs dialog. Refer screenshots #32 and #33.
Let’s take a look at what happened. Go to SQL Server Agent and Jobs node. Right-click on the job 01_SSIS_Export_To_Excel and select View History. This will bring the Log File Viewer window. You can notice that the job failed. Expand the node near the red cross and click on the line that Step ID value of 1. At the bottom section, you can see the error message Option “8.0;HDR=YES’;” is not valid. Click Close to close the Log File Viewer window. Refer screenshots #34 and #35.
Now, right-click on the job and select Properties to open the Job Properties. You can also double-click on the job to bring the Job Properties window. Click on the Steps on the left section. and click Edit. Replace the command with the following command and click OK. Click OK on the Job Properties to close the window. Right-click on the job 01_SSIS_Export_To_Excel and select Start Job at Step…, this will commence the job execution. The job will fail execute successfully. Click Close to close the Start Jobs dialog. Let’s take a look at the history. Right-click on the job 01_SSIS_Export_To_Excel and select View History. This will bring the Log File Viewer window. You can notice that the job succeeded during the second run. Expand the node near the green tick cross and click on the line that Step ID value of 1. At the bottom section, you can see the message Option The step succeeded. Click Close to close the Log File Viewer window. The file D:\SSIS\Practice\Currencies.xls will be successfully populated with the data. If you execute the job successfully multiple times, the data will get appended to the file and you will find more data. As I mentioned earlier, this is not the right-way to generate the files. This example was created to demonstrate a fix for this issue. Refer screenshots #36 - #38.
Screenshot #39 shows the differences between the working and the non-working command line arguments. The one on the right is the working command line and the left one is incorrect. It required another double quotes with backslash escape sequence to fix the error. There could be other ways to fix this well but this option seems to work.
Thus, the example demonstrated a way to fix the command line argument issue while accessing Excel data source from an SSIS package that is deployed on a 64-bit server.
Hope that helps someone.
Screenshots:
#1: Solution_Explorer
#2: New_Connection_Data_Source
#3: Select_Data_Source
#4: New_Connection
#5: Add_SSIS_Connection_Manager
#6: Excel_Connection_Manager
#7: Connection_Managers
#8: Variables
#9: Stored_Procedure_Output
#10: Control_Flow
#11: OLE_DB_Source_Connections_Manager
#12: OLE_DB_Source_Columns
#13: Excel_Destination_Editor_New
#14: Excel_Destination_Create_Table
#15: Excel_Destination_Edito
#16: Excel_Destination_Mappings
#17: Data_Flow
#18: Successful_Package_Execution_Control
#19: Successful_Package_Execution_Data_Flow
#20: C_Temp_File_Created
#21: Data_Populated
#22: File_On_Server
#23: SQL_Server_Version
#24: Execute_Package_Utility_General
#25: Execute_Package_Utility_Connection_Managers
#26: Execute_Package_Utility_Command_Line
#27: Job_New_Job
#28: New_Job_General
#29: New_Job_Step
#30: New_Job_Step_General
#31: New_Job_Steps_Added
#32: Job_Start_Job_at_Step
#33: SQL_Job_Execution_Failure
#34: View_History
#35: SQL_Job_Error_Message
#36: SQL_Job_Execution_Success
#37: SQL_Job_Success_Message
#38: Excel_File_Generated
#39: Command_Comparison
You can use an Excel connection in 64bit environment.
Go to the package configuration properties.
Debugging -> Debugging Options -> Run64BtRuntime -> change to False
In addition if you use SQL Agent go to the job step properties and then check the 32 bit runtime.
note: this only applies to debugging within Visual Studio...
There is no 64-bit Jet OLEDB provider, so you can't access Excel files from 64-bit SSIS.
However, you can use 32-bit SSIS even on 64-bit server. It is already installed when you installed 64-bit version, and all you need to do is run the 32-bit DTEXEC.EXE - the one installed Program Files (x86)\Microsoft Sql Server\90\Dts\Binn (replace 90 with 100 if you are using SSIS 2008).
Unless it's a business requirement, I suggest you move the connection string from the command line to the package and use a package configuration to define the path to the Excel file (in order not to hard-code it). This will make it easier to maintain.
Define a variable #ExcelPath.
Use connection's Expression property to construct a connection string - an example: "Data Source=" + #[User::FilePath] + ";Provider=Microsoft.Jet.OLEDB.4.0;Extended Properties=dBASE IV;"
Assign a value to #ExcelPath in the package configuration.
Take a closer look at the connection string above. It's taken from a working package. I'm not sure about this, but maybe you don't need any quotes at all (the ones above are only there because the expression editor requires them).
I have also had some problems with SSIS on 64-bit SQL Server 2005. That post from my blog does not answer your question, but it is somewhat related so I am posting the link.
I kinda did what Dr Zim did but I copied the DTExec file C:\Program Files (x86)\Microsoft SQL Server\90\DTS\Binn\DTExec.exe to C:\Program Files\Microsoft SQL Server\90\DTS\Binn\ folder but named the 32 bit one to DTExec32.exe
then I was able to run my SSIS script through a stored proc:
set #params = '/set \package.variables[ImportFilename].Value;"\"' + #FileName + '\"" '
set #cmd = 'dtexec32 /SQ "' + #packagename + ' ' + #params + '"'
--DECLARE #returncode int
exec master..xp_cmdshell #cmd
--exec #returncode = master..xp_cmdshell #cmd
--select #returncode