Источник:
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/