Field renaming and subscribers

By now everyone is using or should be using subscribers, so whats there to write about, right? Or at least there should be enough posts out there if something fishy emerges that someone has already written about it. This is no different. I found this problem covered in Punkys blog ( but still i wanted to share my thoughts about it.

So to summarize the problem, if you subscribe to a table field (for example OnAfterValidate) and later someone (or you) renames the field, subscriber will not be updated. Or to be more exact, field onto which you subscribed will not be renamed in the subscriber. Why was i surprised at first? Because, the old-school developer in me is expecting everything to be updated. Why? Because, as we know, every field in the table is uniquely identified by its ID and Name. So renaming a field will simply find the field usage by its ID and rename it properly. Ok, this is not entirely true, but in general this happens (i’ll not go into details why this is not always true).

Lets have a look at this easy example and dig further into this.

This is a simple Test table.


And this is a subscriber:


Lets have a look how the subscriber looks in .txt:


In EventSubscriber line we can see a summary of subscriber properties: EventPublisherObject, EventFunction and EventPublisherElement.

As you notice, table is reffered by ID where field is reffered by its name. No wonder subscriber can’t be updated with new field name as other unique element is missing, field ID. If you think about it, this approach is something Microsoft has already implemented in AL code in VS Code – table fields are reffered by their Name only (credits to Vjeko for pointing this out). So not sure if this will ever be fixed/updated.

Let’s go a step further and see what happens if we rename a table. Seeing how in the subscriber, table ID is used instead of the Name, it should automatically update the subscriber as well. This indeed happens.

How about renumbering the field? Subscriber will work fine. Since the name didn’t change there was nothing to update. There will be other error though that table MetaData is not in sync, so after compiling the object can be used.

So be carefull when renaming a field in a table, you’ll not be warned about the existance of any subscriber related to the field you’re renumbering/renaming.


Exchange Web Services (EWS) – Part 1

So, few months ago I worked on a project where integration with exchange e-mails and calendar was needed so someone mentioned EWS. And here I am. Compelled to write a blog post about it.

So, few months ago I worked on a project where integration with exchange e-mails and calendar was needed so someone mentioned EWS. And here I am. Compelled to write a blog post about it.

Few things to clarify first. Coding was done in NAV2016 and e-mail account is hosted on office365.

After the structure of the whole process was designed, I ended up with rather simple flowchart. One of its components being the authorization part. Obviously, following msdn article about EWS as I never used it before, I started with this:

Initially code looked something like:


If you compare it with msdn article, it’s more or else the same, apart language differences. And look at me using AutodiscoverUrl next to just setting Url property as mentioned as a recommended way of doing it.

But running this will give following error:

A call to Microsoft.Exchange.WebServices.Data.ExchangeService.AutodiscoverUrl failed with this message: Autodiscover blocked a potentially insecure redirection to To allow Autodiscover to follow the redirection, use the AutodiscoverUrl(string, AutodiscoverRedirectionUrlValidationCallback) overload.

Serves me right for trying to be lazy.

Let me fix that quick. What is AutodiscoverRedirectionUrlValidationCallback you ask (or not if you’re experienced EWS developer)?  No idea, but msdn knows:

If you’ve been following vjekos blog on (great site by the way :)) there is a post about limitations of .NET in NAV 2013 ( ) and at place #1 is Delegates. Yes, they are still a problem in NAV2016.

So, the only way to work around this, I need some sort of wrapper class that will use .NET to work with delegates magic instead of NAV code worrying about it. Luckily there is one coming with NAV installation:


Looking at its methods, it seems I don’t have to worry about redirection and I can instantiate it immediately with credentials. But it requires special type called ExchangeCredentials (not WebCredentials used originally).

Looking at the ExchangeCredential class there is a method called op_Implicit which transforms NetworkCredentials into ExchangeCredentials. Or read here for precise terminology: Just what I needed. I hope.


Since this wrapper class can return entire instance as an Exchange Service, I don’t need to instantiate it separately so whole thing can work like this:


And it does. Or does it?

Stay tuned for more EWS goodies on part 2.