Help - Custom code works in DV but NOT in PY environment..

[RaghuBabu]

SO Entry program - Added custom code to write data to temp table and then to update F4211 in OK Post Button event on SO Detail Revision form. Custom code works in DV on both fat client and citrix client. Code does NOT work in PY environment but if I open ER debugger on fat client (PY) to view step by step execution, the code works fine.

We built full packages twice and deployed, Tried removing grid tabs on SO detail revision screen but still NO LUCK ... Any help would be appreciated.


Raghu
XE NT SQL2K

 

[peterbruce]

Raghu,

[ QUOTE ]
... if I open ER debugger on fat client (PY) to view step by step execution, the code works fine.

[/ QUOTE ]

What you describe is typical of an a synchronous problem. Something running asynchronously is not completing in an appropriate time, but when run with the debugger, it is "forced" to run synchonously and then works.

Check to see what is called asynchronously and change it to be synchronous.

 

[RaghuBabu]

Thanks for your response Peter.

But the code works fine in DV on both thin and fat clients. Would it still be that issue?

Raghu
XE NT SQL2K

 

[Zoltan_Gyimesi]

Hi Raghu,

I suppose, Peter already have given the key to you.
Please, check the archives of JDEList - this type of issue had been discussed dozens and dozens times.

Please, come back here to help you - if you wasn't able to solve your issue. That time, let us know more detals - on which event, where, etc. text dump of the ER woud be usefull for us to help you.

Waiting for yor update & Regards,

Zoltán

 

[Zaki Ahmed]

Instead of putting your code in SO entry application, do all your logic in an NER and call that NER from SO MBF End Doc. This way, even though MBF will be running asynch, but your custom logic won't kick off until all the standard MBF logic finish.

 

[Zoltan_Gyimesi]

Hi Raghu,

As far as we do not know the details, hard to help you.
Let me suppose, you add your logic to the OK Button Clicked -Asynch event. Am I right?

If yes, you has two way:

#1.
(The dirty one) Kick OFF Asynch execution on all BSFN in this event and calls and put your custom logic to the end of this event
#2.
(The better one) Create a BSN for the update, place it after the latest BSFN call, call it ASYNCH an INCLUDE Transaction option.

You can read more about this issue on JDEList.

Regards

Zoltán

 

[RaghuBabu]

Thank you all for your responses.

We have similar working code added by a consultant (using custom table) 8 years ago to update F4211 User reserved fields. Since an extra field is NOT available in that custom table, I came up with another custom table to update two more F4211 fields.

At the end of FORM's OK POST BUTTON CLICKED, I am using Table IO operations to udpate F4211 table. My code is exactly similar to old custom code which has been working for years.

I will search JDELIST archives for some helpful information and am also thinking of two more options:

Option #1 - Use custom table (added by consultant) by adding required extra fields and remove the table I created.
Option #2 - Write BSFN as you guys suggested and add it at the end of OK POST BUTTON clicked event.

A screenshot of the custom code is attached to the post.

Thank you
Raghu
XE NT SQL2K

 

[peterbruce]

Raghu,

The behaviour you describe is typical of an asynchronous problem. Why it would occur in PY and not in DV, if it is in fact an asynchronous problem, is highly subjective. Asynchronous problems can also be intermittent.

I'll try to explain how an asynchronous problem would produce the behaviour you are experiencing. Remember that this is supposition and may not be the cause of your problem, but the information you have provided leads me to believe that it is a strong possibility. You will need to investigate to see.

The asynchronous problem detail revolves around two processing threads running independently of each other, but what one process (as opposed to the thread it runs on) does depends on the results of the other process.

Say two process threads are running asynchronously, but process 1 depends on the results of process 2. The two processes may be run asynchronously for performance reasons. If process 1 completes before process 2 the results process 1 needs from process 2 are not available and an error occurs. Under normal circumstances process 2 would finish first, but if changes are made that indirectly effect the time process 2 takes to complete, process 2 may take longer to complete. Now if there are two changes that are made, each change individually may not delay process 2 enough for it to complete after process 1, but both together may.

This is the possibility that may be happening in your situation. The two changes (between the unaltered application running in DV and the altered application running in PY) are (1) the event rules you have added and (2) the different environment. PY probably has a lot more data than DV and this may slow down some processing running in PY compared to the same process running in DV. However the extra data may not slow down a process enough to cause an error. But, if event rules are added, the two changes together may slow down processing enough to cause an error.

 

[peterbruce]

Raghu,

You never said what the error was or what happened that should not or did not happen that should. All you said was that it didn't work. Please post any error information and details of what happened or did not happen.

 

[RaghuBabu]

Peter,

NO ERRORS Occured. What I am trying to do is:
Allow user to enter a value in GC Customer PO field and when he/she clicks on OK BUTTON, the value should be written to F4211 VR01 field. The code works in DEBUG mode and As you said in your earliest post, it should be working because of Synchronous mode.
I noticed the F4211 End Document is called with ASYNCHRONOUS option turned ON. If i turn it OFF, would that create any other issues?

Thank you,
Raghu
XE NT SQL2K

 

[peterbruce]

Raghu,

In most circumstances there is more danger in turning asynchronous mode ON than turning it OFF. However, I do not know your system or the modifications you have made, but my guess is, and this is a guess, that it would probably be OK. My recommendation is to test it thoroughly in test/development, before making the change in production systems.

 

[RaghuBabu]

It worked after unchecking Asnychronous mode option. Thank you very much..

Raghu
XE NT SQL2K