Enum != SchemaChange

The biggest showstopper we had in the old days with C/Side to separate code was the option field. Option fields are often where modules get together and programmers make switches in the code about which business logic to execute.

This is fixed now with the enum, and it will be even better in the next spring release with the interface implementations.

But before you can execute on that you have to change the Option field into an Enum. And yes, this means changing a field type.

Changing field types is not allowed in AL when you run on AppSource. You have to obsolete the field and introduce a new field.

You can imagine that this makes implementing this feature incredibly complex right?

The day before yesterday’s meeting however I sat down with Michael at our office in Horsholm to see if we needed to make changes to the ForNAV product in order to implement Enum support.

Imagine how surprised we were when we noticed that the FieldType::Enum did not exist.

And we did some testing and it looked as if an Enum field returns FieldType::Option.

I tweeted to #BCAlHelp and got no logical answer.

So I decided to save this question for my meeting with Microsoft, also because one of our team members, Cristina Nicolàs identified the schema change as a project risk.

At Microsoft I was happy to learn that this is all by design. Someone smart at Microsoft must have realised that since at SQL Server level this is always an Integer anyway it would only make sense to allow this flipping without making a breaking change.

The Test!

Off course I had to test this in order to blog about it.

I have created a simple table with an option field and published this to a Sandbox.

Next I change it to this

And yes, I can publish this without getting errors.

Enums will come in next Spring Release!

All of the teams in our project of splitting up the base app implemented their own Enum’s because last Fall release was shipped without it.

We were happily surprised to hear that Microsoft has implemented the Enum in the usual suspected places and they are expected in the next Spring release.

I’ve been told, but I did not yet have time to confirm this, that the Insider Docker build already as this code. The compiler of this Docker image also allows you to play around with Interface objects.


Again, thanks to everyone to make this possible and transparent. Thanks to the Base App split team and thanks to Jesper and Bugsy at Microsoft,

7 thoughts on “Enum != SchemaChange

  1. Hans H. Fiddelke

    Mark can you please explain an ENUM solution for the following scenario:

    Given: Two extensions for SalesLine from different vendors,
    1. Called OptionalItems which extends Type by the option value OptionalItem. This option should allow to add an optional item which is handled like an item in most cases except it is not included in Document sums, and it is not transfered to Warehouse.
    2. Called ExtendedTexts. This extension allows to add texts for specific documents (Shipment,Invoice, Warehouse) from standard texts which are connected to the item, glaccount or ressource.

    As OptionalItem is/should be handled as normal Item in most cases, also for the ExtendedTexts, because the optional item may become a normal Item.
    How can we handle this without a compatibility app?
    And where does this end, when we have multiple of souch depending apps?

    And please describe a solution for this scenario, it is an example. There might be other solutions for this case, but there might be also scenarios where anonther solution is not available. (f.e. fixed assets)


    1. Hans H. Fiddelke

      Do you have a solution for that scenario above?

      Normaly i would also agree, but only as a replacement for Code- Fields with lookup to a (Code,Description- Table). Other usage may cause severe harm to your ERP- system if you are using multiple extensions (or a splitted base app)

      There is a general problem with concurrent apps, accessing the same data for which we currently have no solution in BC. And if this is not solved, there will be never a stable complete solution as we and our customers expect.
      In my opinion there is no possible solution for this, except doing it the old way.
      But please convince me from the opposite.


  2. Hans H. Fiddelke

    Any ideas on the scenario?

    BTW: I am not complaing about problems. I try to identify the key issues, that need to be solved before we can go on. And if we can’t solve them, we should stop here.
    You would not design the exterieur and interieur for a real car without wheels, if you don’t know how to move the car foreward and the technical requirments for that. And if these requirements are not realizable, you would/should stop your design.


  3. Hans H. Fiddelke

    Another key issue for extended enums: How do you extend tooltips? Or will we see only the very helpfull message “Here you can enter a Type” in SalesLine.Type in the future.
    A solution would have been to define default tooltips at the base (field,enum.value) but that is another thing.



Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.