SSIS Package - The configuration refers to an object that does not exist in the package

A warning is thrown when there is a variable in the database not found in the package. This can be ignored by setting the "SupressConfigurationWarnings" property to true.

Technorati Tags: SSIS

TFS check in error – couldn’t check in the file ‘[file path]’

This error happens if the file no longer exists in the file system but TFS has staged the changes.

Remove the file from the file system by clicking View > Other Windows > Source Control Explorer and delete the file from the solution in TFS and try checking in again.

Technorati Tags: TFS 2013,VS 2013

System.IO.FileLoadException: Could not load file or assembly ‘’ or one of its dependencies. Assembly in host store has a different signature than assembly in GAC

Had this issue in using a SQL Server CLR Assembly.

Issue

Normally this issue arises if you have restored the database to a new server.

Solution

Check whether the owner has been assigned for the database.

Drop and Create the assembly and make to put the path of the assembly in plain text rather than scripting it from another environment as it would have been encoded and won't work on this server.

Technorati Tags: SQL Server,CLR

An error has occurred during report processing in SSRS

I have created a report and started creating subscriptions and used to get this error and wasn’t sure what’s going on.

Best way to trouble shoot this error is to check the SSRS logs under C:\Program Files\Microsoft SQL Server\MSRS10_50.MSSQLSERVER\Reporting Services\LogFiles for the default install location else which ever location SQL Server has been installed.

The Log files are of max size of 32MB and a new file gets created after reaching that size and the file name will look like ReportServerService__02_15_2010_12_56_37.log where 02_15_2010_12_56_37 refers to “MM_DD_YYYY_HH_mm_SS” format.

http://blogs.msdn.com/b/deanka/archive/2010/02/16/troubleshooting-subscriptions-part-ii-using-the-report-services-trace-log-file.aspx

Technorati Tags: SSRS,Subscriptions

Single Cube vs Multiple Cubes in SSAS

Multiple Cubes

• Having multiple, smaller cubes may result in faster query performance than one large cube in some cases, especially if the fact tables have very different dimensionality.
• While it is possible to apply dimension security to the Measures dimension, it is much easier to allow or deny access to a cube with the multiple cube approach than it is to apply security to all the measures in a measure group using the single cube approach.
• Having multiple, simpler cubes can be much more user friendly than one monster cube with loads of dimensions and measure groups. If you have Enterprise Edition you can of course use Perspectives to counter this, but if you are using Standard Edition then Perspectives aren’t available.
• Maintenance can be easier and less disruptive with multiple cubes: if you need to make changes to a cube while users are querying it, you might end up invalidating users’ connections and dropping caches. With one cube the chances of this disruption affecting more users increases.
• It’s easier to scale out with multiple cubes: if you find your server is maxing out, you can simply buy another server and distribute your cubes equally between the two. With a single cube approach you end up having to look at (admittedly not that much) more complex scale-out scenarios like network load balancing.

Single Cube

• If you ever need to work with data from two fact tables in the same query or calculation, or if you think you might ever need to in the future, you should go with the single cube approach. The two options for cross-cube querying, linked measure groups and the LookUpCube MDX function, should be avoided. Linked measure groups are a pain to manage, carry a slight query performance overhead, and can result in the same MDX calculations being duplicated across the original cube and the cube containing the linked measure group (which means maintenance becomes more difficult). The LookUpCube function is probably the worst MDX function to use in a calculation from a performance point of view and should be avoided at all costs. So a single cube is the only feasible option.
• Even if your users tell you they will not ever need to analyse data from two fact tables in the same query, be prepared for them to change their minds. In my experience, SSAS projects have a tendency to grow in complexity over time, and cubes that start out simple in a first release often grow lots of new functionality as time goes on – and the more successful the project, the quicker things get complicated. As soon as your users see what’s possible with SSAS they will start to have new, more ambitious ideas about the kind of analysis they want to do with their data, and it’s very likely that they will realise they do need to do cross-measure-group queries and calculations. If you started out on the multiple cube approach and then this happens you will have no choice but to use linked measure groups, and as I said this can make maintenance difficult; using the single-cube approach from the start means you won’t have this problem.

Thanks Chris Webb.

Technorati Tags: SSAS,Cubes