C/AL will be removed from 2020. NAV 2018 sales stop at Jan 1st

Inga_Simplanova

Directions North America Day 2 has kicked in with information on pricing for Dynamics 365 Business Central on-premise version and new feature announcement. C/AL will be removed from 2020; NAV 2018 sales stop at Jan 1st. More information is here: https://bit.ly/2P8CW0A

Slawek_Guzek

So much for MS promises that BC on prem will continuue as NAV for at least next 5 years...

otk17

but it will be still possible to upgrade from 2009/2017 to 2018?

Miklos_Hollender

BlackTiger wrote: »

There is a time to change profession... Wasted 20 years of my life. MS ruins everything it touches.

I have always wondered if it is possible to ruin NAV. I mean ultimately every product gets outcompeted, nothing lasts forever, but how exactly will it end?

Well, maybe this way. My boss just rejected a CRM project on the basis that he wants to own software, not rent it. He will not be happy if we open a new office in a new country and can only rent ERP.

Inga_Simplanova

The licenses of NAV 2018 will not be sold from January 1st, 2019. So If you buy a license till this date, it might be ok to upgrade to NAV 2018. More facts to know we have put here.

larshaedersdal

Miklos_Hollender wrote: »

BlackTiger wrote: »

There is a time to change profession... Wasted 20 years of my life. MS ruins everything it touches.

I have always wondered if it is possible to ruin NAV. I mean ultimately every product gets outcompeted, nothing lasts forever, but how exactly will it end?

Well, maybe this way. My boss just rejected a CRM project on the basis that he wants to own software, not rent it. He will not be happy if we open a new office in a new country and can only rent ERP.

Are you talking licens or data? You will still be able to run Business Central on-premise with you own licens.

Miklos_Hollender

Data is certainly more important, but on-premise is considered a temporary thing to get customers slowly used to the idea of the cloud. But even in licencing, in the old schema if you stop paying maintenance you can still use the software forever, just have to backmigrate the regulatory updates. Not anymore. If it gets discontinued or the price hiked you have no choice, it is rented, not owned.

Miklos_Hollender

I looked at BC/AL a bit and one very basic thing that makes me wonder is that you don't get to work with files and directories. Today, every evening we have scheduled tasks like import Data.xml and then save it to an archive folder as DateTime_Data.xml.

And I think they cannot allow it - the whole reason they removed .NET method calls was that you don't run amok on the cloud computer that is hosting your app. Safety.

Well, Azure Functions can process files stored as BLOBs. And uploading them with a script is not that hard: https://docs.microsoft.com/en-us/azure/storage/blobs/storage-quickstart-blobs-powershell

But I guess the problem is that for partners who want to exchange files with you it could be still difficult. More difficult than a .cmd file that uploads something to FTP.

Juhl

Just use Azure Files if file access is needed.
Otherwise I always find a way around using files on disk. Use blob and streams etc.

Slawek_Guzek

Miklos_Hollender wrote: »

..in the old schema if you stop paying maintenance you can still use the software forever, just have to backmigrate the regulatory updates. Not anymore. If it gets discontinued or the price hiked you have no choice, it is rented, not owned.

I never liked software as a service concept for exactly that reason.

I have been saying this to various cloud solutions enthusiasts - by putting your data in someone else's software, in someon else's cloud - you are effectively loading a double-barrel shotgun, with a nice elephant-hunting grade cartridge, putting the barrel agains your head, and handlling the gun to the software vendor, nicely asking them to put their finger on gun's trigger. And the bigger the vendor is - the easier he will pull the trigger.

malintus

@Inga_Simplanova I think that is not true. Only for Azure BC there won't be C/AL. In version on-premis C/AL and NAV still be exists (Only NAV will have name BC)

Juhl

No C/AL will be retired. Entire baseapp will be one big extension.

TallyHo

So, if baseapp AL (on premise) can be changed by developer, not a very big change. AL is totally like C/AL, using VS will be the step to take. About time we entered the 21st century.

Slawek_Guzek

TallyHo wrote: »

So, if baseapp AL (on premise) can be changed by developer, not a very big change.

Think about it again.

Hint - how do you fix problems with base NAV now - you change one or maybe few objects and release them into production DB. Now - how do you fix the problem in extension based solution?

Remco_Reinking

Just like you would apply a cumulative update from MS I guess.
Apart from this, we now have function overloading. Would it be possible to use this to overload standard NAV functions, to be replaced with your own?

Slawek_Guzek

Remco_Reinking wrote: »

Apart from this, we now have function overloading.

Could you elaborate what do you mean by we now have function overloading please ?

As far as I know NAV (AL) does not support function overloading, C# does, but AL is not C#. You can call overloaded C# function from C/AL or from AL, but you cannot create overloaded function in C/AL or AL. Or have I missed something somewhere?.

Also overloading does not help in any way to replace functions, it only alows you to have multiple definitions of the same function with different parameters

Juhl

You can overload in AL, by creating multiple functions with the same name but different parameter signature.
But you cant “replace” a call to a standard function from standard code.

TallyHo

Slawek_Guzek wrote: »

TallyHo wrote: »

So, if baseapp AL (on premise) can be changed by developer, not a very big change.

Think about it again.

Hint - how do you fix problems with base NAV now - you change one or maybe few objects and release them into production DB. Now - how do you fix the problem in extension based solution?

If entire std. NAV is an "extension", change the base extension and upload it to your on premise servicetiers.

Slawek_Guzek

Thanks @Juhl

Miklos_Hollender

Slawek_Guzek wrote: »

Miklos_Hollender wrote: »

..in the old schema if you stop paying maintenance you can still use the software forever, just have to backmigrate the regulatory updates. Not anymore. If it gets discontinued or the price hiked you have no choice, it is rented, not owned.

I never liked software as a service concept for exactly that reason.

I have been saying this to various cloud solutions enthusiasts - by putting your data in someone else's software, in someon else's cloud - you are effectively loading a double-barrel shotgun, with a nice elephant-hunting grade cartridge, putting the barrel agains your head, and handlling the gun to the software vendor, nicely asking them to put their finger on gun's trigger. And the bigger the vendor is - the easier he will pull the trigger.

Sure but in Europe there is basically NAV and SAP, nobody else and SAP is moving on the cloud with HANA as well. Everybody is doing it. Even open source Odoo, formerly OpenERP, now has a monthly renting fee, cloud. Formerly open source CRM stuff I researched recently, now on the cloud, monthly rental. We don't really have a lot of choice.

Sure, someone could sense the market gap and release and old fashioned ERP. But let's face it. The reason we are working with NAV is that people want to buy brand name. Microsoft or SAP. If people would buy no brand name software I would have been working with something that has a far more sensible structure than NAV. We are FAR behind the times, both NAV an SAP, a modern architecture like https://wakanda.github.io/ does not even compare. Another example: NAV5 was released in the same year as Ruby on Rails, yet it feels like Rails is a century ahead, technologically. ERP is always a very slow moving technology. No other reason to work with it it instead of the bleeding edge stuff that people want to buy these brand names.

So what choice we have? People only buy brand name in ERP, this is why they can afford to be technologically backwards. SAP, Microsoft, maybe Oracle. We don't really have a lot of choices.

And SAP HANA in the cloud just gives me the same except being far more expensive, big, clumsy, hard to understand, hard to modify.

Inga_Simplanova

Here is the latest news from Directions EMEA 2018 What's new in Dynamics 365 BC Fall release. More information here.

romje

Hi all, I'm a fairly new C/AL developer and I like it but i heard that C/AL will be removed from year 2020. So now I'm in a dilemma if i should continue or change profession asap as an AX developer to at least avoid learning go to waste. I hope you can give me some advice on this. Cheers!

Juhl

Move to AL

MesutG

How to follow a road map in non-supported countries?

BestVayneADC

vscode and AL it's amazing, low learning curve if you have used C/AL before.

Slawek_Guzek

BlackTiger wrote: »

BestVayneADC wrote: »

vscode and AL it's amazing, low learning curve if you have used C/AL before.

Try to develop something bigger than just an adding a new field to a page.

..Or try to fix some MS bug in the existing code. Really amazing, yeah...