Business Central Custom Fields and Default Field Values

by Steve Endow

When you add new fields to an existing Business Central table, what happens?  

What does Business Central do in the database?  How does Business Central handle default field values?  

I didn't know the answers to these questions, so I decided to do a few tests.  For fun, obvs!

To keep things simple, I created a Table Extension object in AL.  I assume this applies to creating custom tables and adding fields to an existing custom table, but I figured a Table Extension would be simpler and easier to test with, and I learned a few more things about table extensions in the process.

Simple Customer Table Extension 

I installed the extension in my BC Docker Container, and then took a look at the modified Customer table.  I went to the Table Information page and searched for Customer. 

Table Information Page

I then clicked on "5" in the No. of Records column.  When I scrolled to the right, I found my custom fields.

Custom Fields from Table Extension

What may not be obvious at this point is that Business Central is choosing a value for the "Allow Nulls" setting on these new fields. This may sound obvious, simply because Table Extensions just work, but if you think about this further, it has some technical implications, and gives us some insight into what BC is doing behind the scenes when it adds new fields to the database.

Notice that the 5 existing customer records have some blank custom field values, while a few have a value.  So the TestCode, TestDate, and TestText fields are blank, but TestInteger, TestGuid, and TestBool fields effectively have a value of 0.

Huh.  

Look at TestDate again.  It's a Date field.  That is blank for existing records.  Blank, like an empty string.

Huh.

So what's going on behind the scenes?  What are the actual properties of the fields that are being created by Business Central for this Table Extension?

Well, let's take a look.

I opened SQL Server Management Studio and connected to the SQL Server instance in my Docker Container.

I then expanded the "default" database, and expanded Tables.  I found two tables with "Customers" in the name, and it turned out the first one had the custom fields for my Table Extension.

Table Extension Fields in Separate Customer Table

Huh.  Look at that.  Instead of attempting to append my custom fields to the real Customer table, Business Central creates another table, effectively also called Customers, to store just the custom fields for my Customer Table Extension.

I can imagine lots of benefits to this design, but can only think a few potential downsides.

If I query the records in this table, I see a row for each existing Customer, and most of the fields have a default value.

Records in Custom Customer Extension Table

That's interesting.

Notice something about the "Columns" listed under the custom Customers table in the prior screen shot?  Notice the words "not null" after each field?

Let's think about what that means.  First, it tells us that Business Central apparently does not allow NULL fields.  This is similar to Dynamics GP, which I worked with for many years--no NULLs allowed.  But I also realized Business Central created a new table with fields that do not allow null values, but it appears to have added new records to that table.  So that tells me that Business Central has provided some default values for the field.

How did it do that?

One way that I'm aware of is to define a default value for the field through the Default Value or Binding field property.

Default Value or Binding is Blank

Business Central does not seem to have used that property--Default Value or Binding is blank for the TestDate field, but we saw that customer records had a value of 1753-01-01 in our TestDate field.

So how did it create records with default field values in fields that do not allow nulls and do not have a default value defined?

My guess is that it used a command like this that provides a default value during creation of the field.

Add Field with Default Value

That doesn't explain the full sequence of steps it must perform to create all of the records in the new custom table, but I am guessing it's one step in the process.  (a topic for a future blog post)

Interestingly, we see that the Date field has a default value of 1753-01-01 (the SQL Server minimum date value), but when we view the contents of the customer table, the TestDate field is blank.  That seems to indicate that Business Central is automatically replacing the minimum date with a blank value in the UI.

If I missed any details about table extensions, custom fields, or custom tables, let me know!

Steve Endow is a Microsoft MVP in Los Angeles.  He works with Dynamics 365 Business Central and related technologies.

You can also find him on Twitter and YouTube, or through these links:  links.steveendow.com