How to OMA!

Time for a sneak preview of OMA9.

Did you ever realize that with the upcoming NAV2013 RTC it is probably more difficult for an end user to import a FOB. New users are not used to work with the Classic Client. It would be better if he could import the FOB with the RTC. Or the Web Client, when he is e.g. working at home on a tablet.

This is possible with the new Object Manager which we will demo at the NAV TechDays. See you in Antwerp!

Look at this demo on YouTube!

Oh my! Do I like this new feature of OMA8.5!

In previous versions of the OMA you had to wait like 10 seconds if you opened a part of the OMA that needed up to date where used data. Doing that all day long it was pretty frustrating some times. This is no longer needed. The OMA now installs an SQL trigger that will check the where used data in 100ms. A logic consequence is that the question “Do you want to update the where used objects?” is also no longer needed and therefore made optional in the OMA setup.

Go to the “Administration Tasks” and execute “Add Ask SQL trigger”.

Set the “Update Where Used” to “Always” if you like.

This trick has nothing to do with the OMA but I really want to share it. Did you ever had to search for a COMMIT? The command CONSISTENT can help you with that.
This command is specially build to make sure that at the end of a transaction the G/L Accounts are in balance. In codeunit “Gen. Jnl.-Post Line” you will see the following C/AL statement:

GLEntry.CONSISTENT(
  (BalanceCheckAmount = 0) AND
  (BalanceCheckAmount2 = 0) AND
  (BalanceCheckAddCurrAmount = 0) AND
  (BalanceCheckAddCurrAmount2 = 0));

If you put a COMMIT somewhere is the posting routine after the consistency of the “General Ledger Entry” was set to false you will get the following beautiful error:

So if you have to find a COMMIT someday the only thing you have to do is first set a random table to CONSISTENT(FALSE) and the debugger will bring you to the first COMMIT.

PS: Kudos goes to rmv_RU. This topic was the first time I read about this.

I just read in the blog of Luc van Vugt that the development environment of NAV will be transferred to the RTC.

I think this is great news. The way we have to develop in NAV2013 where the testing and tooling is in the RTC and the developing is done separately in the dev-env is almost unacceptable. Try to run a table and you’ll have to wait 10 seconds till it opens.

I’m very happy that Microsoft is going to put these two worlds back together again. Let’s keep our fingers crossed that we can develop with the same speed in the ‘new’ environment as we did in NAV2009. Or even better, that the ‘new’ environment is just a copy of the current environment. Chances are big it will!!

For the OMA this is also great news. It will just sit and wait in the RTC and wait till everything gets back together like one big happy family.

In my opinion all NAV developers should write code in a way that it’s easy to read for other developers. There is only one way to do that: Stick as close as possible to the coding standards that are described in the “C/AL Programming Guide”.

No Hungarian Notation, no strange indentation or other strange constructions. All these abnormalities makes it hard for others to read.

One tool of the OMA can help you with that. The “Check Guidelines Tool” finds 64 of the most made mistakes. And it even can fix a lot of them. I just ran it over a non customized Cronus database and it found 26.838 coding flaws that can be autocorrected by the OMA. Please NAV Development center in Vedbæk, get of copy of the OMA and use it for only 15 minutes to correct all these flaws.

Let’s take codeunit 6814 EP Encode XML. This one is really bad. It has 577 guidelines errors that can be corrected by the OMA. Please take a look at the picture.

Look at this demo on YouTube!

So, now is your chance to win the new Surface tablet. With Object Manager Advanced 8.5 releasing on July 16th, the product is getting richer and richer in functionality. For the ones who’ve missed it, here is the changes list: http://www.idyn.nl/products/objectmanageradvanced/Version-8-5.aspx

However, we want to hear from you what you would like to see in the Object Manager Advanced. Do you know something that would benefit all partners, is there something missing that would make your life easier? Or maybe it’s just a cool feature that would really fit into the OMA.

You can send your thoughts (1 at a time) to sales@idyn.nl. We will be accepting ideas until July 31st. If your idea is picked as the number 1, you will not only receive the great new Surface Tablet, we also are going to build “your” feature into the product.

Sometimes it’s needed to export a bunch of records to Excel to analyze a problem. If it’s a small amount of data you can copy paste it directly from the table in Excel. But it happens a lot to me that I have to kill NAV after a couple of minutes because this approach takes too much time. Writing a data- or xmlport is then the only option.

Or……. let OMA do this for you!

Run the table from the Object Explorer and choose the format you want to export the data to.

Another little advantage of using this option is that it’s much easier to choose the fields you want to export. If you run a table from the NAV Object Designer you will have to make a click for each field you want to hide.

Look at this demo on YouTube!

Cleaning up old functionality such as unused variables, fields and functions makes your code and objects better readable for other developers but can be risky if you remove too much.

The where used functionality can help you with this task. Let’s take a look at table “BizTalk Reservation Entry”. This table has all the right ingredients for a nice example!

It has 9 unused variables, 1 unused field and 2 unused functions.

With this information you could go to the Object Designer and remove them by hand but it’s also possible to delete them straight in the where used functionality. Simply select the entries you want to delete and press F4.

This can be done with keys, fields, variables and functions.

If a field is removed the OMA will first delete all present data in the table and then will remove the field.

Look at this demo on YouTube!

This week I had to rename a couple of records in a customized table. When I tried to do this I was getting an error like “You cannot rename a blahdieblah”. In a default Cronus database something similar is written in the OnRename trigger of the “Fault Code” table.

In life without OMA you’ll have to export this object as a fob, slash out this line of code, rename the record and import the fob. Or even worse if you’re license doesn’t allow you to modify the object you’ll have to write a report that renames the record.

With the OMA you can open this table in edit mode and rename the record. That’s all.

Please be careful in a live database because the OnRename trigger will not be fired so related tables will not be updated.

Look at this demo on YouTube!

It happens too much that when I show the cool stuff of the Object Manager people begin to jump and shout ‘Wow, didn’t know that!’. I think the best way to share those timesaving tricks is to blog about it.

Let’s start with one that I don’t actually use that much but can come handy when you want to analyze a process where a field gets a wrong value. Let’s say the sales line gets filled with a wrong unit cost and you want to debug that process.

First you go to the where used functionality and open the sales line table. Drill down to the code lines where the unit cost is filled and choose “Set Breakpoint” or F9. Now breakpoints are set on all places where the unit cost is filled in the system.

Start the debugger and add a sales order. You will see that the debugger will stop at every point where the unit cost is filled.

Look at a demo on YouTube!

Look at a demo on YouTube!