Erratic failures after DB upgrade (6.0.58 to 8.0)

Bryan Drenner asked on July 31, 2014 23:53

I previously succeeded in upgrading my web application project (files) and database from 6.0.58 to 8.0. Now I need to deploy the files and upgrade a different CMS database from version 6.0.58 to 8.0. After doing so, I'm getting all kinds of erratic failures.

The steps I took to upgrade the database were simple, but different between the first (successful) and second (unsuccessful) attempts.

The first time, I upgraded the database and files in tandem, following these general steps:

  1. Ran the 7.0 upgrade utility.
  2. Ran the 7.0.34 hotfix utility.
  3. Ran the 8.0 upgrade utility.

The files and database were upgraded together, successfully.

The second time, I just needed to upgrade the database, so I:

  1. Ran upgrade_6_0.sql (from the Kentico 7 upgrade package) on the database.
  2. Ran upgrade_8_0.sql (from the Kentico 8 upgrade package) on the database.

Now the administrative interface reports that it's version 8.0. I can use all of the "apps" that I've tried. However, the actual pages will not render. I pasted some common errors below:

System.FormatException: Input string was not in a correct format.
   at System.Number.StringToNumber(String str, NumberStyles options, NumberBuffer& number, NumberFormatInfo info, Boolean parseDecimal)
   at System.Number.ParseInt32(String s, NumberStyles style, NumberFormatInfo info)
   at System.String.System.IConvertible.ToInt32(IFormatProvider provider)
   at System.Convert.ChangeType(Object value, Type conversionType, IFormatProvider provider)
   at CMS.DataEngine.SimpleDataClass.SetData(Int32 columnIndex, Object value)
   at CMS.DataEngine.SimpleDataClass.LoadData(DataRow dr)
   at CMS.DataEngine.AbstractInfo`1.LoadFromDataRow(DataRow dr)
   at CMS.DocumentEngine.DocumentFieldsInfo.New(String className, DataRow dataRow)
   at CMS.DocumentEngine.TreeNode.LoadFromDataRow(DataRow dr)
   at CMS.DocumentEngine.TreeNode.Initialize(String className, DataRow dataRow, TreeProvider treeProvider)
   at CMS.DocumentEngine.TreeNode.New[NodeType](String className, DataRow dataRow, TreeProvider treeProvider)
   at CMS.DocumentEngine.TreeProvider.SelectSingleNode[NodeType](NodeSelectionParameters parameters)
   at CMS.DocumentEngine.TreeProvider.SelectSingleNode[NodeType](String siteName, String aliasPath, String cultureCode, Boolean combineWithDefaultCulture, String classNames, String where, String orderBy, Int32 maxRelativeLevel, Boolean selectOnlyPublished, String columns)
   at CMS.DocumentEngine.TreeProvider.SelectSingleNode(String siteName, String aliasPath, String cultureCode, Boolean combineWithDefaultCulture, String classNames, String where, String orderBy, Int32 maxRelativeLevel, Boolean selectOnlyPublished, String columns)
   at CMS.DocumentEngine.TreeProvider.SelectSingleNode(Int32 nodeId, String culture, String classNames)
   at CMS.DocumentEngine.DocumentContext.get_CurrentDocument()
   at CMS.DocumentEngine.PageSecurityHelper.CheckPermissions(String siteName, PageInfo pi, Boolean excludeSystem, String relativePath)
   at CMS.DocumentEngine.PageSecurityHelper.CheckPageSecurity(PageInfo pageInfo, SiteNameOnDemand siteName, ViewModeOnDemand viewMode, String relativePath)
   at CMS.URLRewritingEngine.URLRewritingHandlers.CheckSecurity(RequestStatusEnum status, SiteNameOnDemand siteName, ViewModeOnDemand viewMode, String relativePath)
   at CMS.URLRewritingEngine.URLRewritingHandlers.CheckSecurity(Object sender, EventArgs eventArgs)
   at CMS.Base.AbstractHandler.CallEventHandler[TArgs](EventHandler`1 h, TArgs e)
   at CMS.Base.AbstractHandler.Raise[TArgs](String partName, List`1 list, TArgs e, Boolean important)
   at CMS.Base.SimpleHandler`2.RaiseExecute(TArgs e)
   at CMS.Base.SimpleHandler`2.RaiseExecute(TArgs e)
   at CMS.Base.SimpleHandler`2.StartEvent(TArgs e)
   at CMS.Base.ApplicationModule.AcquireRequestState(Object sender, EventArgs e)
   at System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
   at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

Here's another:

System.Exception: [LockObject.EnterRead]: Primary thread didn't provide valid result, the Data property must be explicitly set in order to provide the result to other threads, please review the code.
   at CMS.Base.LockObject.EnterRead[OutputType](OutputType& output)
   at CMS.Helpers.CachedSection`1.EnterLock(TData& result)
   at CMS.Helpers.CachedSection`1..ctor(TData& result, CacheSettings settings)
   at CMS.DocumentEngine.DocumentContext.get_CurrentDocument()
   at CMS.DocumentEngine.PageSecurityHelper.CheckPermissions(String siteName, PageInfo pi, Boolean excludeSystem, String relativePath)
   at CMS.DocumentEngine.PageSecurityHelper.CheckPageSecurity(PageInfo pageInfo, SiteNameOnDemand siteName, ViewModeOnDemand viewMode, String relativePath)
   at CMS.URLRewritingEngine.URLRewritingHandlers.CheckSecurity(RequestStatusEnum status, SiteNameOnDemand siteName, ViewModeOnDemand viewMode, String relativePath)
   at CMS.URLRewritingEngine.URLRewritingHandlers.CheckSecurity(Object sender, EventArgs eventArgs)
   at CMS.Base.AbstractHandler.CallEventHandler[TArgs](EventHandler`1 h, TArgs e)
   at CMS.Base.AbstractHandler.Raise[TArgs](String partName, List`1 list, TArgs e, Boolean important)
   at CMS.Base.SimpleHandler`2.RaiseExecute(TArgs e)
   at CMS.Base.SimpleHandler`2.RaiseExecute(TArgs e)
   at CMS.Base.SimpleHandler`2.StartEvent(TArgs e)
   at CMS.Base.ApplicationModule.AcquireRequestState(Object sender, EventArgs e)
   at System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
   at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

And this error shows up in the Event Log, over and over again:

EventType: E
Source: MacroResolver
EventCode: CHECKSECURITY
UserID: 84
UserName: bdrenner
EventDescription: Security check of the expression 'Rule("!CurrentUser.CheckPrivilegeLevel(UserPrivilegeLevelEnum.GlobalAdmin);", "does not have!0select operationtext0GlobalAdminGlobalAdmin0select leveltext1")|(user)administrator|(hash)1b18c0ae79f22696ec3155661ad589fa10ba2df8d11654bae55ca1eeba57ed6f' didn't pass. The expression was signed by user 'administrator'. Remove the signature and re-save the expression by a user with proper permissions.
EventUrl: /Admin/CMSAdministration.aspx

I'm stumped. What did I do wrong, and how can I successfully upgrade a database from 6.0.58 to 8.0 independently from the files?

Correct Answer

Juraj Ondrus answered on August 1, 2014 13:37

Hi,

One more note that is important - the instructions say to run the site after each upgrade - it has its reason, some additional import to the DB is done and also some code is executed. In your case, it seems that this was missed.

1 votesVote for this answer Unmark Correct answer

Recent Answers


Brenden Kehren answered on August 1, 2014 01:26

The last error relates to your macros not having the correct signature. You can resign your macros in the "System" app under the Macros tab. I suggest resigning all of your macros since your connection string has changed. The initial signature is based on your connection string.

Regarding updating the database separately, did you use the KIM tool at all during any point in your upgrade? If not you will have to download each upgrade separately and extract the sql and run it. Until you have successfully updated your database, I'd suggest not running your site as you could see errors like you're talking about.

If you have a backup copy of your db and code, I'd suggest going back and using the KIM tool simply because it will eliminate a lot of headaches.

3 votesVote for this answer Mark as a Correct answer

Bryan Drenner answered on August 1, 2014 16:50 (last edited on August 1, 2014 16:50)

Thank you, Brenden and Juraj. Some followup questions:

For the sake of discussion, an upgraded Kentico database can be in two states: unfinished (when the site hasn't been run yet) and finished (the site having been run at least once).

  • If my web app. code has already run many times and has finished a database already, and I connect it to an unfinished database, will it automatically finish that database too?

  • After I upgraded to 7.0, I ran the site many times as I corrected problems, so I have several revisions of the code that match 7.0. On Production, are the following steps sufficient?

  • Run upgrade_6_0.sql on the 6.0.58 database.

  • Deploy the latest/last revision of code matching version 7.0.
  • Run the site once.
  • Run upgrade_8_0.sql on the database.
  • Deploy the latest revision of my code, which matches version 8.0.
  • Run the site again.

Or will those latest/last code revisions, having already run many times, fail to finish the newly upgraded database?

  • Will I need to resign macros every time I change the connection string? It's strange that I haven't encountered this issue before. So basically Kentico doesn't support simply changing the connection string in Web.config? And on any new site deployment, you'd have to go in and resign macros?
0 votesVote for this answer Mark as a Correct answer

Bryan Drenner answered on August 1, 2014 17:01

Oh god, the style is the same on both ordered and unordered lists. And I can't delete or edit my post. Sorry my post is hard to read. Here, I'll post a new and revised version:

Thank you, Brenden and Juraj. Some followup questions:

For the sake of discussion, an upgraded Kentico database can be in two states: unfinished (when the site hasn't been run yet) and finished (the site having been run at least once).

  • If my web app. code has already run many times and has finished a database already, and I connect it to an unfinished database, will it automatically finish that database too?

  • After I upgraded to 7.0, I ran the site many times as I corrected problems, so I have several revisions of the code that match 7.0. On Production, are the following steps sufficient?

    (1) Run upgrade_6_0.sql on the 6.0.58 database.

    (2) Deploy the latest/last revision of code matching version 7.0.

    (3) Run the site once.

    (4) Run upgrade_8_0.sql on the database.

    (5) Deploy the latest revision of my code, which matches version 8.0.

    (6) Run the site again.

Or will those latest/last code revisions, having already run many times, fail to finish the newly upgraded database?

  • Will I need to resign macros every time I change the connection string? It's strange that I haven't encountered this issue before. So basically Kentico doesn't support simply changing the connection string in Web.config? And on any new site deployment, you'd have to go in and resign macros?
0 votesVote for this answer Mark as a Correct answer

Juraj Ondrus answered on August 5, 2014 20:01

Hi,

There is a flag telling whether the code was executed or not. From your description I am not sure if you run the site against some other DB, do the code revision and then point the upgraded project files to another DB?

0 votesVote for this answer Mark as a Correct answer

Bryan Drenner answered on August 5, 2014 21:23

Starting with a fully upgraded development environment and code base, here's how I upgraded our published environment from Kentico 6.0.58 to 8.0:

Preparation

(1) Create a deployment package from master (which is at Kentico version 8.0). I'll call it "K8FullyUpgraded.zip".

(2) Check out our last commit at version 6.0.58.

(3) Perform a temporary local deployment from that commit.

(4) Restore a temporary database that matches that commit's Kentico version.

(5) Add the database's connection string to the deployment's Web.config.

(6) Run and verify that the temporary deployment is operational.

Creating upgrade-finishing packages

(7) Run the Kentico 7 Upgrade utility on the deployment and database, letting it overwrite files.

(8) Before running the newly upgraded site, archive the web application root directory as something like "K7UpgradeFinisher.zip".

(9) Run the site, and navigate only to "/CMSSiteManager". Kentico finishes the upgrade.

Note: At this point, the site hasn't been recompiled to include custom code, which would require a lot of manual updating to account for breaking changes.

(10) Verify that the event log shows the upgrade / import events.

(11) Repeat steps 7-10 for the Kentico 8 upgrade. On first run, Kentico finishes the upgrade before rendering any content, so the browser request may take 5-10 minutes.

At this point, you have three deployment archives: one for each newly upgraded Kentico version and one for the fully upgraded application.

Deploying upgrades to target (existing app instance)

(12) Back up the target's root directory and database.

(13) Run the Kentico 7 update's SQL script on the target database.

(14) Deploy the first package, "K7UpgradeFinisher", and update the connection string to the target's database.

(15) Run the deployment and navigate only to "/CMSSiteManager". Kentico finishes the upgrade.

(16) Verify that the event log shows the upgrade / import events.

(17) Repeat steps 13-16 for the Kentico 8 upgrade. Again, the first run may take a few minutes to render.

(18) Deploy the final package, "K8FullyUpgraded", and update its connection string to the target's database.

(19) Run and verify that the site works as expected.

0 votesVote for this answer Mark as a Correct answer

Bryan Drenner answered on August 5, 2014 22:10

I would like to add that Brenden's advice to resign under System > Macros eliminated the last of the errors that I encountered.

0 votesVote for this answer Mark as a Correct answer

   Please, sign in to be able to submit a new answer.