Extend a Transaction Boundary via Form Interconnect on a Row Exit

[BOster]

Is it possible to extend a transaction boundary from Form A to Form B using a Form Interconnect on a Row Exit?

Here is the situation:
Form A is Headerless Detail.
Form B is Headerless Detail.

User enters record in Form A, selects record and clicks row exit to Form B. Enters records in Form B and clicks OK, but clicks cancel in Form A. Form B records are now orphaned.

I can't seem to solve this using Trans. Processing. It looks like you can only extend a Trans boundary on a form interconnect in the OK or Cancel button of Form A.

What am I missing?

 

[Zoltan_Gyimesi]

Hi Brian,

I have some tricks (including illegals

) on XE, how to deal with transaction processing in interactive applications - including more form via form interconnect.

Though I have never prepared an exact method, I always found the way, how to solve transaction issue.

#1.) Include Transaction option on Form Interconnect is available in more events- you can find them in the Development Tools manual, under Transaction Processing chapter.

#2.) My first cent to start:
- copy your form interconnect to the OK button event
- set the Include Transaction option
- Cut/Paste this statement to your row exit
- if you should edit this call later, then copy back to the OK, do it there and Cut/Paste back

Let see, does it already solve the problem, or not.

I have more cents to solve the your issue

Regards,

Zoltán

 

[Zoltan_Gyimesi]

Hi Brian,

Would be great to know more about your scenario - to help you more effectivly.

I suppose, you very well know, that modifications on existing records and newly added records on Form A still does not exist in the database, when you call Form B from the row exit.

I am afraid, you will face with an other problem, if Delete is available on Form A.

Regards,

Zoltán

 

[BOster]

Thanks for your reply. Love trick number 2 (although have not tried it yet...) I used to do something similiar to get different Form Controls on to message forms that were not available in FDA for message forms (basically add the control to a fix inspect and then cut/paste to the message form).

To explain my problem further, I want the OK/Cancel buttons on Form_A to commit/rollback records added/edited/deleted on both Form_A and Form_B. I think though to avoid some of the complexities I am going to tackle the problem from a slightly different angle and use a Fix/Inspect for Form_A so only 1 parent record is being worked with at any given time. I may still need to try you trick number 2...

 

[Zoltan_Gyimesi]

Hi Brian,

[ QUOTE ]
I used to do something similiar to get different Form Controls on to message forms that were not available in FDA for message forms (basically add the control to a fix inspect and then cut/paste to the message form).


[/ QUOTE ]

I frequently used this trick on XE

[ QUOTE ]
I may still need to try you trick number 2...

[/ QUOTE ]

2nd cent

You can enter Open Table I/O with Include Transaction advanced option on OK and Cut/Paste it to other event (e.g. Dialog Is Initialized) and place a Close Table I/O after other form call, but generally best place the End Dialog event.

I have some more cents for you, including Dummy Transaction Frame Form technique groupping more forms into a single transaction

Regards,

Zoltán

 

[BOster]

Ok, so I decided to play by the rules (also turned out to be a better design), but JDE Transaction processing still doesn't work completely as expected...

Form_A is a Fix/Inspect (Transaction Enabled)
Form_B is a Headerless Detail

Form_A has OK button w/ form interconnect to Form_B with "Include in Transactin" checked.

Scenario 1:
User adds/edits record on Form_A.
Clicks OK. (no changes in DB as expected)
Adds/Edits records on Form_B
Clicks OK. Both tables in the database reflect the changes as expected.

Scenario 2:
User adds/edits record on Form_A.
Clicks OK. (no changes in DB as expected)
Adds/Edits records on Form_B
Clicks Cancel. Form_A records get written to DB and Form_B records are canceled. I would have expected BOTH tables to be rolled back.

 

[Zoltan_Gyimesi]

Hi Brrian,

Maybe you can make a try with my Dummy Transaction Frame form technique.
I try to decribe it briefly:

#1. Extend the Data Structure of bot form with a flag, to let the caller know, wheter OK or Cancel returned (e.g. cOK_Returned_01 based on EV01)
#2. Manage this parameter in both form (set to 0 in Dialog Ininitialized and set to 1 in Post Button Clicked of OK)
#3. Create a dummy Fix Inspect form with enabled Transaction handling (not necessary to create it in the same APPL, you can create a new APPL for it.
#4. If you call Form A via Form Interconect originally, then create Data Structure for dummy form, similar as Form A has - making possible to pass parameters for Form A through dummy form and passing back to the caller.
#5. Make this form as Entry Form and/or call this form instead of Form A.
#6. PressButton(HC &OK) in the Dialog Is Initialized event on this form.
#7. Place a dummy DD field on the form, e.g. "Dummy Control For Default Cursor" based on EV01.
#8. Set "Default Cursor on add mode" and "Default Cursor on update mode" options in the properties of this control.
#8. PressButton(HC &Cancel) in the Control Is Entered event of this control.
#9. Logic for Button Clicked event of OK:
- call your Form A with Include transaction
- if NOT the OK returned, then issue a dummy control error for your dummy field or for any Hyper Control and issue a StopProcessing system function - your dummy conrol will receive the control focus and will manage Cancel branch (NOTE: pressing Cancel from OK produce nasty run-time error)
- OK returned, the call Form B with Include Transaction
- if NOT OK returned, then manage this the same way as for Form A.
- if OK returned then everything had been done.

Maybe you should extend with some further parameters your Form Interconnect Data Structers to manage your information flow.

If you place your Dummy Form into a separate APPL and your original APPL has processing options, the you should somehow manage, which version of the original APPL to call - in the first pass, you can simply hardcoed it, and if this technique works, the we can discuss, how to manage this - based on your scenario.

I do not know, is it necessary or not, but maybe you should attach a dummy (any) BSVW to your Dummy Form (e.g. it can be the BSVW of Form A - not necessary to create a Dummy BSVW).

If this step is necessary, the you should Suppress ADD and UPDATE in the appropriate "DB-Before" events of the Dummy form

Please, if you make a try, then try it first without attached BSVW and let us know, does it work, or attaching BSVW is necessary! Thanks (I am really curious).

Extra Advantage:
If you open the table of Form A in Form B as I described it in my previous post, then you can FetchSingle the UpToDate values from the record of Form A.

Please, keep us informed. Thanks.

Regards,

Zoltán

 

[BOster]

Does this work in HTML clients as well?

 

[Zoltan_Gyimesi]

Hi Brian,

[ QUOTE ]
Does this work in HTML clients as well?

[/ QUOTE ]

Sorry, I do not know - I have never tried it.
The only, what I know, that it works on XE SP23 as well on fat client and on WTS, accessed via Citrix or Remote Desktop - as well on SQL and Oracle DB.

If you make a try on HTML client, then please, let us know your result.

Regards,

Zoltán

 

[Zoltan_Gyimesi]

Hi Brian,

I am just curious.
Do you plan to make a try?
I suppose, you have a good chance, that this work on HRML client too.
As I mentioned, I am just curious.

Regards,

Zoltán

 

[BOster]

Actually, I had all ready re-structured the app where it is not quite as important (its a small app that will be used by only a handful of people and won't really be that heavily used).

I am putting all this good info in the memory bank for the next time something like this pops up. We use both Citrix and HTML, so it would need to work correctly on both, so at some point I might test this out. I allways get a little nervouse when circumventing normal JDE... but it wouldn't be the first time...

 

[Zoltan_Gyimesi]

Hi Brian,

[ QUOTE ]
I allways get a little nervouse when circumventing normal JDE...

[/ QUOTE ]

I could tell some (???) story, what had I seen inside vanilla JDE objects, which made me serious head-ache and driven me nervous...

Regards,

Zoltán