U4-1389 - Add documenttype throws error: There is already an open DataReader associated with this Command which must be closed first.

Created by Joost van den Berg 04 Jan 2013, 08:31:05 Updated by Morten Christensen 19 Jan 2013, 11:17:53

Relates to: U4-1479

[InvalidOperationException: There is already an open DataReader associated with this Command which must be closed first.] System.Data.SqlClient.SqlInternalConnectionTds.ValidateConnectionForExecute(SqlCommand command) +6275731 System.Data.SqlClient.SqlCommand.ValidateCommand(String method, Boolean async) +271 System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method, DbAsyncResult result) +138 System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method) +28 System.Data.SqlClient.SqlCommand.ExecuteReader(CommandBehavior behavior, String method) +256 System.Data.SqlClient.SqlCommand.ExecuteDbDataReader(CommandBehavior behavior) +19 System.Data.Common.DbCommand.System.Data.IDbCommand.ExecuteReader() +23 Umbraco.Core.Persistence.d__1c1.MoveNext() +1074 System.Collections.Generic.List1..ctor(IEnumerable1 collection) +472 System.Linq.Enumerable.ToList(IEnumerable1 source) +80 Umbraco.Core.Persistence.Repositories.TemplateRepository.PerformGet(Int32 id) +206 Umbraco.Core.Persistence.Repositories.RepositoryBase2.Get(TId id) +230 Umbraco.Core.Persistence.Repositories.ContentTypeRepository.<PerformGet>b__0(DocumentTypeDto template) +27 System.Linq.WhereSelectListIterator2.MoveNext() +232 System.Linq.WhereEnumerableIterator`1.MoveNext() +196 umbraco.cms.businesslogic.web.DocumentType.SetupNode(IContentType contentType) +301 umbraco.settings.EditContentTypeNew.Page_Load(Object sender, EventArgs e) +107 System.Web.Util.CalliHelper.EventArgFunctionCaller(IntPtr fp, Object o, Object t, EventArgs e) +25 umbraco.BasePages.BasePage.OnLoad(EventArgs e) +19 System.Web.UI.Control.LoadRecursive() +71 System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +3048

2 Attachments


Richard Soeteman 14 Jan 2013, 08:10:30

I see this error a lot, also with content editing

Dan Booth 14 Jan 2013, 08:46:49

Maybe the devs could check out this thread on SO - http://stackoverflow.com/questions/9511669/cant-figure-out-exception-message/9580253

Morten Christensen 14 Jan 2013, 12:24:12

@Richard when ever you run into this issue again please post the stack trace as it helps a lot to determine where the bug originates.

I have changed a few usages of .Query to .Fetch as it was unnecessary to use the Query method. I'm not entirely sure this is a 100% fix as there is a chance that the legacy SqlHelper has an open connection, which PetaPoco then can't use. But these errors are fairly difficult to reproduce, so we can only rely on reported stack traces at the moment. I'm gonna mark this as fix, but feel free to open it again if the issue occurs again when using the latest nightly - 123 or later.

Rusty Swayne 17 Jan 2013, 03:21:24

This is still happening in Build 130. I have been having trouble renaming a tab in a parent content type and moving properties between tabs (in a parent document type). The db save seems to hang ... clicking the same document type (ex. Base -> make some changes -> click Base) throws the error which "I think" can be seen on content "nodes" that have the Base ContentType in the composition. It clears up pretty quickly so it is hard to say for certain ...

Morten Christensen 18 Jan 2013, 08:25:56

@Rusty Are you seeing the same stack trace as the one posted in the issue? If not it would be great if you could post that as well. From the scenario you write I would have expected the error to be different, but its of course plausible that the issue is the same.

Morten Christensen 18 Jan 2013, 10:37:38

@Rusty I tried to reproduce the issue you described above, but it seems to work fine on a new install, so I'm wondering if this by any chance is an upgrade? Cause we have an outstanding issue with upgrades from v4-v6 and inherited doc types, so maybe your issue is related to that?

Either way here is my scenario using a structure of Base -> Meta -> Article. Only the Article DocType has a template assigned. Both Base and Meta each have a single Tab with a couple of properties. Article has two Tabs with a few properties on each. On the Article DocType I added a property to a Tab from the Meta DocType, and I renamed Tabs on both the Article and Base DocTypes without problems. All changes showed up on the content using the Article DocType.

Rusty Swayne 18 Jan 2013, 20:01:47

Morten - spot on with the v4 to v6 upgrade. We went from 4.11.2 to 6.0.0 Beta.

I thought I did attach a screen shot. It was late and it is probably on my desktop on my box at home. I will check tonight.

We did notice that after the upgrade it appeared that the document type hierarchy was lost (in the UI), but when I checked in the database the relations looked fine and, other than the empty template saving issue U4-1394 (fixed) simply saving the individual document types through the UI and refreshing the document type folder snapped everything into place.

Our scenario

Base -> Text Page

Base had tabs : Content and SEO (with sort order set to 10 so it always comes last)

Text Page had tab : Content

I was reviewing the setup and noticed that one of our designers had added the Content tab to the Base document type and had added two properties. At first I was simply trying to rename "Content" to "Headlines" or something so that I could go through the content and understand what properties were coming from where. I was not able to rename the tab (on the Base document type) so I created a new tab and moved the properties into it and deleted the original Content tab. This worked but moving the properties was really slow.

I have sense decided that neither of the properties should have been added to the Base document type and tried to delete them. One successfully deleted while the other caused a constraint violation. Both properties were simple textstrings. Sorry - this may belong in another issue.

Morten Christensen 18 Jan 2013, 20:56:37

@Rusty Its fine to add it here. I think the issue you are seeing is related to a few different issues. As I mentioned we changed the doc type structure so it uses parent/child relationship for the tree. We fixed the upgrade part of this today. This issue is also related to U4-1479 which we resolved today, and finally the stack trace you posted implies that there is a difference in constraints for the cmsPropertyData / cmsPropertyType tables between a fresh install and an upgraded one, which I have to look into. But I think I've fixed something similar before, so just have to do a bit of investigation.

Rusty Swayne 19 Jan 2013, 00:10:21

Hi Morten,

I just got the open DataReader exception again in Build 135. Hope this helps.

I was adding a new document type and had left the Create matching template checked. Templates are .cshtml views if that helps.

Morten Christensen 19 Jan 2013, 11:17:53

@Rusty You'd probably need nightly build 140 to get the updates affecting this issue. I know its a bit difficult to keep up with all the changes that are currently occurring, but build 135 is from the 17th the day before fixes for U4-1389 and U4-1479 were committed.

Priority: Normal

Type: Bug

State: Fixed

Assignee: Morten Christensen

Difficulty: Normal


Backwards Compatible: True

Fix Submitted:

Affected versions: 6.0.0

Due in version:


Story Points: