Interesting SqlException

Working with a ReST API that uses Linq to SQL for a DAL.

We have a method that calls a stored procedure that does various SQL statements and does it in a transaction that it either commits or rolls back.

If we called this method 5 times in a row, it would “hang” the api for subsequent calls that did multiple queries. Any call that traversed a relationship and queried the child table would throw this SQL exception:

The server failed to resume the transaction. Desc:#########

The proc that was called returns a table of errors (if any). Our API was never consuming this table.

Thanks to this blog entry, I was enlightened into the need to consume that return table.

Once I consumed the return table, the connections stopped being “stuck” with a transaction context.

Overriding Web Service URL in web.config for Referenced Class Library

I do this so rarely, that I always forget how to do it. Sometimes in a web application, you reference a class library that uses a web service. The web service is not directly added to the web application, so nothing is in the web.config to override, and since it is a class library versus a web application, you need to add a sectionGroup so you won’t throw the yellow screen of death due to an unknown section “applicationSetttings”.

<configSections>

<sectionGroup name="applicationSettings" type="System.Configuration.ApplicationSettingsGroup, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" >
<section name="ErrorHandler.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" />
</sectionGroup>

</configSections>
<applicationSettings>

<ErrorHandler.Properties.Settings>
<setting name="ErrorHandler_ErrorLoggingWebService_ErrorLoggingWebService"
serializeAs="String">
<value>http://localhost/errorloggingwebservice/errorloggingwebservice.asmx</value>
</setting>
</ErrorHandler.Properties.Settings>

</applicationSettings>

 

 

 

 

 

 

 

Report Viewer Auto-Sizing

I was searching for some information on the report viewer control, and accidentally stumbled upon something I always wanted, but could not seem to figure out.

A combination of 2 properties will have the control automatically size itself to fit the entire report:

 AsyncRendering=false SizeToReportContent=true

The AsyncRendering=false changes the rendering to be in-line instead of a frame, which for whatever reason is required for the SizeToReportContent to work.

A noteworthy side-effect of these settings, is that images that have the “sizing” property set to “AutoSize” do not render correctly. They get shifted and cut off. Changing the sizing to FitProportial cured the rendering problem for me. This was not a property I set myself, so AutoSize must be the default.

Report Designer in Visual Studio 2005 – Case Sensitive Fields

If you’ve never worked with the report viewer control and the report designer in VS 2005, you should give it a try if you ever have a need for a reporting services report in your web application. Anyway, a colleague of mine at work was working on a report that I designed a few months earlier. Whenever I setup a reporting services report, I use the smart tag to create a datasource to start my design from. The smart tag will create a dataset which is what the report will in theory be bound to. At runtime, I always manually bind to a dataview that I get from a business layer class, and therefore only make use of the dataset name to tie my business class to the report. So in the method I use to run the report, I do something like this:

ReportDataSource rpds = new ReportDataSource();
rpds.Name = "DataSet1_DataTable1";
rpds.Value = dv;
ReportViewer1.LocalReport.DataSources.Clear();
ReportViewer1.LocalReport.DataSources.Add(rpds);
ReportViewer1.LocalReport.ReportPath = @"MyReport.rdlc";

where “DataSet1_DataTable1” is the name of the dataset / datatable created using the report designer smart tag, and “dv” is the local variable holding a DataView returned by my business class.

Anyway, we had a problem where one of the fields was not displaying on the report. After an hour of scratching our heads, we determined that the field names (columns in the dataview) in the report appear to be case sensitive. Once we had the case of the column name returned by the business class match the case in the dataset, the field would then display on the report. I am not certain if this is a bug with the report designer, or just a strange coicidence that matching the case fixed the problem.