I'm having a bizarre issue with SSRS 2012 reports, specifically with SQL Shared Data Sources.
My reproduction steps are as follows:
Create a new shared data source called Test, pointing to a SQL server on the network. Test credentials, get a successful test.
Create a new report called Test, not going through the wizard.
On the Test report, add the shared data source.
Add Dataset1 utilizing the shared datasource 'Test'. Query type of text as SELECT 1 AS 'one', 2 AS 'two'
Preview report. As expected, I get a blank report with no errors.
Commit data source and report to TFS repository (.rdl, .rds and changes to .sln).
Get latest on coworkers workstation
Open Test report, and go to Preview. The error I receive states 'An error has occurred during report processing.' Refreshing the report also gives error 'Object reference not set to an instance of an object,'
Recreating the shared data source on coworker's workstation lets the report run successfully again. Recommitting the changed data source then breaks the report on my original machine. The only thing changing in the .rds file is the DataSourceID, which is not referenced in the .rdl as far as I can see.
Both machines are on Visual Studio Premium 2013, with a SSRS 2012 solution file.
Any ideas as to what may be causing this are very much appreciated.
Cheers
For security, datasource credentials are not committed to source control nor propagated when deployed to a server. The first time you use the datasource in a new environment you will have to re-enter the credentials for the datasource to be able to connect to the database.
Related
Something really strange is happening with SSRS. I have a report which is powered by a stored proc which uses a lot of TSQL and CTE's to set variables ect... I know that there's no problem with the procedure as it runs in SQL and also runs within Visual Studio and returns a full data set. The issue I'm having is on deployment, I can't seem to get the report to return data when running it from the reporting server. The headers of the table and parameter are displayed but just no data.
I've tried the following:
- Deleting the .DATA file
- Clearing cache
- Checking for data source errors
- Checked the report server error log
- Rebuilt RDL and created a different report with the code
I'm clueless on this one, it's something I've never seen before.
Please help.
Much appreciated,
Thank you
Ri
I have a quarterly update package that I run from the backend of our system that uses an Excel (2007 format) document as a data source. The package stages the data from the Excel document to a table within the database, where it is processed and loaded in the production system.
Today, I received the Q2 update for April 2015, and attempted to run the new file into the staging system through Visual Studio as I have in the past. But for some reason today, VS / SSIS appears to be stuck "Validating Excel Source". I've let it sit for up to 10 minutes, before having to kill my Visual Studio instance through Task Manager.
The source document is small and relatively uncomplicated on 6 columns and less that 300 Kb in size, so I can't understand the validation issue all of a sudden. It appears to be the same excel version and format as my previous runs.
This package has been untouched for the better part of year, only having to change a series of parameters for each quarterly run.
I've deleted the connection managers and excel components from the package and recreated them but still appear to have the same issue. I've also recreated the source document.
I attempted tp disabled the DelayValidation and ValidateExternalMetaData properties, in hopes that it might give me a meaningful error dialogue, but have yet to get past the "Validating Excel Source" message.
Any input would be appreciated, Thank you.
I appear to have found a resolution to the issue.
It appears that a recent update to my installed Office suite altered the driver for Excel on my machine.
The following articles helped me resolve the issue, but as it turned out I needed to reinstall the Office 2007 System Driver: Data Connectivity Components...(linked in the 2nd article)
Once installed I was able to reopen my solution and view the Excel document.
Thank you for the assistance.
Using Excel 2012 file in Excel Connection Manager
How to fix errors: "the 'microsoft.ace.oledb.12.0' provider is not registered on the local machine"
Remove the excel file that the connection manager is looking for from the directory that it is pointing to. Once you do that the Validation of the Excel source should fail when it can not find the file it is looking for. This should allow you to get into the package and set Delay Validation = True in the properties.
The package validates the excel connection manager the same as it would any other OLE DB connection manager. It confirms connection and then runs your statement to validate the return of data. If you take away its source it should flame out quickly.
I have found that background processing on your machine can block this validation or processing of the request the same as a priority query might in SQL. If you machine is in a state with a number of priority tasks running this validation is put on the back burner and can and will take forever. In cases like this the connection used to the source being used to validate with either disconnect or timeout and it is not handled in the UI so it just hangs and locks up.
Although my title states my current goal, I am open to alternative solutions. In short, I have a series of SSIS packages that are scheduled to run on a nightly basis, on our SQL Server machine.
Due to various updates that happen in the ether of my corporate-IT, some times these exports brake and the process will stop working, in the middle of the job. To troubleshoot this process, I fire up BIDS on my workstation and restart which ever process fails. This is useful because it's been my experience that any error generated from within BIDS are much more useful than anything I've found from within SQL Server/Package Execution History or the servers event logs.
Historically, my problem has been that not all problems will occur in BIDS, but they will, consistently on the server. These issue have been painful to diagnose and have cost me a lot of time.
As such, what I would like to do is publish my package to the SSIS server, start the server instance from BIDS and monitor the project as it runs. Is this possible?
If not, is there something else that I can do so that I can monitor the internal steps as the process executes?
I fear that none of this may be possible but I have to ask. It will make my debugging and troubleshooting life so much easier.
Possible option:
You need to make use of Logging feature in SSIS. It allows you to configure the events for which you would like to capture the messages. I usually prefer the log OnWarning and OnError to keep track of all the warning and error messages that occur in the package. You have various provider to save the logging data. I prefer to use SQL Server so that I can query the logging information.
Logging options shown from SSIS 2012:
To enable logging in a package, you need to click the package Business Intelligence Development Studio (BIDS) if you are developing packages in SSIS 2005 - 2008 R2 or SQL Server Data Tools (SSDT) if you are developing packages in SSIS 2012.
Click SSIS menu and then click Logging...
You will see the Configure SSIS Logs dialog.
On the left side, you can check the package or individual tasks to log the event data.
On the Providers and Logs tab, you can select an appropriate provider to which you can save the log information. The below screenshot shows that event information are captured in a SQL Server database using the connection manager OLEDB_PracticeDB.
On the Details tab, you can select which events you would like to capture. The below screenshot shows that I am capturing the following events.
OnError
OnInformation
OnTaskFailed
OnWarning
Thanks to #William Todd Salzman for recommending OnTaskFailed event
Sample package illustration:
Let's say we have a package named SO_15004109.dtsx with a Data Flow Task and Script Task. Data Flow Task is just a dummy with no components inside.
Script task has the following code in Main method to fire custom information, warning and error messages so we can observe how it is captured in the logging data source. The code is written for SSIS 2012 so you may need to alter it for SSIS 2005. I chose VB.NET instead of C# because you have tagged this question under sql-server-2005 and SSIS 2005 only supports VB.NET.
Script Task code in VB.NET for SSIS 2005 and above.
#Region "Imports"
Imports System
Imports System.Data
Imports System.Math
Imports Microsoft.SqlServer.Dts.Runtime
#End Region
<Microsoft.SqlServer.Dts.Tasks.ScriptTask.SSISScriptTaskEntryPointAttribute()> _
<System.CLSCompliantAttribute(False)> _
Partial Public Class ScriptMain
Inherits Microsoft.SqlServer.Dts.Tasks.ScriptTask.VSTARTScriptObjectModelBase
Public Sub Main()
Dim fireAgain As Boolean = False
Dts.Events.FireInformation(101, "Custom Script Information", "This is a test information message.", String.Empty, 0, fireAgain)
Dts.Events.FireWarning(201, "Custom Script Warning", "This is a test warning message.", String.Empty, 0)
Dts.Events.FireError(201, "Custom Script Error", "This is a test error message.", String.Empty, 0)
Dts.TaskResult = ScriptResults.Success
End Sub
#Region "ScriptResults declaration"
Enum ScriptResults
Success = Microsoft.SqlServer.Dts.Runtime.DTSExecResult.Success
Failure = Microsoft.SqlServer.Dts.Runtime.DTSExecResult.Failure
End Enum
#End Region
End Class
If we execute the package, it will fail because we raised an error within the Script Task.
If you navigate to the data source where you logged the errors, you will notice that SSIS creates a table to log the information if you chose SQL Server logging provider. Below table lists the logging table that SSIS creates in the SQL Server database chosen to be the log provider.
SSIS Version Log table name Table type
-------------- ---------------- ----------
SSIS 2005 dbo.sysdtslog90 User
SSIS 2008 dbo.sysdtslog100 User
SSIS 2008 R2 dbo.sysssislog System
SSIS 2012 dbo.sysssislog System
Below query was executed in the database to view the events captured by this sample package. You will notice some messages twice because the events are logged for each containers and tasks. The table is named dbo.sysssislog because the package was created in SSIS 2012.
select id, event, source, message from dbo.sysssislog;
Personal experience with logging:
I have had fairly good success in just viewing the logging error messages to understand what went wrong. Debugging packages in production environment is not advisable, in my opinion. However, capturing log events is preferable.
When I worked in SSIS 2005 and 2008, I have created SSRS based reports that queries the log table to generate daily report of the job executions and send a PDF attachment to persons of interest.
Things have improved in SSIS 2012 that the tool comes with in-built reporting capabilities with Integration Services Catalog that creates a database named SSIDB.
At my current gig, we've started using a product from Pragmatic Works called BIxPress, which includes tools to inject logging code into existing SSIS packages and monitor running packages as they execute. It's not cheap, but we have found it helpful. (Especially since it means we don't have to roll our own monitoring code...)
I have been asked to create an MVC web application in VS 2010, and was instructed to use a SQL express database for my data. I am using EF Code-First for creating and managing my data. The database was created in VS2010, and is attached via "AttachDBFilename" in the web.config.
I have used SQL CE before with MVC with no problems, however the attached SQL Express DB is causing weird issues.
For one thing, when I try to deploy the app, it fails and tells me that it cannot copy the database.mdf because it is in use by another process. I have NOT opened the database in VS2010 nor SSMS. Of course the program code accesses it - is there some reason that connection would remain open? I am using boilerplate code from the scaffolding.
I should mention that I use a ProjectInitializer.cs to create the sample data. It runs at every launch for the moment, since I am testing quite a bit.
The other problem I have is that if I delete the database, it fails to recreate it. It says that my windows account does not have access to the (now non-existent) database that it is trying to create. I literally have to create a new database with new name, as anything that was created previously (with that DB name) fails.
I assume there is some sort of residual info being left somewhere that is out of synch, but I don't know what it is. I've closed all connections to the file in VS 2010, deleted the files, both any found via VS2010 and any physical files I see in the app_data directory.
Any help or suggestions would be appreciated.
Shut down the web server (Cassini, IIS, IIS Express) and try again. The file can remain locked if the web process is still referencing the file. In addition the loaded EF context will retain the db name. Ensure the visual studio browser isn't running in the tray still either.
I have a database I am using the Visual Studio 2010 Database Project tool vsdbcmd.exe to create a schema from.
vsdbcmd /a:Import /dsp:Sql /model:"Database" /cs:"Server=SqlServer; Initial Catalog=DatabaseName; Integrated Security=SSPI;"
The tool is reporting an error:
Error TSD02016, Gen-259 (12,50) The column name is not valid. No table name was specified.
How would I go about pinpointing where this error is originating?
I have found one resource on the internet (http://social.msdn.microsoft.com....) that points to a possibility of a keyword used incorrectly, but the error messages are not the same.
What is Gen-259?
Thank you,
Keith
I ran into a similar problem and was able to resolve it by using the import function in Visual Studio 2010. I created a new project and used Project -> Import Database Objects and Settings. In the our case, there were stored procedures that had become orphans and referenced columns in a table that no longer existed. We did have to correct some of the errors on the live system before we could get the project to fully import, but we were able to do that and create a .dbschema file which could be used as a reference in other VS projects.