Learn More





DNN Community Blog

The Community Blog is a personal opinion of community members and by no means the official standpoint of DNN Corp or DNN Platform. This is a place to express personal thoughts about DNNPlatform, the community and its ecosystem. Do you have useful information that you would like to share with the DNN Community in a featured article or blog? If so, please contact .

The use of the Community Blog is covered by our Community Blog Guidelines - please read before commenting or posting.

Workaround for some installations seeing sql timeouts when upgrading or installing modules

Important Note:
This is a configuration change that is designed to resolve an issue introduced in 5.1.1 and resolved in 5.3.0. This should only be considered by users of 5.1.1, 5.1.2, 5.2.0, 5.2.1, 5.2.2 or 5.2.3 , and only if you're experiencing problems with sql timeouts during upgades/module installs.

It's also important that you revert this configuration change with 5.3.0, as the fix introduced in 5.3.0 would cause this to stop working and would cause then cause this to be an issue in 5.3.0 and above.

When under extremely heavy load there is a possibility that Microsoft classes may return "stale" data i.e. the results of an old query rather than the result of the query that was just executed. This is quite a rare case and only exhibits under extreme load or/and insufficent resources. As the error comes from code external to DotNetNuke i.e. somewhere within the .net framework, or the database drivers themselves our options were limited. From 5.1.1 DotNetNuke introduced code to try to mitigate against this by introducing database segmentation i.e all queries that are executed by DotNetNuke have an application name appended to the connection string. This means that "stale" results from other database processes cannot contaminate DotNetNuke data, thus cutting this issue down as much as possible.

Issue and workaround
The drawback to this fix was that it introduced a problem. DotNetNuke supports the concept of installing under one user (the upgradeConnectionString) but running under another (the connectionString) e.g. a site could install/upgrade under a database user with db_owner permissions, but run only one who only had permissions to execute stored procedures. The majority of sites only use 1 user but for certain installations this support for 2 users is important. This issue was introduced when code that compares these strings got out of sync, so to resolve this issue it's possible to define an upgrade connection string that will resolve as the same string as the connection string. As DotNetNuke believes these are both the same there is no need for it to run the optional GrantStoredProceduresPermission and GrantUserDefinedFunctionsPermission functions which can cause the application to be slower than expected during installs/upgrade.

To do this in your install you'll need to take a copy of the value of the SiteSqlServer and append the segmentation string to it e.g. in my install I have the connection strings with values similar to below

 <add key="SiteSqlServer" value="Data Source=(local);Initial Catalog=dnn523;User ID=dotnetnuke;Password=dotnetnuke" />


To workaround the segmentation issue I then location the SqlDataProvider definition. This will have an empty upgradeConnectionbString (see below for an example)

<add name="SqlDataProvider" type="DotNetNuke.Data.SqlDataProvider, DotNetNuke.SqlDataProvider" connectionStringName="SiteSqlServer" upgradeConnectionString="" providerPath="~\Providers\DataProviders\SqlDataProvider\" objectQualifier="" databaseOwner="dbo" />

I now replicate what the DotNetNuke code does by first of all ensuring it ends in a semi-colon ";" and then adding the segmentation string "Application Name=DNNCore;". In my case this will end up as this string.

<add name="SqlDataProvider" type="DotNetNuke.Data.SqlDataProvider, DotNetNuke.SqlDataProvider" connectionStringName="SiteSqlServer" upgradeConnectionString="Data Source=(local);Initial Catalog=dnn523;User ID=dotnetnuke;Password=dotnetnuke;Application Name=DNNCore;" providerPath="~\Providers\DataProviders\SqlDataProvider\" objectQualifier="" databaseOwner="dbo" />

If I now save the web.config and try to do my install/upgrade/module installation, the logic within the code will see the strings as the same and not execute the optional logic, leading to much reduced database time, and cases where timeouts can occur on large installs.



Comment Form

Only registered users may post comments.


2sic Daniel Mettler (124)
Aderson Oliveira (15)
Alec Whittington (11)
Alex Shirley (10)
Andrew Nurse (30)
Anthony Glenwright (5)
Antonio Chagoury (28)
Ash Prasad (21)
Ben Schmidt (1)
Benjamin Hermann (25)
Benoit Sarton (9)
Beth Firebaugh (12)
Bill Walker (36)
Bob Kruger (5)
Brian Dukes (2)
Brice Snow (1)
Bruce Chapman (20)
Bryan Andrews (1)
cathal connolly (55)
Charles Nurse (163)
Chris Hammond (203)
Chris Paterra (55)
Clinton Patterson (28)
Cuong Dang (21)
Daniel Bartholomew (2)
Dave Buckner (2)
David Poindexter (3)
David Rodriguez (2)
Doug Howell (11)
Erik van Ballegoij (30)
Ernst Peter Tamminga (74)
Geoff Barlow (6)
Gifford Watkins (3)
Gilles Le Pigocher (3)
Ian Robinson (7)
Israel Martinez (17)
Jan Blomquist (2)
Jan Jonas (3)
Jaspreet Bhatia (1)
Jenni Merrifield (6)
Joe Brinkman (269)
John Mitchell (1)
Jon Henning (14)
Jonathan Sheely (4)
Jordan Coopersmith (1)
Joseph Craig (2)
Kan Ma (1)
Keivan Beigi (3)
Ken Grierson (10)
Kevin Schreiner (6)
Leigh Pointer (31)
Lorraine Young (60)
Malik Khan (1)
Matthias Schlomann (15)
Mauricio Márquez (5)
Michael Doxsey (7)
Michael Tobisch (3)
Michael Washington (202)
Mike Horton (19)
Mitchel Sellers (28)
Nathan Rover (3)
Navin V Nagiah (14)
Néstor Sánchez (31)
Nik Kalyani (14)
Peter Donker (52)
Philip Beadle (135)
Philipp Becker (4)
Richard Dumas (22)
Robert J Collins (5)
Roger Selwyn (8)
Ruben Lopez (1)
Ryan Martinez (1)
Salar Golestanian (4)
Sanjay Mehrotra (9)
Scott McCulloch (1)
Scott S (11)
Scott Wilkinson (3)
Scott Willhite (97)
Sebastian Leupold (80)
Shaun Walker (237)
Shawn Mehaffie (17)
Stefan Cullmann (12)
Stefan Kamphuis (12)
Steve Fabian (31)
Timo Breumelhof (24)
Tony Henrich (3)
Torsten Weggen (2)
Vicenç Masanas (27)
Vincent Nguyen (3)
Vitaly Kozadayev (6)
Will Morgenweck (37)
Will Strohl (163)
William Severance (5)
Try Evoq
For Free
Start Free Trial
a Demo
See Evoq Live
Need More Information?