Custom Application works in Fat, not on Web

[Wkunneke]

Less than a month from Go Live with 8.10 and here's something that was JUST brought to my attention. A custom application I wrote creates records in 2 custom tables as well as the F0911Z1. This application has been in production for over 2 years without any problems. We wrapped up Fat client testing over a month ago and it worked fine in the Fat client. A group of users are finishing testing for the Web client and it turns out this same application fails to write the records to the F0911Z1.

Fat Client:
F574201.Insert works
F574210.Insert works
F0911Z1.Insert works

Web Client:
F574201.Insert works
F574210.Insert works
F0911Z1.Insert doesn't work ???

I don't get an error message, the record simply NEVER appears in the F0911Z1 ONLY FOR THE WEB client. Any ideas? Any thoughts on how to troubleshoot this?

 

[Frosty the Coder]

If you are using handles, make sure they are all opened, closed as you expect.
I've experienced issues where HTML won't work write if it finds something other than it expects.
Fat client is more tolerant.

As far as debugging, I've used an F55DEBUG table to trace appl flow in HTML.
Yeah, it's an "old dog trick" but it's helped me isolate other screwy web stuff.
I'd suggest setting up a UDC w/the FORM NAME (ie W4210A01) as KY and USERID as SPHD.
This allows me to find the "user specific" issues w/out bogging down all users.
Trigger writing to the F55DEBUG based on existence w/in the UDC.

You maybe able to find something in the JAS log,
but I needed the CNC guy to show me/help me read that mess.

Good luck. Let us know what you find.

Gene

 

[Frosty the Coder]

Sorry, "won't work write" should be "won't work right".
That's an old dog having problems w/homonyms....

 

[Wkunneke]

Thanks for replying...

Not using handles, but thanks for the heads up there. That tidbit will come in handy for the future.

The CNC guy and I looked over the JAS log(s) and couldn't find anything pertinent.

As for your F55DEBUG suggestion, could you explain a bit more? I'm assuming you have a custom table named F55DEBUG that you insert data into as you are troubleshooting, is that correct? Do you mind sharing the basic structure of the table and how you use it? Thanks in advance,

 

[Frosty the Coder]

You're correct that F55DEBUG is custom.
The layout is:
K: USER
K: JOBN
K: PID
K: UPMJ
K: UPMT
K: EDLN
DTAI
DSC1
DSC2
DTA

I use UDC 55/UN (username) to store
KY: W4210A01
DSC1: This is used to debug SO Dtl
DSC2: blank, drivel, whatever
SPHD: GPIEKARSKI

It can have W4210A02 for JOEUSER, W4210A03 for ANNPGMR etc.

W/in Dialog is Init'd I:
Get Audit info for the USERID/JOBN
Select F0005 rows LIKE "W4210A" AND SPHD=Audit_USERID
If I find a hit for this form/user,
I delete any existing F55DEBUG rows for this user/form;
VA frm_F55DEBUG_szUSER = Audit_USERID;
VA frm_F55DEBUG_szJOBN = Audit_JOBN;
VA frm_F55DEBUG_szPID = FORM ID (W4210A).

Peppered (laced, strewn) throughout the APPL are:
If SL_USERID = VA frm_F55DEBUG_USER:
Get Audit Info (Date->VA frm_F55DEBUG_jdUPMJ, Time->VA frm_F55DEBUG_mnUPMT);
VA frm_F55DEBUG_mnEDLN = VA frm_F55DEBUG_mnEDLN + 1
(this prevents dup keys);
VA frm_F55DEBUG_szDTAI = RECA, RIE, DII, PDII whatever;
VA frm_F55DEBUG_szDSC1, szDSC2, szDTA to things I'm looking for (ie FCs, GCs, GBs);
F55DEBUG.Insert.
(ENDIF)

AS SOON AS the user has said, "it just happened",
I turn OFF their 55/UN entry by changing JOEUSER to JOEUSERx.
They can continue w/out destroying their "trace" data.
I manually clear the table every once in a while.

As I said, it's an "old dog" approach (which stinks),
but I'm an "old dog" (which also stinks).
I learned this trick back on S36 (a long time ago, in a galaxy far, far away).

This approach allowed me to recently find an issue where
CUSTOM row is entered code was interupting
CUSTOM row exit and changed asynch code
and stepping on VAs used in both events.

I (truly) regret NOT having a better way to debug HTML.

Good Luck.

Gene

 

[janemcs123]

You may say it's an old dog approach, but this is a great tip. I would suggest putting in the tips and traps.

I'm certainly gonna print this out and try it next time I have an issue.

Thanks for sharing

(As for the issue at hand, I'm sorry I can't add anymore. I've had issues in the past using MBF's to update tables on the portal, but never seen an issue using an insert statement.)

 

[peterbruce]

William and Gene,

I use a variation of Gene's approach too, though I'm not so sure about the "old dog" bit. I also wrote an NER to take care of the common things, I just feed it the diagnostic data and the program id and it does the rest.

The approach is very handy to work out exactly what the UBE, APPL, etc. is doing. It can provide more information than the jdedebug.log.

 

[Frosty the Coder]

By the time I realized that I SHOULD have NER'd it,
I'd already put it into too many places w/in P4210.

If you've read my prev posts regarding P4210,
we've MAIMED it, not mod'd it.

 

[Wkunneke]

Thanks for all the details, I'll post the results when I'm successful in troubleshooting why this has happened.