Re: POSTING RECORDS TO THE DATABASE (V7)

In <3g6n94$4ej_at_News1.mcs.com> stowe_at_aol.com writes:

>In article <3g5sh1$qj5_at_xenon.brooks.af.mil>, <foroughh_at_vanadium.brooks.af.mil>
>writes:
>> I want to know if there is a problem with posting records. This is the
>> senario:
>> Form A has new record pending, (table A) and calls form B
>> Form B adds new record to (table B)
>> Commiting records on form B will cause the following error:
>> "can not commit chnages, calling form has unposted records"
>> So we post by saying
>> POST;
>> and exit
 

>You cannot post or commit records from a called form when there are unposted
>records in the calling form.

I disagree... You cannot commit in a called form when there are uncommited records in the calling form, but the whole point of POST was to allow posting in either the calling form before calling the called form (in this case the called form can COMMIT - this will commit the records POSTed by the calling form) or in the called form before returning.

>> When form A commits, shouldn't the records in form B be commited
>> as well?
 

>No, because you cannot post them.

I'm not sure what you mean here - but the principle should be that the records POSTed in Form B should be COMMITed (in the ORACLE RDBMS sense of COMMIT, not the FORMS sense) by the COMMIT_FORM operation in Form A. However, what happens is that Form A sets a Savepoint when it calls Form B, and the default behaviour when Form B exits is to ROLLBACK to that Savepoint. Try changing Form B to exit with :-

                EXIT_FORM(NO_VALIDATE,NO_ROLLBACK);
It works for me :-)

>> What are we doing wrong:
 

>You are attempting to post/commit from two forms simultaneously.

I don't think that's the problem. As I said above, the trick is to understand that though Form B can POST, the default EXIT_FORM behaviour will ROLLBACK those changes.

All flames gratuitously ignored.

Mark Bluemel. The Man with No Sig Received on Mon Jan 30 1995 - 11:37:11 CET