Just upgraded to update 110 and it worked fine on my dev machine, but when deployed to the test-server, EPiServer.Data.DataInitialization threw up complaining about duplicates in tblScheduledItem.
The test-server is load balanced with 2 nodes, that might have something to do with it
I got around it by deleting the duplicates but it might be worth looking into if more people should experience it.
Full error: http://pastebin.com/iahvDsc8
"EPiServer.CMS.Core" version="9.8.1" targetFramework="net461" "EPiServer.CMS.UI" version="9.4.4" targetFramework="net461" "EPiServer.CMS.UI.Core" version="9.4.4" targetFramework="net461" "EPiServer.Forms" version="18.104.22.168" targetFramework="net461" "EPiServer.Framework" version="9.8.1" targetFramework="net461"
"EPiServer.CMS.Core" version="9.8.3" targetFramework="net461" "EPiServer.CMS.UI" version="9.5.0" targetFramework="net461" "EPiServer.CMS.UI.Core" version="9.5.0" targetFramework="net461" "EPiServer.Forms" version="22.214.171.124" targetFramework="net461" "EPiServer.Framework" version="9.8.3" targetFramework="net461"
Don't know why, but the jobs in question exists in two languages:
The script in EPiServer.Data.Resources.SqlUpdateScripts.zip\9.8.3.sql doesn't handle more than one entry:
SET @OldId = (SELECT pkID FROM tblScheduledItem WHERE TypeName = 'EPiServer.Notification.NotificationDispatcherJob')
Hi Espen,We are looking into this, could you verify that it's only the NotificationDispatcherJob that has multiple entries and not all job types?
Hi Henrik, thanks for the feedback
NotificationDispatcherJob and NotificationMessageTruncateJob had duplicates, all other jobs were fine.
It's hard to tell exactly when the duplicates appeared though. We usually install every update on this site.
Hi again,We can confirm that the upgrade script fails in this case as it was written with the assumption of a single entry per type and namespace. This script was somewhat ironically added to prevent duplicates of the same job but in different namespaces. We will modify this upgrade script so that it won't fail if there is multiple entries in the database but we have yet to find any reason for why you ended up with multiple entries in the first place. This is also not something that's been reported before. We will keep looking, but if you can think of anything that you have done to cause this state, please let us know.
Hey. I'll of course notify you if I should think of anything that could've caused this. It's hard to tell when it happened since there's no "CreatedDate" type column in the table, so we could pin it to a certain release. I'd have to look through old sql-backups, but that is not easily achieved in the environment in question.