I did a full export from my dev environment, and then tried to import that to my staging environment, but received the following error:
The UPDATE statement conflicted with the FOREIGN KEY constraint "FKcmsPropertyTypecmsPropertyTypeGroup_id".
I'd guess there's a sequencing problem where entries aren't getting created in cmsPropertyType before entries are added to cmsPropertyTypGroup, but I'm not sure how to work around this, given that uSync is doing all the magic.
The logs show:
2018-02-22 11:06:57,017 [P4216/D2/T16] INFO Jumoo.uSync.BackOffice.uSyncApplicationEventHandler - Running uSync Import: Group = default Folder = ~/uSync/data/ Force = False
2018-02-22 11:06:57,017 [P4216/D2/T16] INFO Jumoo.uSync.BackOffice.Logging - Running Import: DataType
2018-02-22 11:06:57,064 [P4216/D2/T16] INFO Jumoo.uSync.BackOffice.Logging - Handler Import Complete: 32 Items 1 changes 0 failures
2018-02-22 11:06:57,064 [P4216/D2/T16] INFO Jumoo.uSync.BackOffice.Logging - Running Import: Template
2018-02-22 11:06:57,064 [P4216/D2/T16] INFO Jumoo.uSync.BackOffice.Logging - Handler Import Complete: 5 Items 0 changes 0 failures
2018-02-22 11:06:57,064 [P4216/D2/T16] INFO Jumoo.uSync.BackOffice.Logging - Running Import: DocumentType
2018-02-22 11:06:57,111 [P4216/D2/T16] INFO umbraco.content - Loading content from database...
2018-02-22 11:06:57,205 [P4216/D2/T16] INFO umbraco.content - Loading content from database...
2018-02-22 11:06:57,283 [P4216/D2/T16] INFO umbraco.content - Loading content from database...
2018-02-22 11:06:57,439 [P4216/D2/T16] ERROR Umbraco.Core.Persistence.UmbracoDatabase - Exception (1778c34c).
System.Data.SqlClient.SqlException (0x80131904): The UPDATE statement conflicted with the FOREIGN KEY constraint "FK_cmsPropertyType_cmsPropertyTypeGroup_id". The conflict occurred in database "GWPublic", table "dbo.cmsPropertyTypeGroup", column 'id'.
The statement has been terminated.
then you should get loads more logging, and hopefully it will tell you which doctype is causing the problem.
I don't think i've seen that specific error, but if the property type was moved from a child doctype to a parent or compositions you 'might' get this error (but that can depend on order that things come in from disk, and usually a second sync fixes it. )
Thanks for the fast and helpful reply Kevin, that pointed me in the right direction. I had deleted a document type in my "Compositions" folder, and then created a new document type in the root by the same name.
I think I may have neglected to delete the uSync/data folder on the target machine before deploying the updates and importing, so there was likely stale uSync data present.
there is a little (and under promoted by me!) setting in the usync config file called preserveAllFiles
<PreserveAllFiles>true</PreserveAllFiles>
if you have this set in the uSyncBackOffice.config file then when you delete something it doesn't actually delete the file, it just puts a blank holder file in its place, meaning it won't accidentally import something that is gone, but not removed from the disk. _its really good for deployment scenarios, but more and more i have found myself leaving it on just to stop me accidentally doing something like that.
Foreign key error on import
I did a full export from my dev environment, and then tried to import that to my staging environment, but received the following error:
The UPDATE statement conflicted with the FOREIGN KEY constraint "FKcmsPropertyTypecmsPropertyTypeGroup_id".
I'd guess there's a sequencing problem where entries aren't getting created in cmsPropertyType before entries are added to cmsPropertyTypGroup, but I'm not sure how to work around this, given that uSync is doing all the magic.
The logs show:
Hi
if you up the logging for uSync to debug (Add the below to log4net.config)
then you should get loads more logging, and hopefully it will tell you which doctype is causing the problem.
I don't think i've seen that specific error, but if the property type was moved from a child doctype to a parent or compositions you 'might' get this error (but that can depend on order that things come in from disk, and usually a second sync fixes it. )
Thanks for the fast and helpful reply Kevin, that pointed me in the right direction. I had deleted a document type in my "Compositions" folder, and then created a new document type in the root by the same name.
I think I may have neglected to delete the uSync/data folder on the target machine before deploying the updates and importing, so there was likely stale uSync data present.
Hi
there is a little (and under promoted by me!) setting in the usync config file called preserveAllFiles
if you have this set in the uSyncBackOffice.config file then when you delete something it doesn't actually delete the file, it just puts a blank holder file in its place, meaning it won't accidentally import something that is gone, but not removed from the disk. _its really good for deployment scenarios, but more and more i have found myself leaving it on just to stop me accidentally doing something like that.
Excellent! I'll give this a try. Thanks again!
is working on a reply...