P0911Z1 - How does it decide Update or Add Mode?

[eydeak]

Hello List,

I'm running into an issue with P0911Z1 where you select a row from the "Work With" (Find/Browse) form, but the Revisions (Headerless Detail) form is opening in Add Mode.

We have many sources feeding data into the F0911Z1 and we have not encountered this issue before. I'm working on a new data feed, and some of the batches open in Update mode correctly and some of the batches open in Add mode. I've looked at the batches in UTB and the data is there. It is very consistent about which ones it opens and which ones it doesn't. So, I think it must have something to do with the data, but I don't know how JDE is deciding whether to be in Add or Update mode.

I've stepped through the debugger and on both a "good" batch and a "bad" batch, all of the FI values are being populated will valid values. When I continue to step through the "good" batch as it goes into the Revisions form, the SV Form Mode is BOB MODE UPDATE and that value remains as it goes from the Dialog Is Initialized Event to the Post Dialog is Initialized event. When I step through the "bad" batch, in the Revisions Form Dialog is Initialized event SV Form Mode says it is BOB MODE UPDATE, however the next event to fire is Clear Screen Before Add and SV Form Mode changes to BOB MODE ADD.

Has anybody seen this happen before? Any suggestions as to what else I can look at in debug that might help me figure it out?

Thanks,

 

[rlmalott]

The only time I've seen this is when one or more of the primary key columns is blank, zero or null. You may need to do some SQL directly on the tables to see the problem. UTB isn't always good for this kind of problem.

Rob Malott
INRANGE Consulting
a zanett company
5412 Courseview Drive | Suite 122 | Mason, OH 45040 | USA
T: 877 876 3271 | F: 513 573 0790 | M: 513 236 5123
www.inrangeconsulting.com

 

[eydeak]

Okay, I decided to roll up my sleeves and try digging into the debug log to see what the SQL statements looked like and this is where I found my answer.

The EDUS value in the table was TEST12a, when JDE built the where clause for the SQL statement it was looking for EDUS = TEST12A. Because the AS400 does a case sensitive comparison, no matches were found.

From this, I'm surmising the following:

The Select is generated and executed upon completion of the Dialog is Initialized event. If records are found, the form goes into update mode and continues to the Post Dialog is Initialized event. If no records are found, the form goes into Add mode and goes to the Clear Screen Before Add event.

Normally, on our live data, the EDUS value is in all caps, which is why I had never run into this before. I was working with some test data that contained a non-standard EDUS value.

Thanks

 

[BOster]

Good too know. I alwasy just assumed that this was controlled by which button you pressed on the calling form ("Add", "Select", "Copy").

 

[PRABHA19]

As of My Knowledge.........
Upon initially opening a form, a SQL select occurs based on the key values of the form. If a record is retrieved from that select statement, then the form is in Update mode. This generally occurs when data is passed to the form within the form interconnect. If no record is retrieved, then the form is in Add mode. This generally occurs when calling the form without passing data into the form interconnect.

If a corrupt record exists in the table with all blanks/nulls in the key fields, the application will select it upon initially opening the form and put the form into update mode. It will not go into add mode unless no record is found when doing the select. Removing the corrupt record will resolve this potential issue.