SysDictCoder: Intrinsic function weirdness

[Blog bot]

Источник: http://sysdictcoder.com/blog/intrins...ion-weirdness/
==============

Over at Dynamics Ax Daily I found a post about a compile error using tableNum() in a select statement.

As mentioned there, the following code doesn’t compile.

select extCodeTable where extCodeTable.ExtCodeTableId == tableNum(CompanyInfo) join extCodeValueTable where extCodeValueTable.ExtCodeId == extCodeTable.ExtCodeId;

The compiler chokes on the call to tableNum(). I was surprised to see this, as I could have sworn that I have used tableNum() in select statements before. As it turns out it does compile in some cases.

It compiles without the join.

select extCodeTable where extCodeTable.ExtCodeTableId == tableNum(CompanyInfo);

It also works if you add another where clause after tableNum().

select extCodeTable where extCodeTable.ExtCodeTableId == tableNum(CompanyInfo) && extCodeTable.RecId != 0 join extCodeValueTable where extCodeValueTable.ExtCodeId == extCodeTable.ExtCodeId;

And using a non-intrinsic function works too.

select extCodeTable where extCodeTable.ExtCodeTableId == str2int("1234") join extCodeValueTable where extCodeValueTable.ExtCodeId == extCodeTable.ExtCodeId;

This example doesn’t make much sense with regards to business logic but it does compile.

I’m guessing this is a bug in the compiler. As far as I can tell it only fails when you use an intrinsic function before a join clause. Until it’s fixed just use a variable or throw in another where clause to check for RecId != 0. Since all records have a RecId it won’t affect the results you get back. This happens in Ax 4.0 and 2009.

All intrinsic functions are listed on MSDN.



Источник: http://sysdictcoder.com/blog/intrins...ion-weirdness/