CommandType changes back to text ALMOST EVERYTIME

When I open a report definition, go to a dataset and open it, the CommandType ALWAYS goes to "Text". I don't want "Text", I want "Stored Procedure". I NEED "Stored Procedure".

I have also found that the CommandText for a different dataset will change even though I have not opened it.

I guess the only solution I have is to open the RDL files, search for the dataset entries and then fix the XML code. This is a real pain in the buttocks when I am working with 300+ reports.

Is there a fix for this bug? Or are you going to FORCE everyone to use "Text"?

I am trying to finish this project so that we can release it to our customers but now I have to wonder why we decided to go with Reporting Services, especially now that we have to do double edits on each and every report.

Steven Broomhead
Optimum Solutions, Inc.

This happened to me with MDX queries.

One thing to try would be to determine why it is happening for some reports and not others. For me it was a carriage return within the RDL file where the query was. Removing this solved the issue.

Try doing a diff on reports that are and aren't experiencing this problem.

Also try using this product instead of visual studio.

http://www.fyireporting.com/

Another thing would be to try using the exec statement before the stored procedure and surrounding the stored proc in brackets, or if you are already doing this try removing the statement.

regards,

Andrew

|||Andrew,

So far it has happened with every report.

If I access any dataset within a report, the CommandType for that dataset will change to Text. It happens every time. If I don't go back and reset it to StoredProcedure, the deployed report expects the call to be a text string not an SP name.

Personally, I like the StoredProcedure CommandType. The Text command with the embedded parameters can get hard to read and debug.

I was hopeful that someone would reply that it was a bug and that there was a hotfix available. I searched but have not had any success to date.

The fyiReporting program looks interesting but our developers need to deploy to a common development server not their local PC. That and the fact I would have to sell my boss on buying software that provides a similar tool to studio (from our MSDN Universal subscription, costing $$$$) because studio has a bug. I don't want that conversation.|||

Steven or anyone,

Has anyone found a fix for this problem! As Steven explains it happens with every report I work on. Even after applying Visual Studio SP1 this bug still exists. It does not leave a warm feeling that this post goes back to Oct 2006 without any MS response.

Scott