Category: SQL Server

Reporting Services 2005 was installed on a virtual machine prior to a sysprep. I received errors from http://localhost/Reports and http://localhost/ReportServer that ultimately indicated that it couldn’t connect to the reporting database.

The resolution to this is to run a tool called "rsconfig". In my case, which I suspect is pretty common, the required command was:

rsconfig -c -s localhost -d ReportServer -a Windows

This led to the next issue, which was that Reporting Services was no longer able to "decrypt the symmetric key used to access sensitive or encrypted data in a report server database". I believe this is due to the fact that the public/private key of the virtual machine was changed after sysprep was run. Better practice (I’ll refrain from using ‘best practice’ here, as I’m sure there is a better process) would be to backup the symmetric key using the Reporting Services Configuration Manager before running sysprep, and then restoring it afterwards.

However, I had not backed up the key. So the solution was to use the configuration manager’s "Delete encrypted content" feature on the "Encryption Keys" page, then "Change" the key. This was fine for me to do as I had no schedules or encrypted connection strings in my Reporting Services database.

There is no Microsoft.Jet.OLEDB.4.0 provider for 64 bit Windows editions. If you need to use an Excel Source task or Excel Connection Manager in Integration Services on a 64 bit machine (I’m using Vista Ultimate x64), you will need to set your packages, or your project, not to use the 64 bit runtime. This is done by setting the Run64BitRuntime property to false on the project properties’ Debugging tab.

This article on MSDN provides more information about Integration Services running 64 bit editions of SQL Server and Windows.

Also note that if your source file is Excle 2007, the Excel Connection Manager cannot be used and the OLE DB Connection Manager must be used instead. See the note in the linked MSDN article about the Excel Connection Manager.

Technorati tags: SQL Server 2005

How do you perform a Lookup transformation using an input column of type DT_DATE (e.g. from a spreadsheet input) and a SQL Server table column that has the datetime type? Dragging the former onto the latter results in the error message "One or more columns do not have supported data types, or their data types do not match".

The answer is to create a Data Conversion transformation earlier in the flow. In this task, convert your input column to the type "database timestamp [DT_DBTIMESTAMP]". Make a note of the output alias you have entered. Now go back to the Lookup transformation and drag the new column (i.e. <output alias> of the Data Conversion transformation) onto the datetime column in the lookup table.

I’m using Visual Studio Team Edition for Database Professionals and have spotted a couple of niggles with it.

1) If you rename a foreign key field, the schema compare fails to recognize that it needs to update the foreign key constraint. Instead it creates a new one and leaves the old one in place and unchanged, causing an error.

2) Extended properties are behaving strangely. It seems to be dumping them all into a file called “ScriptsIgnoredOnImport.sql”, appending it on to any entry it left in that file last time it ran. As far as I can tell you need to manually copy the extended property creation lines out of this file and into the individual table SQL scripts in the project. Irritating.

In Business Intelligence Studio (AKA Visual Studio 2005), when editing a cube, there is a tab for creating calculations. This tab contains a handy ‘script organizer’ pane showing a list of the names of all your calculations, names sets, etc. Unfortunately if you select an item within the script organizer, the standard properties window does not show "Display Folder" and "Related Measure Group" properties. To get to these properties, there is a "calculation properties" icon near the top of the calculations tab.

A technical post for a change. We recently noticed a difference in SQL Server 2005 over 2000 around the use of the SCOPE_IDENTITY function. I’ve been used to "SELECT SCOPE_IDENTITY()" returning INT as its data type, as that was the largest data type that was allowed as an IDENTITY column. However, it now seems to be returning DECIMAL.

A quick investigation shows that DECIMAL can indeed be used as an IDENTITY column. There is a restriction that the scale must be zero, i.e. DECIMAL(n,0), so that the field only contains whole numbers.

Exciting? Maybe not. Interesting? Evidently enough for me to blog it.

Technorati tags: SQL Server 2005, SQL Server