A closer look quickly determined there’s NO syntax error, so what’s wrong?
The red line is kinda wide, and using some shift-cursor keys movement showed that this is one character:
But that is two spaces?
Ahh, mystery bug solved. You can paste TAB characters into C/AL, and they stay as tabs, but the compiler does not like them. Typing a tab gets translated into spaces, but not if you paste it in there, it just looks like 2 spaces but stays as one tab, that cannot be compiled.
Ctrl-H can actually search and replace the tabs with spaces, by copy’pasting the tab into the Find What field:
Lots of web service vendors these days are tightening their requirement security protocols, SSL was removed back on the hearthbleed days, and not TLS version 1.0 and 1.1 are getting outed too. So suddenly NAV code that has been working for years stop working unless you change your client to select TLS1.2. Thankfully, there is a simple trick to choose the security protocol used by DotNet. This is done with the ServicePointManager.SecurityProtocol property:
Set it to SecurityProtocol.Tls12
Now you’re talking Tls12 with DotNet from inside NAV.
Wikipedia article on TLS
This happens if you have a table object, saved with a post-GDPR CU (Like NAV2018 CU6), imported that object into a pre-GDPR NAV and then try to export it to TXT from that version. Post-GDPR objects include the DataClassification properties
Make sense? Post-GDPR objects are not compatible with Pre-GDPR NAV CUs.
The solution, do not mix your development environment. Currently, that means that CU2 is the preferred CU for NAV2018 development.
(The quick fix, is the remove the fields, and RETYPE them (Cut’n’Paste will not work).
I’ve seen a couple of explanations about this, but they seemed incomplete, so I did this quick write-up.
This is part of a very old C/Side bug, (or feature might some people from Microsoft argue) where unknown properties are carried along behind the scenes when importing FOB files.