Same problem is happening to me. I've tried increasing all the timeouts in web.config (in the DSN and in <httpRuntime> but it's no help. Adding field types has been slowly getting slower and slower but now it's stopped, and it's a problem.

I'm running Umbraco 4.5.2; will try an update if there's no other suggestions here.

Thanks,

- Andrew

Update - the timeout seems to stem from the versioning process; this site has been up for a while, and we update/republish most content nodes automatically each day with stats from google analytics, thus the number of revisions that use this document type is over 200,000, and I believe that's causing the property insertion to timeout. It also explains why the insertion process has gradually gotten slower.

I'm experimenting with the various techniques (FALM Houskeeping, UnVersion) to see if I can reduce this overhead and get back to a point where I can add new fields.

This seems like something that should be better documented; perhaps I'll take a shot at adding this to the wiki.

Andrew ... did you ever come up with a solution to this? Problem is back again, same thing...

Actually I did, have a look here:

http://our.umbraco.org/forum/using/ui-questions/29586-Incredibly-frustrating-time-adding-properties-on-established-sites

Unfortunately (at least from a hassle and change-management viewpoint) it involves modifying the source and replacing a DLL (just one, cms.dll) that comes with the umbraco core distribution.

But if you're up for that, here's what worked for me: In the file /umbraco/cms/businesslogic/ContentType.cs, in the method 'populatePropertyData', I changed this:

SqlHelper.ExecuteNonQuery(
  "insert into cmsPropertyData (contentNodeId, versionId, propertyTypeId) select contentId, versionId, @propertyTypeId 
  from cmsContent inner join cmsContentVersion on cmsContent.nodeId = cmsContentVersion.contentId 
  where contentType = @contentTypeId",
  SqlHelper.CreateParameter("@propertyTypeId", pt.Id),
  SqlHelper.CreateParameter("@contentTypeId", contentTypeId));

to this:

// sql command
SqlConnection scx = new SqlConnection(ConfigurationManager.AppSettings["umbracoDbDSN"]);
scx.Open();
SqlCommand scm = new SqlCommand();
scm.Connection = scx;
scm.CommandText = @"
    insert into cmsPropertyData (contentNodeId, versionId, propertyTypeId) 
    select contentId, versionId, @propertyTypeId 
    from cmsContent 
    inner join cmsContentVersion on cmsContent.nodeId = cmsContentVersion.contentId 
    where contentType = @contentTypeId          
";
scm.Parameters.AddWithValue("@propertyTypeId", pt.Id);
scm.Parameters.AddWithValue("@contentTypeId", contentTypeId);
scm.ExecuteNonQuery();

...which allowed me to add properties to my nodes successfully (provided you increase the DNS timeout in web.config as mentioned earlier). Apparently ExecuteNonQuery() has some sort of baked-in timeout. As usual YMMV, make backups, try on a development server first, etc.

Hello,

For an Sql server database, it seems for me that SqlHelper.ExecuteNonQuery calls umbraco.DataLayer.SqlHelpers.SqlServer.SqlServerHelper.ExecuteNonQuery

which calls Microsoft.ApplicationBlocks.Data.SqlHelper.ExecuteNonQuery like this :

SH.ExecuteNonQuery(ConnectionString, CommandType.Text, commandText, parameters);

and the code of this last ExecuteNonQuery is :

using (SqlConnection connection = new SqlConnection(connectionString))
      {
        connection.Open();
        return SqlHelper.ExecuteNonQuery(connection, commandType, commandText, commandParameters);
      }

So if you pass a correct timeout in the connection string in the web.config, it should be ok I guess.

@fabrice I tried that:

<add key="umbracoDbDSN" value="server=.\SQLEXPRESS;database=my_db;user id=my_login;password=my_pass;timeout=6000" />

...but it didn't seem to have any impact on timeout of the actual query. This stackoverflow post talks about connection timeout vs. query timeout; I don't know if that's exactly what's going on here but it sounds right:

http://stackoverflow.com/questions/2265733/connection-timeout-property-in-connection-string-ignored

@Andrew, ok thanks I missed that part.

I found a thread that explains the difference between sqlconnection and sqlcommand timeout.

http://stackoverflow.com/questions/847264/what-is-the-difference-between-sqlcommand-commandtimeout-and-sqlconnection-conne

So with Umbraco, you're right,  it seems that doesn't help to much to add a timeout in the connection string because it will just affect the sqlconnection.

Maybe a way would be to add a new key in appSettings, with the CommandTimeout and change umbraco.DataLayer.SqlHelpers.SqlServer.SqlServerHelper.ExecuteNonQuery instead of /umbraco/cms/businesslogic/ContentType.cs, in the method 'populatePropertyData

Maybe we should contact the Umbraco super starts to know what they think about it...

I've literally come up against the same issue now.  So you guys conclude there's no way around it apart from to modify the core?

Just to update this, I found an issue raised for this on codeplex (http://umbraco.codeplex.com/workitem/23075) but for some reason it has been closed.  I'm currently trying to find out why it's been closed when seemingly the issue still affects the latest version of Umbraco.  I'll report back here if/when I find anything but in the meantime a similar thing has been raised as a separate issue on codeplex and it is still open, so please vote for this issue if you'd like to see it fixed.

Thanks ! i'll vote for it :)

Cheers guys, I hit it on a major multi site domain and it's pretty consistent depending upon how much data we are updating. Hopefully it will be fixed for 4.9 (according to Sebastian @cultiv) but it's going to be a hard one for them to debug

Si

Hi Simon,

Curious, have you tried the fix suggested earlier in the thread (http://our.umbraco.org/forum/using/ui-questions/27003-SQL-timing-out-when-adding-a-new-property-to-a-doctype#comment121171).  I did, only I also added an explicit timeout (scm.CommandTimeout = 600) in there too, and it worked for me.  I know it's a core hack, but if we can nail this as the definitive solution then that's a great thing.

Cheers

Hi Dan

Not yet but will be trying it soon, back onto the project with all the issues shortly so will grab 4.7.2 code and recompile it to see if that fixes it - easy for the core team to add if it does

Si

So the umbraco bug tracking has been migrated from Codeplex to YouTrack: http://issues.umbraco.org.  Can anyone spot this issue on YouTrack as I can't (searched for 'sql' and 'timeout' but it didn't come up - perhaps it's tagged as something else)?

Thats an arse, nothing like good communication eh, mind you CG12 was a bit like that. I guess it will need adding again to their other tracker and hope it gets picked up!

I've added this to the issues bug tracker:

http://issues.umbraco.org/issue/U4-276

Vote it up!

Sorry for the confusion, we were planning to migrate the Codeplex issues sooner, but unfortunately ran into problems which I was only able to fix yesterday.

http://issues.umbraco.org/issue/U4-456 is the original Codeplex issue and I've marked the new one as duplicate. :-)

Thanks Sebastiaan.  To add to the confusion, I think the link in your post above should have been http://issues.umbraco.org/issue/U4-623 as http://issues.umbraco.org/issue/U4-456 is something very different.

Whoops, you are absolutely right Dan, must've copied and pasted the wrong one!

No probs - thanks for updating this and pointing us to the right place on the new tracker.

is working on a reply...