"TypeHelper.UrlEncode": this is a very big mistake by AL programmers and I think they should fix it! because this can cause real headaches. Thank you very much Erik, for these lessons and for clarifying this issue for us.
Hi Eric, now where we have got the possibility to return records as well, do you still use the var or do you use the return possibility? What are pros and cons? Maybe working with record return would be a nice topic vor video
Thank you, Erik. I happened to have read the Microsoft document about this and found after that (on the same day) that you shared this video. It was a perfect coincidence. Microsoft should put links to your video in their online documents. BTW, "var" what does it stand for? It's not "variable", is it?
Hi Eric, I think when you first ran the function the value “Hey” in field Address 2 of Vendor 1000 was written to the database and not rolled back when the second Modify errored out. Could that happen without a Commit?
I have seen that when you have multiple modify on the same record for the same table you get this error. Seems like BC does not like multiple modify at the same flow. Like you said MS has never addressed this error.
The documentation says: "For performance reasons all HTTP, JSON, TextBuilder, and XML types are reference types, not value types. Reference types holds a pointer to the data elsewhere in memory, whereas value types store its own data.". Can't find any information about "how" records/codeunits/etc. are passed by value though, is it always like a fresh uninitialized variable or do filters and stuff on the passed-in variable have effect on what the function receives?
Love the rawness of this post. BTW, V = vendor, not customers. Typical late night brain fog I get too.
Did Vendor on purpose to show the weird error message :)
"TypeHelper.UrlEncode": this is a very big mistake by AL programmers and I think they should fix it! because this can cause real headaches.
Thank you very much Erik, for these lessons and for clarifying this issue for us.
Hi Eric, now where we have got the possibility to return records as well, do you still use the var or do you use the return possibility? What are pros and cons? Maybe working with record return would be a nice topic vor video
Thank you, Erik.
I happened to have read the Microsoft document about this and found after that (on the same day) that you shared this video. It was a perfect coincidence. Microsoft should put links to your video in their online documents.
BTW, "var" what does it stand for? It's not "variable", is it?
It does mean "variable" ... That your are not passing "the value" but passing "the variable", aka the address of the variable.
@@Hougaard I see. Thank you for the clarification.
Hi Eric, may I know how you can see base objects from clicking the packages from vscode ?
Install the AL AZ tool extension in VS Code. Check this: ruclips.net/video/HwN0aIJMm5o/видео.html
Hi Eric, I think when you first ran the function the value “Hey” in field Address 2 of Vendor 1000 was written to the database and not rolled back when the second Modify errored out. Could that happen without a Commit?
I have seen that when you have multiple modify on the same record for the same table you get this error. Seems like BC does not like multiple modify at the same flow. Like you said MS has never addressed this error.
It's not a recommed pattern.
The documentation says: "For performance reasons all HTTP, JSON, TextBuilder, and XML types are reference types, not value types. Reference types holds a pointer to the data elsewhere in memory, whereas value types store its own data.". Can't find any information about "how" records/codeunits/etc. are passed by value though, is it always like a fresh uninitialized variable or do filters and stuff on the passed-in variable have effect on what the function receives?
It would properly have been better forcing a "var" in front of them to let the programmer knows what goes on.