0

I have an import interface (not coded by me) that imports XML data and creates LedgerJournalTable (1) and LedgerJournalTrans (1..n) records.

When handling LJT dimensions, the code first checks that the dimension exists in AX, then inserts the data in the dimension[x] field. However, in the case that the dimension doesn't exist, a warning is shown to the user after the import run ends, but the data is still inserted as is.

And when the user goes to the LJT line after the import is complete, the erronous value is shown in the dimension field. When the lookup/drop-down of this dimension is clicked, the lookup does not open and AX client hangs. Ctrl+break will recover it, but the lookup never opens. You can delete the value, save, and the problem will still persist. You can manually enter an existing value and save, and the problem will still persist. Problem extends to the table browser also.

Any idea why this is happening and how can it be fixed, other than not saving the erronous value in the first place (I have no idea why this is done this way in the first place)?

Thanks in advance.

mrsalonen
  • 343
  • 2
  • 15

2 Answers2

0

Let me know if I'm reading this correctly.

  1. User runs some process to import LJ table/trans records from XML.
  2. If a bad dimension is inside XML, it shoves the data into the LJ trans dimension[x] field even though it's invalid, and presents a warning to user.
  3. User views the journal and sees the bad data and attempts to use the lookup to correct it, but the lookup hangs/crashes.

Seems to me the issue may be that you've been shoving a bunch of bad data into AX and the lookup is trying to use table/edt relations that are invalid.

If I'm right, you need to go to SQL directly and query the ledger trans table and look for any bad dimension data and correct/remove it.

I suspect existing bad data is causing the lookup to fail and not merely whatever bad data you imported and are looking at.

Perhaps what caused the problem is, a user imported bad data, received a warning, ignored warning, clicked "post" as-is (with bad data) and now it's in AX? And now when you do a 2nd import, and try to use the lookup, it's crashing on that bad-data-relation.

Alex Kwitny
  • 11,211
  • 2
  • 49
  • 71
  • You are reading 100% correctly, except the warning user receives comes up only after the import has finished, so it does not even stop there. What gets me here is how the lookup hangs even after the value has been replaced in the LJT form. I think I have to write a correcting job and see if that fixes it, until I can push through some actual code correction (again, not my code, so...). – mrsalonen Apr 06 '20 at 06:06
  • @mrsalonen - Take a test environment that has imported data that contains a bad dimension in a journal...leave that alone for a moment. Manually create a brand new journal, add a line, and see if the lookup hangs. If it hangs, then the existing bad data is getting pulled into the lookup's query. Delete the bad journal, go to the good journal and see if the lookup hangs still. If it does not, you've proven it. If it does, then examine the data in already posted journals for bad dimensions. I suspect you'll find some...delete those entries from SQL and re-test the lookup. Again, in a Test env. – Alex Kwitny Apr 06 '20 at 17:27
  • 1
    @mrsalonen My hunch is the previous Dev had good intentions, allowing the journal to import w/the bad data so the user could follow the warning and correct it. They probably assumed the validation/posting would prevent it from posting (which it may?), but if it doesn't prevent it and a user just ignores the warning, that is probably the issue. The true solution is either make the entire process atomic, or import and skip errored lines (and warn), or import into staging table that does validation before creating the journal. Not...allowing bad data to exist in tables that could get comitted. – Alex Kwitny Apr 06 '20 at 17:30
0

Edited: So, while there was an corruption in the DB, the actual culprit was found: the standard AX code creating temp data for the dimension lookup - there was a mod code in Dimensions.insert() that wrote an XML file every dimensions were updated or inserted. This took so long in this case that it hang up the client. I put the code inside an if clause like so:

if(!this.isTemp())
{
  // offending code
}

Problem solved.

mrsalonen
  • 343
  • 2
  • 15