InsertAsNewCultureVersion fails unexpectedly with 'File' type field

Brandon Prudent asked on August 1, 2018 18:55

I'm at a bit of an impasse with this method call. For some reason this is failing with a Data Type='File' field. Here is the error I'm getting:

Cannot insert the value NULL into column 'Thumbnail', table 'Kentico.dbo.sologic_blog'; column does not allow nulls. UPDATE fails.

Here is the offending line: handler.DestNode.InsertAsNewCultureVersion(Culture)

Which is pretty straight forward - Kentico believes DestNode.GetValue("Thumbnail") is null for this required field. What is odd is that the value just before executing this line is present, and when the exception dialog comes up the value is null.

I thought perhaps Kentico will not accept two documents having the same GUID for that field, and clears out the data before trying to insert. But even if I copy the attachment using DocumentHelper.AddGroupedAttachment() and give a new GUID value the issue persists. What am I missing to insert a new culture version when a field has a file type?

Correct Answer

Anton Grekhovodov answered on August 2, 2018 13:48

Hi Brandon,
TreeNode.InsertAsNewCultureVersion uses DocumentHelper.InsertAsNewCultureVersion by default. And that method have a parameter of NewCultureDocumentSettings type. Description of the type:

public class NewCultureDocumentSettings : BaseDocumentSettings
    private bool mCreateVersion = true;
    private bool mAllowCheckOut = true;
    private bool mClearAttachmentFields = true;

So, by default your attachment fields are cleared during insert. Try to call DocumentHelper.InsertAsNewCultureVersion and pass to it a correct configuration, example:

DocumentHelper.InsertNewCultureVersion(new NewCultureDocumentSettings
        ClearAttachmentFields = false,
        Node = YourNode,
        Tree = new TreeProvider(MembershipContext.AuthenticatedUser),
        CopyAttachments = true,
        CultureCode = YourCulture
1 votesVote for this answer Unmark Correct answer

Recent Answers

Brenden Kehren answered on August 1, 2018 22:48

Making a "file" field required causes one big problem:

  • When the user adds a file, they cannot remove it

So what you're experiencing could be a result of that, the field was filled out before and your update has no value present for the file field.

Secondly, it could simply be the order in which your're calling the methods. If I remember right, you need to have the file created first, then insert the page/document.

0 votesVote for this answer Mark as a Correct answer

Brandon Prudent answered on August 1, 2018 22:54

Thanks for the response. In this case we aren't worried that the user can not remove the file, though I do appreciate you pointing it out - hadn't considered that before. The field is indeed filled out - how could it suddenly become un-filled out? Also I have made sure the file was created first by copying the binary data and using DocumentHelper.AddAttachment() before the call. It did not change the outcome.

0 votesVote for this answer Mark as a Correct answer

Brenden Kehren answered on August 1, 2018 23:06

So are you adding the attachment, getting the returned value, then updating the document with the returned value/guid? The DocumentHelper.AddAttachment() method states specifically:

"Does not update the document to the database, updates the attachment if currently present."

0 votesVote for this answer Mark as a Correct answer

Brandon Prudent answered on August 1, 2018 23:51

So I've tried it a number of ways. Just now I ran: DocumentHelper.AddAttachment(Node, field, file).AttachmentGUID which surprisingly is giving the same GUID value as before.

Also I think I'm missing the significance of the documentation you've quoted. My expectation is that the Node[field] is getting updated when I do AddAttachment(). Or is this what you mean about since the field is required the value can not be changed? But there must be some way to do it because it works to create a new culture version via the UI.

0 votesVote for this answer Mark as a Correct answer

Brandon Prudent answered on August 2, 2018 16:42

Many thanks - worked perfectly!

0 votesVote for this answer Mark as a Correct answer

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