I originally reported this on the TechNet site, but one of the moderators asked me to post here. Here's the link to that thread: http://social.technet.microsoft.com/Forums/en-US/sqlreportingservices/thread/a4c54e10-3d59-4d30-8264-bfc250b4cfbe I have a report that has a main report query based off an OLAP cube. It also uses a shared datasource for other queries. There are times when I make a seemingly innocuous change to the report, like adding a border to a table cell, and when I go to preview the change, the report comes back to tell me: [rsInvalidReportDefinition] The report definition is not valid. Details: The report definition element 'ConnectionProperties' is empty at line 13, position 9. It is missing a mandatory child element of type 'DataProvider'. Build complete -- 1 errors, 0 warnings I then have to go into the Datasource Properties window, just opening it and then hitting "OK" to close it again, to reinstate the connection string (even though it shows properly when I open the dialog box). The kicker is that it seems totally random. Sometimes the small change will require this action and other times it doesn't. Version information can be found on the TechNet posting... Thanks in advance for you help. John "A bus station is where a bus stops. A train station is where a train stops. On my desk I have a workstation..."

Hi John, I have searched this issue internal, and I am sure it is not a bug. The issue should be caused by some other applications corrupt the Report Definition while we saving the report. I would suggest you trying the following steps to check if the issue is solved: 1. Disable Anti-Virus(if possible, please uninstall Anti-Virus). 2. Disable other applications or services. 3. Kill unused process. 4. Now, try to save the report again. If you have any more questions, please feel free to ask. Thanks, Jin ChenJin Chen - MSFT

Okay, and how is this not a bug again? It's a consistent, repeatable result that deviates from an expected result; isn't that what constitutes a bug? Your assumption about something interfering with saving the .rdl or corrupting the .rdl on save is incorrect. I don't have to save to exhibit the unexpected behavior/bug. If I open the report, select a cell, go to the properties pane, change the cell borders to something other than what it is set to, and then immediately hit the preview tab, it will throw the error--the connection string (in the xml code, I bet) gets altered. I then have to open the shared datasource's property pane and click OK to recommit the connection string. Just to entertain your theory, I killed all non-essential processes and tried it and it did the same thing."A bus station is where a bus stops. A train station is where a train stops. On my desk I have a workstation..."

I ran a quick test to look at the XML and found something interesting... here is an excerpt from the XML before anything is done. I just opened the report RDL and viewed the code: <DataSources> <DataSource Name="MBSOLAPDataSource"> <DataSourceReference>SalesRepConnectDataSource</DataSourceReference> <rd:DataSourceID>661edb19-b672-478a-a2f4-e96d13188714</rd:DataSourceID> <rd:SecurityType>None</rd:SecurityType> </DataSource> <DataSource Name="AXOLTPDataSource"> <DataSourceReference>AXOLTPDatasource</DataSourceReference> <rd:DataSourceID>5ac14655-852c-47e5-9512-d81dc2f79b24</rd:DataSourceID> <rd:SecurityType>Windows</rd:SecurityType> </DataSource> </DataSources> Now, I selected a cell, added a border, hit the preview tab, it displayed the error, I went back to the design, and viewed the code again... this time I got a VS dialog box that said, "Attempted to read or write protected memory. This is often an indication that other memory is corrupt." When I click OK to close the dialog box, it displays the code. Here is the resulting XML: <DataSources> <DataSource Name="MBSOLAPDataSource"> <DataSourceReference>SalesRepConnectDataSource</DataSourceReference> <rd:DataSourceID>661edb19-b672-478a-a2f4-e96d13188714</rd:DataSourceID> <rd:SecurityType>None</rd:SecurityType> </DataSource> <DataSource Name="AXOLTPDataSource"> <ConnectionProperties> <ConnectString /> <IntegratedSecurity>true</IntegratedSecurity> </ConnectionProperties> <DataSourceReference>AXOLTPDatasource</DataSourceReference> <rd:DataSourceID>5ac14655-852c-47e5-9512-d81dc2f79b24</rd:DataSourceID> <rd:SecurityType>Windows</rd:SecurityType> </DataSource> </DataSources> Notice anything funky around line 8 and 9? Whatever is handling the XML within VS, is errantly inserting a ConnectionProperties and a closing ConnectionString tag. I'd have to call that a bug. Any thoughts? "A bus station is where a bus stops. A train station is where a train stops. On my desk I have a workstation..."

Hi John, From your last reply, the issue seems to be caused by the Business Intelligence Development Studio(BIDS) is trying to change the shared data source to embedded data source. However, I need to the sample report to reproduce the issue. Could you please send me the sample report and sample data sources? MBSOLAPDataSource.rds AXOLTPDataSource.rds <report>.rdl You can send the files to sqltnsp AT microsoft.com (replace AT with @) Thanks, Jin ChenJin Chen - MSFT

This happens to me whenenever I open my project on a different machine, it doesn't save the passwords (when you open the project from a different machine) because of some code-signing 'feature' I think that it's a big though!aaron_kempf

Hey Jin, I emailed the files. The issue seems to be with any report RDL in this reporting project, maybe it's something with the data sources themselves? I don't know. At any rate, whatever mechanism in VS2008 or BIDS that writes out the XML code is injecting bad XML into the RDL whenever the change is made (as opposed to when it's committed/saved). Weird. Thanks in advance for your help. John"A bus station is where a bus stops. A train station is where a train stops. On my desk I have a workstation..."

Hey Aaron, Do you see the same sort of thing happening with the XML code (tags getting written erroneously)?"A bus station is where a bus stops. A train station is where a train stops. On my desk I have a workstation..."

Hi John, I am not able to reproduce the issue due to no sample data. However, I has done research on the RDL, all seems to be fine. Now, could you please help to check the following things: 1. Does the issue happen in all reports? 2. Does the issue happen in all machines with BIDS in your company? 3. Could you please remove datasource "AXOLTPDataSource" reference from the report, and then check if the issue happen? Thanks, Jin ChenJin Chen - MSFT

All reports within this reporting project exhibit this, yes. I'm the only one that uses BIDS for reporting development at this time, so to answer #2, yes. I cannot remove the AXOLTPDataSource from my report and reproduce the issue, that's like asking me to remove the tires on my car to see if that's what's causing the slow leak in my tires."A bus station is where a bus stops. A train station is where a train stops. On my desk I have a workstation..."

I'm running into this issue as well. Furthermore, I am now getting an error when trying to open some reports in the Designer: Warning 1 Deserialization failed: The report definition element 'ConnectionProperties' is empty at line 10, position 8. It is missing a mandatory child element of type 'DataProvider'. Line 10, position 8. Aaron Jarboe -Remember to mark as an answer if this post has helped you.

Hey Aaron, 'Slightly different error than I'm seeing. Does it clear up if you open the datasource properties window and then just hit OK? It seems to rewrite the XML and it removes the bad code injection... in my case anyway. Cheers! John"A bus station is where a bus stops. A train station is where a train stops. On my desk I have a workstation..."

Yes, the error is slightly different, but I've run into both of these errors, so I thought they might be related. For the specific error you mention, I was able to open the shared datasource, CUT the connection string, and hit OK (saving the changes). Then I re-open the datasource and re-paste the connection string and hit OK again, and all would be well. In the case of my error - I had to open up another report in the same report project and copy all the DataSource and ConnectionProperties info in the XML definition file and paste it into the offending report. Upon saving and opening the report in designer view, it started displaying correctly. Aaron Jarboe -Remember to mark as an answer if this post has helped you.

I used to do the same thing (for my error), but I found that all I really needed to do was open the properties window and then "OK" it. It seems to me like whatever component within Visual Studio (or the BIDS add-in) that writes the XML code has a bug that is injecting bad tags. Would you say the same? Maybe the SSAS Team or the Visual Studio Team needs to look into that component?"A bus station is where a bus stops. A train station is where a train stops. On my desk I have a workstation..."

Hi Aaron, Could you please try using ProcessMon to monitor which process is going to modify the report definition? Thanks for your greate help. Jin ChenJin Chen - MSFT

Hi there, I escalate this thread. According to your descriptions, it seems to be a bug. However, to be mentioned, generally, we confirm a bug when we can reproduce it. Here are two suggestions for this thread: 1.Submit a feedback at http://connect.microsoft.com 2. Contact Microsoft Customer Service Support. Thanks, Jin Chen Jin Chen - MSFT

This issue was moved to the Microsoft Connect bug reporting forums: https://connect.microsoft.com/VisualStudio/feedback/details/563605/shared-datasource-connection-string-keeps-getting-wiped-out If you are experiencing similar issues, please vote the thread there as important. Cheers! "A bus station is where a bus stops. A train station is where a train stops. On my desk I have a workstation..."

Hi, Had the same problem, and it was caused by changing to a shared data source. I think I've got a quick fix though, this is what I did: - Close the report - Right click on report, select View Code - For the data source recently changed to shared, change <rd:SecurityType>Windows</rd:SecurityType> to <rd:SecurityType>None</rd:SecurityType> - Save report - Close report Should be fixed when you subsequently open the report.

I also encountered this error. ZincRich's answer above worked perfectly (provided I choose |File| > |Close Solution| first). That allowed me to see the rdl in its XML form rather than opening the editor - since I no longer had the .sln open.

I am experiencing the exact same problem and after reading this full thread, the SIMPLE fix mentioned by ZincRich corrected my problem. It appears to be caused by converting from what I will call a "local/internal to report" datasource to a shared data source. Thanks ZincRich

I can't quite remember if I ever just converted an embedded data source to a shared data source, but that is entirely possible. Thanks for that. I'll pay attention next time. Cheers!"A bus station is where a bus stops. A train station is where a train stops. On my desk I have a workstation..."

Today I got the same error message. As mentioned by ZincRich, I opened the .RDL file in Notepad and deleted the 3 extra lines. After that I am able to preview the report. Thanks Suresh