Converting Reporting Services (SSRS) rdl from 2005 into 2000

Case
I receive a error when uploading my report.

Error number: 0x80048298

Information:
[CrmException: Exception of
type Microsoft.Crm.CrmException was thrown.]
Microsoft.Crm.Application.Platform.Report. InternalCreate(String xml) +721
Microsoft.Crm.Application.Platform.Entity.Create() +109
Microsoft.Crm.Application.Forms.AppForm. RaiseDataEvent(FormEventId eventId)
+408 Microsoft.Crm.Application.Forms.EndUserForm. Initialize(Entity entity) +57
Microsoft.Crm.Application.Forms.EndUserForm. Execute(Entity entity) +13
Microsoft.Crm.Web.Tools.ReportProperty. ReportPropertyPage.ConfigureForm() +202
Microsoft.Crm.Application.Controls.AppPage. OnPreRender(EventArgs e) +30
System.Web.UI.Control.PreRenderRecursiveInternal() +62
System.Web.UI.Page.ProcessRequestMain() +1499

Problem
I made a mistake and created a report in VS2005 instead of VS2003. How could I change this?

Gary Cowan gave a real good tip on : http://sqlservertipsandtricks.blogspot.com/2008/06/converting-reporting-services-ssrs-rdl.html

but it wasn’t really complete for my case. In the end it turned out I had to change the document as following.

Solution
If you want to convert a SSRS rdl from 2005 to 2000, you can try the following

1) Open the .RDL file in a text editor and change the XML.
2) Change the first node to look like this:

Report
xmlns=”http://schemas.microsoft.com/sqlserver/reporting/2003/10/reportdefinition”
xmlns:rd=”http://schemas.microsoft.com/SQLServer/reporting/reportdesigner”

3) Do a search for “Interactive” You should find 2 nodes InteractiveWidth and InteractiveHeight. You need to delete these nodes.

4) The XML in the RDL file is different between 2005 and 2000 when you want to pass parameters to a SQL procedure.

In 2000 they pass parameters this way in the RDL file. I used

&lt Query>
&lt CommandType> StoredProcedure< /CommandType>
&lt CommandText> =”procGetInvMovement”< /CommandText>
&lt QueryParameters>
&lt QueryParameter Name=”@BegDate”>
&lt Value> =Parameters!pBegDate.Value< /Value>
&lt /QueryParameter>
&lt QueryParameter Name=”@EndDate”>
&lt Value> =Parameters!pEndDate.Value< /Value>
&lt /QueryParameter>
&lt /QueryParameters>
&lt DataSourceName> JLG SQL< /DataSourceName>
&lt /Query>

and in 2005 they do it this way:

&lt Query>
&lt rd:UseGenericDesigner> true< /rd:UseGenericDesigner>
&lt CommandText> =”Execute procGetInvMovement ‘” & Parameters!pBegDate.Value & “‘, ‘” & Parameters!pEndDate.Value & “‘”< /CommandText>
&lt QueryParameters>
&lt QueryParameter Name=”pBegDate”>
&lt Value> =Parameters!pBegDate.Value< /Value>
&lt /QueryParameter>
&lt QueryParameter Name=”pEndDate”>
&lt Value> =Parameters!pEndDate.Value< /Value>
&lt /QueryParameter>
&lt /QueryParameters>
&lt DataSourceName> JLG SQL< /DataSourceName>
&lt /Query>

Notice how they don’t include the parameters in the commandtext tag in 2000

5) Delete the CommandType-tag if you want to use a query

6) In to the 2000 version of the .RDL file. You will need to add this line:
StoredProcedure after the first tag.

7) In the ReportParameters don’t use the tag Hidden

THIS IS NOT SUPPORTED SO I WOULD BACKUP YOUR REPORTS BEFORE ATTEMPTING THIS AND USE THIS ADVICE AT YOUR OWN RISK.

Maintenance Plan in SQL Server 2005

Case
Sometimes things just won't be “so plain to get” as Microsoft thinks it is. I was working at a customer with no database administrator. They needed to clean up there log-file to create free disk space and to create a new back-up every day. So I started browsing about maintenance plans and found a good source.

i The Maintenance Plan Wizard in SQL Server 2005 enables administrators to perform the following maintenance tasks against SharePoint databases:

• Check database integrity
• Reduce a database
• Reorganize an index
• Clean up the history
• Update statistics
• Rebuild an index

We have tested these tasks and the effects that these tasks have on database schema and performance. The following table summarizes the results of these tests.

Task -> Safe to perform this task?

• Check database -> Yes
• Reduce a database -> Yes
• Reorganize an index -> Yes
• Clean up the history -> Yes
• Update statistics -> Yes. However, this task is unnecessary because the SharePoint Timer service performs this task automatically.
• Rebuild an index -> No. The task does not restore existing index options before the rebuild operation. However, you can use scripts that restore index options. Note This problem was corrected in SQL Server 2005 Service Pack 2.

Source: http://support.microsoft.com/kb/932744

Problem
This is the point where Microsoft (or maybe just me?) thinks that things are so easy. I created a new Plan and created all of the below objects:

• Check database integrity
• Create a Full back up
• Reduce a database (should release the log file disk space)
• Update the statistics
• Clean up the history

Problem was…? Somehow the log file entries just wouldn’t be deleted during the shrink task, so no disk space was released! Am I wrong thinking that a Full back up would make it possible to delete log file entries? (You can leave a message at the end of this blog post ;-)

Solution
There was no other option… I asked a database colleague for some tips. With those tips I thought out a plan and created the following maintenance plan.

Now everything works like a charm!!!