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.
Yes, and, sadly, there are no plans to fix this in AX6.
So get used to it 🙂
Too bad. But then again, it is quite obscure. I can understand it’s not a high priority issue.