P4205 locked after TR upgrade

78aspide78

78aspide78

VIP Member
Dear All,
I'm working on TR upgrade 8.96 to 8.98.1.4 on 8.10 release running without web applications.

The only issue occured is related to P4205 program.

Running this app on new TR sometimes (5-10 per day) customer reports a unusual blocking status of the client after shipping confirmation (no jde.log information found). Transaction goes ok but application is blocked and users need to close JDE and log again into the system.

I was unable to reproduce the error with jdedebug activated (and from this i assume some sync/async issue but i'm not sure). So i decide to switch one citrix server to the old TR and in this condition program works fine (tested by the users for different days).

Did you have any suggestions about this issue?
 
This is a long-shot, but one thing I've had to do many times -- delete all user overrides for P4205 (and any other programs being used by it). User overrides (aka grid formats) have historically been very touchy, especially whilst upgrading tools releases.
 
Very good suggestion Don, many thnaks, but unfortunately it doesn't works.
 
Hi Bruno,

Have you any customization/mods on P4205?
Mainly in Button Clicked / Post Button Clicked events of OK button.

Regards,

Zoltán
 
Hi Zoltan,
of course, it was customized
smirk.gif


Next step in my test will be to move the code after the end doc to the post commit event but if it's a bsfn error i aspect some suggestion from jde.log but no information on this file leave me confused.

I can suppose that a timeout at bsfn execution level can left the log without indication but not sure about this so jde.ini timoute increasing can be another way to find more info.

If you have any idea............. i'm ready to try!!!!

Thanks for your interest and best regards
 
Hi Bruno,
Which event your customization is in?
What does your customization?

Do you Update some fields (with Table IO or with custom BSFN)in a table which is also handled by P4205?

First check all Synch/Asynch and Include Transaction settings of the original BSFN calls.

Waiting your reply and the further information to help you.

Regards,

Zoltán
 
Well Zoltan,
just looked at the code, it's realy a bad affair.

ShipConfirm End doc was turned in SYNC mode and it's not in transaction, then there are differetn Table IO to F4211 and F4311 and other custom table, some custom BSFN call and some form interconnect to other screens.
That's all.
 
Hi Bruno,

[ QUOTE ]
ShipConfirm End doc was turned in SYNC mode

[/ QUOTE ]

Then this in the Post Button Clicked event.

Q1.) Have you checked the Button Clicked event too - here just for Include Transaction?

Q2.) Are there other original BSFN call in tzhe event (in both)? f yes, what are their settings?

Q3.) Is there any Open/Close statement for your custom TableIOs?

Q4.) Are your all customization at the end of the event, after the original code?

Q5.) What are the options in your custom BSFN call(s)?

Regards,

Zoltán
 
Thanks for the response,

1) In button clicked event BSFN are not included in transaction too
2)i found the original EndDoc commented in the post button event and in this call include in transaction is enabled, in button cliecked i'm not sure because i see no comment.

3) no open/close statement

4)Not at all, some minor code beafore the original code (IO on F4211 and F4311 file)

5) custom BSFN are called without include in transaction flag except a removeObjectReservation that i see with include in transaction flag.

I'm not the developer of this code so realy not understand all the scope of the code (it was customized from client dusirng the years)

Do you think can be a sync/async issue?
 
Hi Bruno,

[ QUOTE ]
Do you think can be a sync/async issue?

[/ QUOTE ]

No, I suppose this is a Transaction Handling / Record Locking issue.

What am I already know about your scenario - is a bit confused to me.

Can you attach the code of both event of OK?
Can I see, which are the custom code?
Can you include the setting for each BSFN call?

Regards,

Zoltán
 
Thanks again for your interest,
can i send you the code bye email? there are a lot of comment from different people and it's not correct in my opinion to publish on the List this work.

If you agree i'll send you bye email the code and bsfn settings.

Then we can continue to discuss about the issue on the forum so other people take advantage from this.
 
Hi Bruno again,

Just further questions.
(Sorry, currently I have access only to an XE system, where we also have a lot customization on P4205)

Q1.) What is the Tranction setting on the Prperties of the Form?

Q2.) Does the APPL (P4205) called directly from the menu or the Form is called indirectly from an other screen?

[ QUOTE ]
Not at all, some minor code beafore the original code (IO on F4211 and F4311 file)

[/ QUOTE ]

Q3.) Do you know, why they are before the original code? Mainly IO on F4211?

Regards,

Zoltán
 
Hi Bruno,

OK, send me by e-mail.

You should know, this is my last work day before my 2 weeks holiday.
On my holiday, I won't watch JDEList too frequently
cool.gif
and I will have very slow internet access in the hotel (less the 256 kbps)
frown.gif


Regards,

Zoltán
 
1) Form is transaction enabled
2) P4205 is called from menu
3) They need to check some condition on related PO order and item cost.
 
I need a little bit of time to prepeare the code to send you, so don't warry about this issue and have good holiday (i'm sure it's more important then all the shipment confirmations in the world).

Best regards.
 
Hope this is the right thread !!!
smile.gif


Following the suggestions provided by Zoltan...finaly I was able to fix the issue.

Yes it was a Transaction problem. Form was in transaction, EndDoc was not in transaction, some BSFN (standard and custom) were not in transaction.

I removed the transaction properties of the forms, now we are testing but everything works fine.

Thanks to all, and , of course, Thank to Zoltan for the inspiration :)

Regards

Bruno Condemi
 
ciao Bruno, I don't know if disable transaction properties in form is the best solution. Which are specification of you custom code (table IO operation)? Can you try to implement it inside a custom NER called by ShipmentConfirmationEndDoc?
gg
 
Code refactoring can take a lot of time and effort.
Customer need to test again ship functionality, users need to test it too because the error occurs at 2% of time, so a lot of test (read this as money).

So exactly why you say that?

Wich kind of problems do you see?

As a said EndDoc run in sync mod and outside the transaction. So errors at ship confirm level doesn't roll back sql statment. Others Table IO , at event rules level,are not in transaction.

So what i'm missing?

I'm according to you the best solution is to investigate what code produce the error, but i need to ballance this work with the cost and the result. Assuming (and untill now really i can't say nothing of different) that removing the transaction property works without impact on businees operation, this is, in my point of view, the best choice.

Any suggestion will be appreciated.

Ciao!
 
Hi Bruno,

Apology, I wasn't back again yesterday - hope, you excuse me.

First of all, glad to know, that your issue had been solved (but I will have some comment later).

[ QUOTE ]
[ QUOTE ]
Do you think can be a sync/async issue?

[/ QUOTE ]
No, I suppose this is a Transaction Handling / Record Locking issue.

[/ QUOTE ]

It seems so, my suspection was right
cool.gif


[ QUOTE ]
Yes it was a Transaction problem. Form was in transaction, EndDoc was not in transaction, some BSFN (standard and custom) were not in transaction.

I removed the transaction properties of the forms, now we are testing but everything works fine.


[/ QUOTE ]

I agree with Luigi - not the best choice to eliminate Transaction Processing. Generally there is a good reason of Transaction Processing - to keep data consistent.

Eliminating Transaction Processing solve your current issue, but open an other potential trap/risk - producing data integrity issue.

In my humble opinion, better way to include custom DB fetches/mods into the original Transaction Scope. It is easy to do.

This has been discussed more times on JDEList - many times commented by me
cool.gif


One of the solution does not require to eliminate Asynch execution of vanilla BSFN calls in Post Button Clicked event on OK.

I had made many custom codes in such a situation - as well in original APPLs (including "favourite" P4210/P4310) as in brand new own APPLs/UBEs - sometimes to keep three or more level of data in integrity.

If you would like, JDEList (including me:eek:) can help you, how to realize this (better) way.

At last, but not least, to my friend on the "List", Ady (Adrian Chimiral):

Hope, you will read this thread and will be glad, that my favourite topic is again on the top
grin.gif
cool.gif
grin.gif
cool.gif


Bruno, please keep us informed, which way have you choosen finally and why - and how does it works for you.

NOTE:
Maybe would be useful to open a thread on the "Tips & Traps" forum about transaction processing, so there won't be need in the future to post again the same - would be enough to direct the member to that thread.

Regards,

Zoltán
PS: today: swimming a bit, thermal pool, buzz pool, sauna, grape seed oil massage, relaxation - thermal pool, buzz pool, sauna, sauna, sauna
...and maybe a bit JDEist
tongue.gif
grin.gif
cool.gif
 
Thanks again,
can you post the link you mentioned, i'm not a good seracher but, of course, a good reader.
 
Back
Top