1
2
3
4
5
6
7
8
9
10
11
12
13
14

static void JDO_ChangeLanguage(Args _args)
{
    info("@SYS1");
    infolog.language('nl-be'); // Change the language to nl-be
    info("@SYS1");
    infolog.language('fr-be'); // Change the language to fr-be
    info("@SYS1");
    infolog.language('it'); // Change the language to it
    info("@SYS1");
    infolog.language('de'); // Change the language to de
    info("@SYS1");
    infolog.language('en-us'); // Change the language to en-us
    info("@SYS1");
}

And the result is:

Caution: When you use this function make sure you get the current language before you use this function, so you can change it back when you don’t need it any more.

• static TempStr numeralsToTxt(real _num)
• static TempStr numeralsToTxt_EN(real _num)
• static TempStr numeralsToTxt_ES(real _num)
• static TempStr numeralsToTxt_FR(real _num)
• static TempStr numeralsToTxt_NL(real _num)

So you can just use these methods like this:

static void JDO_AmountInWords(Args _args)
{
    info(numeralsToTxt(123456789.12));
}

And you get the following result:

I know these methods aren’t perfect, but they can be a start and save you a lot of programming time.

There are a lot of misunderstandings about what these keywords actually  do. When you use the index keyword in a select statement the kernel will translate this to a order by command and the database optimizer will chose the best index to actually use. When you chose to use the index hint keyword in your select statement, Ax will force the database to use the chosen index.

Now what guideline should you use in writing your select statement? Index / Index hint or should you write nothing and let Ax decide what to do with the query. There are pro’s and con’s for all decisions.
Some people have no trust in the common sense of the developer and say ‘let the database optimizer chose’, it will know what’s best.
Personally I’m a big fan of using the index keyword in all your select statement because you it forces you to think about the indexes that are available on the table or if you should add a extra index to optimize the database-call for your SQL statement. In the end, the database optimizer can chose what the best index is to use.

If anyone has a opinion about this matter, don’t hesitate to comment.

Wen you quickly want to test the same code when it is running on server side, you can simply create a action-menu item from this job and change the property ‘RunOn‘ property to ‘Server‘. Now when you execute the menu item, the job will be executed on server.

Small example to list all tablenames + their corresponding Id.

1
2
3
4
5
6
7
8
9
10

static void JeDoe_listTables(Args _args)
{
    Dictionary  dictionary = new Dictionary();
    int         i;
    ;
    for (i=1 ; i<=dictionary.tableCnt() ; i++)
    {
        info(strfmt('%1;%2', dictionary.tableCnt2Id(i), tableid2name( dictionary.tableCnt2Id(i) )));
    }
}

When you combine this with a DictTable / DictField-object, there are lots of possibilities.

I’ve put a break-point on my postload method and noticed the recId (this.recid of the HRMBenefitType table). This is always the 101090. When I check this in the tablebrowser, this does not match the actual RecId valule.
I checked the SQL-trace-log and noticed the following instruction:

SELECT A.HRMBENEFITTYPEID,A.DESCRIPTION,A.RECVERSION,101090 FROM HRMBENEFITTYPE A WHERE (DATAAREAID=?) ORDER BY A.DATAAREAID,A.HRMBENEFITTYPEID OPTION(FAST 1)

The solution to this problem is simple. Just change the CacheLookup property to EntireTable and the strange behaviour of the RecId-field stops.

The trick is actually simple:

• Create a new variable of the type Boolean en the classDeclaration of the Dialog-class
• Create a public parm method for this new variable to get/set the value
• Extend the wait-method by placing the following code before the close-statement:

  dialogform.formRun().wait(this.parmShowModal());

Now when you make a new instance of the dialog class just set the value of the parmShowModal() to true. From now on this dialog will stay on top.

• When you declare a buffer of a record of temporary table type, the table does not contain any values.
• Memmory and filespace aren’t allocated for a temporary table till the first record is inserted. This means that you have to watch out for client/server problems.
  When the first record is inserted in a buffer on the client tier, the memory is allocated there. All actions (insert / update / delete) to this buffer will run trough that tier, so try to reduce round-trips and improve your performance.
• When you declare 2 different buffers of the same temporary table, they will both have a life of their own. To share the date between the tables use the setTmpData method.
  for example: tmpCommonBuffer1.setTmpData(tmpCommonBuffer2);
• You can’t (normally) set up logging on temporary tables.
• Use the method isTmp() to know if a record is temporary or not (true –> temporary, false –> phisical)

My opinion: Temporary tables are very useful and can help you to easily manipulate data you don’t need store permanently, but watch out where and how you use them.

You can add information to the Infolog by calling:

• Infolog.add(…)
• info(…)
• warning(…) or checkfailed(…)
• error(…)
• You can add some structure in it by using setPrefix(…)
• Using the Proxy-class for the Enterprise Portal

The info(), warning() and error() method are found in the Global class and can contain up to 3 arguments:

• a string (mandatory) : the string that is added to the infolog
• a path to the Axapta Help (optional)
• an Infolog action (optional) : you can use this parameter to initiate a action, for example open the code editor or open a parameter-form when some parameters are missing. Depending on what action you want to trigger, you need to call the right method that extend from sysInfoAction.

1
2
3
4

SysInfoAction   sysInfoAction;
;
sysInfoAction = SysInfoAction_Formrun::newFormname(formstr(HRMParameters));
info("click on me", "", sysInfoAction);

Using the keyword Throw before info(), error() or warning will result in terminating the execution (or jump to catch statement) and a rollback of your transactions.

1

throw error("Something bad happend");

The method setPrefix() will help you to group info(), warning() and error() messages with a header. using setPrefix() will make a indentation for your current block of code (everything between { and }). Leaving the code-block will automatically result in going one indentation back.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

int i;
int j;
;
setPrefix("Testing out setPrefix");
 
for (i=1 ; i<=2 ; i++)
{
	setPrefix(strfmt("Prefix %1", i));
 
	for (j=1 ; j<=3 ; j++)
	{
		info(strfmt("Info %1", j));
	}
}

The checkFailed() method is a warning() method that returns a Boolean (alwais false). U can use this method when you want to display a warning and directly set a return value to false.

1
2
3
4
5
6
7

Boolean ret;
;
if (true)
{
    ret = checkFailed("Something is wrong");
}
return ret;

Note: The infolog can contain maximum 10000 lines. So try to limit the use of it. Building the output of the infolog usually happens at the end of the code you are executing and depending on the number of lines, it can take a while. You can limit the maximum number of lines under a header in a batch by setting the property infolog.errorsPerBatch(#)(). When this number is exceeded only the furst # will appear and Ax will give you a notification that their could be more errors.
It is also possible to update the infolog while executing code by calling the method infolog.viewUpdate().


Using the infolog in the Enterprise Portal:
In the portal you can access the infolog by using the Proxy of the Enterprise Portal.

1
2

using Proxy = Microsoft.Dynamics.Framework.BusinessConnector.Proxy;
Proxy.Info objInfoLog = new Proxy.Info(this.AxSession.AxaptaAdapter);

Now, when you want to write something to the infolog you need to give a Enum with it, so the portal knows if the message you want to show is a info, warning or error. So pass through Proxy.Exception.Info, Proxy.Exception.Warning or Proxy.Exception.Error.

1

objInfoLog.add(Proxy.Exception.Warning, "My warning");

So in short thing you should keep in mind while using the Infolog-class:

• Use short & informative messages
• Choose the righty message level (info, warning, error)
• Use actions, this simple trick is verry usefull for end-users
• Limit the number of messages you send to the Infolog-dialog

Small code example (bad):

1
2
3
4
5
6
7
8
9
10
11
12

DataArea dataArea;
PurchTable purchTable;
;
while select dataArea
where !dataArea.isVirtual
{
    changecompany(dataArea.id)
    {
        select firstonly purchTable;
        info(strfmt("%1 (%2)", purchTable.purchId, purchTable.dataAreaId));
    }
}

The result is:

You can clearly see that the table variable is is known in the company you declared it.

Small code example (good):

1
2
3
4
5
6
7
8
9
10
11
12
13

DataArea dataArea;
PurchTable purchTable;
;
while select dataArea
where !dataArea.isVirtual
{
    changecompany(dataArea.id)
    {
        purchTable = null;
        select firstonly purchTable;
        info(strfmt("%1 (%2)", purchTable.purchId, purchTable.dataAreaId));
    }
}

The result:

So by making this small code change it runs perfectly.

NOTE: When you are calling a new method in the changecompany statement, you don’t have to set all the common variables that you declare  equal to ‘null’. This because they are declared after the companychange.