Try..Catch for .NET Interoperability

  • Post comments:2 Comments
  • Reading time:13 mins read

While it may be a cold day in hell before we see any TRY..CATCH constructs in pure C/AL, we are all far more lucky when it comes to .NET interoperability. In this blog post I’ll (re)present the same concept I demonstrated during NAV TechDays 2013 last year in Antwerp, because I am quite sure this nifty little trick got lost under piles of other posts on this blog.

So, let’s learn how to do try..catch..finally for .NET interoperability C/AL code, using mostly C/AL code.

(more…)

Continue ReadingTry..Catch for .NET Interoperability

How I Reduced Data Upgrade Time By 78 Hours

  • Post comments:36 Comments
  • Reading time:6 mins read

Upgrade projects are lots of fun. They are full of challenges that keep you busy day and night all the time.

I have encountered a very interesting challenge on my last upgrade project. The object upgrade process was completed, the data upgrade procedure ready to go, but when we started first tests we realized that the data upgrade execution takes some 39 hours to complete just Step 1. Without even bothering to measure Step 2, we realized we need to do something about it. The customer is running a 24/7 business, and cannot accommodate for such a large downtime, just to upgrade data from NAV 2009 R2 to NAV 2013 R2.

Eventually, we got it down to under a second. If you want to learn how, read on.

(more…)

Continue ReadingHow I Reduced Data Upgrade Time By 78 Hours

Detecting current object type and ID using some funky .NET Interop

  • Post comments:5 Comments
  • Reading time:9 mins read

Did you ever need to identify the current object type and ID, programmatically, from within the object? For example, detecting the current table ID in a table trigger like this guy? Or current codeunit ID from inside the codeunit?

Why would you need something like this? If you are inside a trigger in, say, table 18, you do know that you are in the table 18, and you can refer to it as 18 or DATABASE::Customer, right? Yes, but this is hardcoding. If you move this code to a different table you’d have to change the hardcoded constant to whatever that other table is.

Microsoft was well aware of the need to know the currently running object ID in some cases, because there is the OBJECTID function to the CurrPage and CurrReport built-in objects. However, for tables, codeunits, XMLports, and queries, there is nothing of the sort.

Now, using .NET Interop, you can easily (well, easy is relative) get this info.

(more…)

Continue ReadingDetecting current object type and ID using some funky .NET Interop

Detect file encoding in C/AL using .NET Interop

  • Post comments:9 Comments
  • Reading time:4 mins read

When importing files using XMLports, and especially when handling text files, file encoding is important. If the XMLport expects ASCII, and you feed it UTF-8, you may get scrambled data. If you have mismatching unicode input files, it may just fail altogether. Therefore, making sure that encoding is correct before you actually start gobbling input files might be important.

At least it was for me. I am currently automating data migration for a major go-live, and I am feeding some 30 input files to NAV, and I want to make sure they are all encoded correctly before I enter a process which would take another geological era to complete.

Detecting encoding is not something that pure C/AL can help you with, so I naturally went the .NET way. My position is that there is nothing a computer can do that .NET cannot. My another position is that there is no problem that I have that nobody before me ever had. Combining these two, we reach a yet another position of mine, that there is nothing that computer can do, of which there is no C# example, and typically I look for those on http://stackoverflow.com/

So, here’s the solution.

(more…)

Continue ReadingDetect file encoding in C/AL using .NET Interop

A .NET Interoperability Lesson: Mapping indexed properties to C/AL

  • Post comments:0 Comments
  • Reading time:9 mins read

Indexed properties are commonly used in C# because they allow a lot of syntactical flexibility, and make the code more readable, and easier to follow. Indexed properties are very similar to C/AL array indexing, except for two important differences:

  • In C/AL, indexer is always 1-based. In C#, indexers are 0-based.
  • In C/AL, indexer is always an integer. In C#, indexers can be any type.

These two examples show these differences:

image

(more…)

Continue ReadingA .NET Interoperability Lesson: Mapping indexed properties to C/AL