Tag: C/AL

How to: Access timestamp from C/AL

22/03/2018 / NavNab / 0 Comments

How to access timestamp from C/AL? When you Google/Bing this question, you mainly get three answers:

Short answer: you can’t,
Write a SQL query using ADO.NET,
Create a SQL view and use a linked table on NAV,

When Microsoft introduced NAV 2016, we got a fourth answer described in this blog post by Dynamics NAV Team Blog.

Here is my point of view about these solutions:

Solutions 1: is not a solution,
Solution 2: is like you use a hammer to kill a mosquito,
Solution 3: well, this is not a solution too because:
- You have to create a view on your database and this will give some headache when you upgrade…
- You have to consume a table: what if you want to have the timestamp for records from two/three/N tables ? Would you create N dummy views and N linked tables? If it was me, the answer is a big NO.
Solution 4: these is a great and useful improvement but:
- You may have to customize standard tables (add new field of type BigInteger and set property “SQL Timestamp” to Yes)… Yet another customized table you may need to handle during your upgrades 🙁
- What about older versions?

After this short introduction (short?), I get right to the point “here is a fifth solution in three lines of code“:

IF NOT DataTypeManagement.GetRecordRef(_RelatedRecord, RecRef) THEN
EXIT(0);

EVALUATE(timestamp, FORMAT(RecRef.FIELD(0).VALUE));

Want to try it? Here is the fob for Dynamics NAV 2013. In this fob, the function GetTimestamp returns the decimal value for the record’s timestamp.

This solution works for Dynamics NAV 2013 and later. Unfortunately, it does not work for Dynamics NAV 2009 R2 or older.

This blog is available also on Microsoft Dynamics NAV Community

How to calculate Dimension Set ID

19/12/2017 / NavNab / 10 Comments

Starting from Dynamics NAV 2013, dimension’s structure has changed a lot. Since then, a lot of developers struggle to insert or update dimensions pragmatically.

I will not bother you with what was already explained a hundred times in other blogs on how to calculate Dimension Set ID. Better, I will share with you a simple codeunit “SpecDimensionManagement” that will save you time whenever you will need to update dimensions (by update I mean Create, Update, Delete).

In order to use my codeunit, I invite you respect the following example:

WITH SpecDimensionManagement DO BEGIN
// Get Current Dimension Set ID or init a new one
INIT(MyRecord);
// Update my dimensions values
UPDATE(‘DIM1’, ‘VALUE1’);
UPDATE(‘DIM2’, ‘VALUE2’);
UPDATE(‘DIM3’, ‘VALUE3’);
DELETE(‘DIM4’);
DELETE(‘DIM5’);
DELETE(‘DIM6’);
// Calculate my new Dimension Set ID
MyRecord.”Dimension Set ID” := GetDimSetID;
// Get new values if needed
GetCurrDimValues(DimCode, DimValueCode, MyRecord.”Dimension Set ID”);
END;

I put some comments to explain what the functions do.

In the fob, you’ll find codeunit 92600 that handle the calculation and codeunit 92601 where I create some examples for test.

Feel free to contact me if you need more details / informations. Share your ideas and feedback in comment section 🙂

P.S: the fob is from a NAV 2015 FR (Build 49000) database. I test it on NAV 2017 and 2016 also.

This blog is available also on Microsoft Dynamics NAV Community

Text encoding in NAV 2009 R2 Classic Client – Part 2

30/09/2017 / NavNab / 2 Comments

As I already explained in this blog post you can import text files with encoding in Dynamics NAV 2009 R2 Classic Client and old versions.

Today, I will use the same trick to export a text file with encoding (UTF-8 in the example below).

To illustrate this, let’s export all items in a text file from a Russian database. I’ll use three possible solutions:

1- Via dataport:

2- Via codeunit using variable of type File:

3- Via codeunit using variable of type Automation (Stream):

Now, let’s see the results:

We quickly notice that export via dataport or via File variable does not do the job as Russian characters are not exported correctly whereas export via Stream does the job perfectly.

As always, I let you download the objects and files I used in this blog post.

This blog is available also on Microsoft Dynamics NAV Community

Text encoding in NAV 2009 R2 Classic Client – Part 1

18/09/2017 / NavNab / 3 Comments

P.S: If you’re still using Microsoft Dynamics NAV 2009 R2 Classic Client or a previous version, then you may want to continue reading this blog post.

We all know that Microsoft Dynamics NAV 2009 R2 Classis Client supports ANSI only (code page 1252 or depends on your windows localization).

In order to import/export encoded files we usually use some workarounds. In fact, when you google (bing) you will find two main answers:

Ansi-Ascii converter: but you need to add new characters in the codeunit as they come up,
Use some third party tools: but this will create dependency and it will cause a headache to maintain your NAV platform.

The solution I personally prefer is to use “Microsoft ActiveX Data Objects 2.8 Library” automation. In fact, this Dll is available on every windows machine and it offers a an interesting object: Stream.

In order to use it, you need to:

Know your text file encoding,
Check that your OS supports the needed language,
Use a simple code is your NAV:

CREATE(Stream);
Stream.Open;
Stream.Charset(_Charset);
Stream.LoadFromFile(_Path);
Line := Stream.ReadText(1024);
Stream.Close;

Let’s see how this works concretely. In the example below, I will use a Russian Windows Server (change English to Russian):

Then, I will use two Russian text files with different encoding: UTF-8 and IBM855 (OEM 855). Finally, I test all on a NAV 2009 R2 Russian Native Demo Database.

I’ll let you see the results:

Below some comments to understand the results:

Code	Comment
FIL_IBM855	Read a IBM855 encoded file with File variable
FIL_UTF8	Read a UTF-8 encoded file with File variable
IBM_UTF	Read a IBM855 encoded file with Stream automation and wrong Charset = UTF-8
STR_IBM855	Read a IBM855 encoded file with Stream automation and correct Charset = IBM855
STR_UTF8	Read a UTF-8 encoded file with Stream automation and correct Charset = UTF-8
UTF_IBM	Read a UTF-8 encoded file with Stream automation and wrong Charset = IBM855

Finally, I’ll let you download the objects and the files I used in the examples here.

This blog is available also on Microsoft Dynamics NAV Community

My two cents about Try/Catch in C/AL

09/07/2017 / NavNab / 2 Comments

By introducing NAV 2016, Microsoft introduced Try Functions to endow developers with some sort of Try/Catch in C/AL.

The purpose of this blog is not to add another entry to explain how to use Try Functions. José Castro Fernández has already explained this here. The problem with these types of functions is resumed in this sentence from MSDN:

Changes to the database that are made with a try function are not rolled back.

So, inattentive developers may cause some calamities… You know what I mean 😉

Fortunately, Microsoft caught up by the introduction of NAV 2017. It added a new parameter DisableWriteInsideTryFunctions. It is fully documented here.

Okay, this is all good to know but what is the point behind this post?

To answer this question, I will first ask a question 🙂

How can we create a “Try Function” for older versions (5.0 to 2015)?

The answer is simple, and every NAV developer know it (should know it):

IF MyCodeunit.RUN THEN
MESSAGE(‘OK’) // Continue processing…
ELSE
MESSAGE(GETLASTERRORTEXT); // Log the error or display it…

One of the biggest ~~advantages~~ drawbacks to me José is ~~not~~ having to use one new codeunit everytime we need to “trycatch” a process. This can end up consuming a lot of codeunits in some cases. (Yes, I quoted José and I made some modifications 🙂 ).

Here comes the purpose of my post. I would like to share with you a trick I used to use far away before NAV 2016. In fact, I created a Codeunit to centralize all processes that need a “trycatch”. It’s all based on this simple code (of course):

IF TryCatch.RUN(TempParam) THEN
MESSAGE(‘OK’)
ELSE
MESSAGE(GETLASTERRORTEXT);

“TryCatch” is my Codeunit where all the magic happens thanks to my temporary table “TempParam”. All you need to do; is to implement the function you want to “trycatch” inside the “Try/Catch” Codeunit and use it as I show in the “Try/Catch Example” Codeunit. Enough explanations, I believe the Codeunit is simple to understand. I’ll let you try and see by yourselves, download the objects here (fob and txt are from a NAV 2009 R2 database).

Of course, I’ll be glad to answer your questions if needed.

If “TempParam” trick does not suit your need then create your own solution (share it as comment if you want). You can for example create global variables inside “Try/Catch” Codeunit and initialize them by calling a function “InitMyGlobals” before you call TryCatch.RUN.

P.S.: In 2014, Vjeko explained why some sort of Try/Catch may be a big disaster for C/AL world (or at least, if not used wisely).

This blog is available also on Microsoft Dynamics NAV Community

Dynamics NAV Generic SOAP Client

05/12/2016 / NavNab / 16 Comments

Last summer, when I posted my first article I though blogging is very easy, and I’ll post an article every week. Actually, it’s not that easy. Anyway, after few months here is the article, I promised: a 100% generic web service client for NAV.

I was looking for a way to automate all my web service calls without managing, deploying, and struggling with all Dlls generated by Visual Studio. I was hoping to use CU 1290 “SOAP Web Service Request Mgt.” like described here. I quickly noticed that it is not working if the web service comes from another NAV Database (due to SOAP version used natively by NAV). So, I started looking around how Visual Studio generates Dlls I was used to use. I found the answer in this wonderful article from msdn.

This introduction begins to be longer than expected. So, let’s get into the bare bones of the topic.

As you guessed, I tried to translate the msdn article using .NET interoperability in NAV. The result was astonishing. I let you admire the similarities:

The C/AL code remembers me this great article. My first reaction was: What the he**, I’m writing code like the great Vjekoslav Babić.

Now, let me explain how it works. The CU uses four functions:

InitClient: compiles the WSDL on the fly and prepares a ready to use client (proxy, dll… or whatever you want to call it) in memory.
InitCallMethod: prepares the method to call with its parameters.
CallMethod: invokes the method and retrieves the web service result.
GetObjectValue: use the web service result in whatever way you want (result may be simple Text,Decimal… or complex Customer Record…).

Here is an example:

and this is the result:

Enough talking, you can download the code here gws-with-examples.

Some readers may say:

But this needs to compile the client every time; this is huge for the memory.

This is true. The answer will be the subject of one of my next posts.

This blog is available also on Microsoft Dynamics NAV Community