Understanding "writeOriginOwnerRelationship" method in invenTransOrigin Tables

Please help me to understand the code of the method writeOriginOwnerRelationship in the InventTransOrigin*-Tables like InventTransOriginSalesLine,InventTransOriginPurch Line. In general it is clear to me, that the method gets called from SalesLineType.insert to create the relation between the InventTransOrigin and InventTransOrigin*.

What is not clear to me is the use of try/catch in that method!

try
{
inventTransOriginPurchLine.PurchLineDataAreaId = _purchLineDataAreaId;
inventTransOriginPurchLine.PurchLineInventTransId = _purchLineInventTransId;
inventTransOriginPurchLine.InventTransOrigin = _inventTransOriginId;

inventTransOriginPurchLine.insert();

}
catch (Exception::DuplicateKeyException)
{
if (xSession::lastDuplicateKeyViolatingTable() == inventTransOriginPurchLine)
{
update_recordset inventTransOriginPurchLine
setting InventTransOrigin = _inventTransOriginId
where inventTransOriginPurchLine.PurchLineInventTransId == _purchLineInventTransId
&& inventTransOriginPurchLine.PurchLineDataAreaId == _purchLineDataAreaId
&& inventTransOriginPurchLine.InventTransOrigin != _inventTransOriginId;
}
else
{
t****throw Exception::DuplicateKeyException;
ception
}
infolog.clear(logCount);
}

Question 1: Is there any reason why the original developer does not first check if the record is there, and then do the update instead of using try and catch?

**Question 2:**In some cases when I try to update the Price on the PO Lines , I am getting the error below error

The error message is: “Impossible to create a record in Relation between the purchase order line and the invent trans origin (InventTransOriginPurchLine). Invent Trans Origin: RSA-02483285, RSA-02483285. The recording already exist.”

Note : I am unable to replicate this issue

Question 3: Can you please tell what is the use of this method : xSession::lastDuplicateKeyViolatingTable()

Hi there, I would also like to understand the use of this method. In the past week only we have been randomly been getting the same error in our production environment when posting packing slips for a PO, eg:

“Cannot create a record in Relationship between the purchase order line and the inventory transactions originator (InventTransOriginPurchLine). Inventory transactions originator: PO00046482 Purchase order LOT00549906, LOT00549906. The record already”

We have been using AX 2012 R2 RTM for a year without seeing this error. A month ago we did upgrade to CU7 so I am wondering if it is related (The example PO was created after the CU7 release)

Any knowledge on this would be greatly appreciated.

Hi Nagesha,

I have finally been able to understand this issue and I have created a forum post on customersource with more details: https://community.dynamics.com/ax/f/33/t/160905

Basically what is happening is the infologLine() call in InventTransOriginPurchLine.writeOriginOwnerRelationship() is sometimes returning an incorrect infolog line count which results in the catch exception not removing this error and then displaying it to the user.

As a temporary fix I have replaced this with a call to infolog.line() which is working better. infolog.line() is actually the old deprecated way for getting the infolog line count.

Regards,

Dale

Thank you Dale,

Hi Dale,

Thanks for Valuable reply.

I tried as per your suggestion, but i am getting the below errr

“The Info::line method is obsolete. On the Info class or the infolog global variable, the line method is obsolete. For better performance, use the infologLine method on the Global class.”

Please help me:)

Same here.

https://fix.lcs.dynamics.com/Issue/NotFixed/0?bugId=3626411&qc=86a773c894c2fe0f98f4071647d42e6a

Issue 3626411Return value of infologLine() is sometimes wrong

Product and version

Microsoft Dynamics AX 2012 R3

RESOLUTION

Postponed

PROBLEM

Return value of infologLine() is sometimes incorrect.

REMARKS

Microsoft has evaluated this issue, and will not be issuing a fix at this time.

The discussion concerning infologLine() not returning the right number of records is all great. Nevertheless, it does not help answering this question:

Question 1: Is there any reason why the original developer does not first check if the record is there, and then do the update instead of using try and catch?