Developer forum

Hi Imar

In this case null and false is handled in the same way. Or basically anything not true. Changing to a nullable boolean could cause compatibility to break, so I would rather not. And why would you ever want a null on the bit - it cannot be seen in the UI anyways, and would probably never be handled as a null anywhere, so maybe a list of something would be a better option to make it more explicit that the value can be set or not.

Hi Nicolai,

I am not requesting a change, I think. I am OK with False and null being the same thing. It's just that we're seeing code crash with scenarios like this:

1. I add a field called IsBoolean to the backend for the user (type checkbox)

2. Some custom code updates the user:

user = User.GetUserByID(123);
var testField = user.CustomFieldValues.First(x => x.CustomField.SystemName == "AccessUser_SomeNonBoolField");
testField.Value = "Test";
user.Save();

This code crashes because it tries to send null for the new IsBoolean field. I could set it to false from code, but it's somewhat hard to discover that I need to do that because I am setting a completely unrelated field.

Does that make sense? 

Imar

Thanks, that looks great!

On second thought: shouldn't it do this for other field types as well? DateTimes for example suffer from the same issue...

Hi,

I've a solution recently upgraded to 8.9.2.14 that started to give an error when saving a new user:

Cannot set Column 'AccessUser_DefaultExpDate' to be null. Please use DBNull instead

The field is a custom field for the solution and with the previous version (8.8.1.13) no error has generated when saving the new user.

Can this be the same issue?

BR,

Rui Silva

Hi Rui

I've send this to QA for verification and re-opening if it is the same issue.

Hi Rui,

I've checked my test environment based on DW8.9.2.14 with regular way to add new user and was not able to catch an exception, I use user custom field of all available types - https://www.screencast.com/t/CTdNAuuf91

Besides, I've tried to downgrade my solution to 8.9.2.13, add new custom field type of Date/DateTime, move back to 8.9.2.14 and perform the adding again - the same result is. 

So, please, comment if you use other way and conditions are different against mine.

BR, Oleg QA

I’ve check it deeper and the exception I’ve mentioned is throwed when my code calls the Save method from the API for a new Group object (not a User sorry).

I mentioned the user custom field because the field name is from the AccessUser table, and since both types of objects shared the same table that lead me to the misdirection.

Hi Rui,

I was able to reproduce the bug on DW892 on creating new user during checkout. So, new separate TFS42060 has been created to fix 892, will be provided with further hotfix soon. Thanks.

BR, Oleg QA 

Hi

The problem TFS#42060 "Error exception on user creating in checkout on DW89" has now been fixed in version 8.9.2.15

You are able to find this build in the download section:

http://doc.dynamicweb.com/releases-and-downloads/releases

Please contact Dynamicweb Support if you need any additional help regarding this.

Kind Regards
Dynamicweb Support
Kristian Kirkholt