Developer forum

Forum » Dynamicweb 9.0 Upgrade issues » new constrains on bit types in tables

new constrains on bit types in tables

Frederik Gadegaard

Hello DW, 

Im in the middle of a upgrade progress from DW8 to DW9 and I found out that you have added some more strict constrains to some columns.

In partically 'bit' are not allowed to be null anymore - at least in some places. 

The issue for our solution is that we use the null value indicate no decision has yet been made. For example AccessUserNewsletterAllowed in AccessUser table, we use the null value to indicate that a new user has not yet decided on allowing newsletters. 

So false/true and null gives us this flexibility. 

And there are some other columns aswell that we utilize in this way. 

Do you think your internal code would break if we change these values back to being nullable in the database? 

I would assume the short answer is: make a new custom table with custome columns to accommodate this business need. Time is of the essense though, and this upgrade project is already a bit overdue, and if you could say that you changed these to 'not null' just because it is best practice then we would consider changing them. 

Thank for the help

Kind regards


Nicolai Pedersen

HI Frederik

We have not tested it, so we would not know. You can easily create a custom field (which is supported out of the box) on a user to hold the information instead.

BR Nicolai

Frederik Gadegaard

Hi Nicolai, 

Thank you very much for the reply. 

Im a bit curious of what the reason was that AccessUserNewsletterAllowed changed from nullable to not null?

kind regards

Nicolai Pedersen

Dynamicweb 9 is 5 years ago - cannot answer that. I have nothing in the DW9 branch of source code that can explain the change - maybe if I dig into the old DW8 branches. Maybe your DW8 just has it as nullable column by a custom intervention at that time...

We have introduced consents - and we might have changed something related to that - a more modern and extensive way of keeping track of users that have opted into emails (GDPR and all that).

Smart searches can use AccessUserNewsletterAllowed - and that might have caused wrong results if searching for AccessUserNewsletterAllowed = true|false. So it might be a bug fix.


You must be logged in to post in the forum