Enum != SchemaChange

I love a nerdy title and I love learning about cool new smart stuff.

But before you continue reading I want to say thanks to my colleagues at ForNAV, especially Michael Nielsen. Without him pushing me (again) to step out of my comfort zone this would not have been possible.

Yesterday I visited the Microsoft office in Lyngby for the first time in a very, very long time to talk about our project to split up the base app. We also talked about something else, but that will be another blog. (Soon…).

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)

    Like

    Reply
    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.

      Like

      Reply
  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.

    Like

    Reply
  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.

    Like

    Reply

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.