Wednesday, August 8, 2018

First record in 'RecordInsertList' had incorrect company

We recently had a situation where (Long story short...) the first record from a 'RecordInsertList' was showing the data area id of the batch job it was run under and the other 3 were correctly showing the company from 'changeCompany()'.

Here is the original code (From a 3rd party):

 MyTable myTable;
 RecordInsertList myRecordInsertList;
 myRecordInsertList= new RecordInsertList(myTable.TableId);
 while (myEnumerator.moveNext())
 {
    [Get the company you need]
    changeCompany([company])
    {
      myTable.Field1 = field1
      ....
      myTable.Insert();
    }
 }
 
The first record, in some instances, will have the data area id that doesn't match what you changed it to in 'changeCompany'.  Very interesting.  This was causing some other functionality to fail as it was doing a 'select' on myTable but not cross company.

Here is the solution:

changeCompany([comapny])
{
   myTable = null;
   myTable.Field1 = field1
   ....
   myTable.Insert();
 }

This fixes the problem.  I suspect that the 'mytable.TableId' might be instantiating the myTable buffer 'DataAreaId' and it doesn't ever get corrected.
On top of the above fix, I would also do:

myRecordInsertList = new RecordInsertList(tableNum(MyTable));

I don't know if this would fix the problem (I suspect it would), however, it seems to be a better to handle this.

UPDATE:
After running some tests, I have confirmed that 'tableNum(Mytable)' fixes the issue.  When you do 'myTable.TableID', it instantiates the table buffer with the curExt() in 'dataArea'.  As above, when you continue on to filling the fields in the table, the 'dataArea' is wrong.

I think one could use either myTable = null or myTable.Clear() so long as the 'clear()' method is called after the 'changeCompany()'

Special thanks to Ben for helping me out with this one.

No comments:

Post a Comment