If you have databases with another default collation than the instance default, you may get something like the following error:
[red_box]Msg 468, Level 16, State 9, Line 30 Cannot resolve the collation conflict between “Finnish_Swedish_CI_AS” and “Finnish_Swedish_100_CI_AS” in the equal to operation.[/red_box]
Sometimes a data flow in SSIS needs to be sorted. It may be because the business rules require sorted data, or it may be that you want to use either a Merge or Merge join component. Those component won’t work if the data isn’t sorted previously.
So, how does SSIS know if the data is sorted?
Before a fact table is loaded, a common pattern is to do a lookup in SSIS before the loading. The lookup can be some key from a dimension for instance, or maybe a repository of primary keys in a MDM solution. But what if the lookup doesn’t return a matching value? Sometimes when this happens, we want to insert new values to the lookup table (to get the key) before the loading of the fact table starts. Here I’ll show one way to handle this scenario.
The T-SQL function SERVERPROPERTY returns a lot of properties about the current SQL Server instance. The list of parameters it accepts can be found on Technet. On the top of the page, choose the version of SQL Server you are running.
In most cases stored procedures are developed so that it accepts a number of input parameters with a single value. But a common requirement is to be able to submit multi value parameters. That is, parameters that accept several values as opposed to a single value.
In SQL Server 2008, table values parameters in stored procedures was introduced.
SQL Server keeps a configurable number of error log files as text files on disk. So you can’t simply use T-SQL directly to read those text files. Instead you can use the system stored procedure xp_readerrorlog.
The SQL Server service keeps its own error logs outside of SQL Server in a number of text files. The location of the SQL Server error log is specified in a startup parameter for the SQL Server service.
In this blog post, I’ll demonstrate how to find the currently active node in a SQL Server cluster, and how to do a manual failover to another node.
Note that a failover will result in a short down time for your SQL Server environment. This is because a recovery (rollback and roll forward of transactions) will be performed on the new active node in the SQL Server cluster. In an environment with long running transactions, the time for the recovery may be substantial (how to check the latest recovery time). So don’t do failover in a production environment unless absolutely necessary. Preferably, use a cluster lab environment to test things out first.