Project “Madeira” is ON!

Today Microsoft officially announced Project “Madeira” including a preview. Project “Madeira” is too much to fit into one blog post, so I’ve dedicated a part of my blog to this awesome new offering from Microsoft.

Project Maderia Try Preview

Here are some links:

What is “Project Madeira”

How to sign up for the preview

How to get ready for “Project Maderia”

Upgrade from Quick Books

About Extensions and Eventing

Webinar about “Madeira”

Next week Andrew Good and I will host a webinar about “Madeira”. We will look at the preview and discuss the challanges NAV partners have to onboard this ship. Liberty Grove Software is based in the USA where Microsoft is launching this project.

Register here.

Act quick! We only have room for 100 attendees.


6 thoughts on “Project “Madeira” is ON!

  1. Are there any add-ons currently using extensions?
    This looks to me like the challenge for US partners is it will require low overhead and rapid implementation since a small company paying 500 to 1000 dollars a month is not going to expect a big upfront cost.


    1. Charge Logic is using them, and with Madeira we could for Dynamics TMS and Data Masons because of the new options.

      Madeira is for a new type of NAV Partners like an accountancy firm who already have customer relationships. I don’t think any existing NAV partner will step into this. They could have for the last two years.


  2. Mark – the record size limit of 8K is a NAV restriction – SQL Server allows larger.
    I still think Microsoft needs implement joined tables as an option to keep ISV and partner fields out of the standard tables.
    This could be implemented by prefixes to the field names. e.g MB Bed and Breakfast could be defined as MBBB and so customer fields added by your solution would be MBBB.CustRec.”Hotel Favorite”.
    MBBB would be defined as Mark Brummel’s bed and breakfast for Patterns gurus.

    What do you think of my idea?

    Liked by 1 person

    1. Dave, according to MSDN the max. size for SQL is 8060 bytes.

      I agree on the joined tables but I disagree on prefixes.

      If my add-on has a tablename that Microsoft also introduces in NAV I want to get a heads up warning. For example: If I have a table “Workflow Setup” and merge my code into NAV 2016 I have to functionaly rething about my offering. Autmatical merging is actually dangerous.

      Anyway. Just my opinion. You should off course never implement tables named “Stop”. This is why we have “Do as we say, Don’t do as we do.” 😉


  3. Mark – I don’t think maximum row size is the limit for record size. Now there are some additional restrictions for in-memory OLTP, but that is actual size after compression.
    “SQL Server supports row-overflow storage which enables variable length columns to be pushed off-row. Only a 24-byte root is stored in the main record for variable length columns pushed out of row; because of this, the effective row limit is higher than in previous releases of SQL Server. For more information, see the “Row-Overflow Data Exceeding 8 KB” topic in SQL Server Books Online.”
    Now I believe performance takes a hit when the record size gets very large.

    2008 had a hard limit of 8060, but that was actual size after varchar and others were compressed.


    1. True, but I am not sure we should start using that extensively. It’s like the BLOB which is not stored at the same place as the normal data. Sounds more like a trick for people who have bad design to work around the 8000 byte limit.


Leave a Reply

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

You are commenting using your 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 )

Google+ photo

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

Connecting to %s