Re: Form returns 'Data Not Saved' after a successful COMMIT!!

From: Bob Cunningham <bcunn_at_oanet.com>
Date: 1997/10/19
Message-ID: <344985c3.22753285_at_news.oanet.com>#1/1


On Sat, 18 Oct 1997 16:42:23 GMT, Thenardier_at_POBoxes.com (ªü´ö Thenardier) wrote:

>
>Hi all,
>
>The problem is as subject. The form returns 'Data Not Saved'
>message even when records are successfully INSERTed and COMMITted.
>
>I generate the form using Data Module Diagrammer in which i
>specify a table, say, TABLE_A to display on the form. But,
>in run time, i need to use the information from TABLE_A to
>insert new records in to *another* table TABLE_B. That
>TABLE_B is not included in the Data Module Diagrammer.
>
>Some say when saving record, D2K would do a COMMIT_FORM
>to the form that is included in the Data Module Diagrammer
>(in the case, TABLE_A). In my case the included one is
>TABLE_B instead of TABLE_A. So the D2K would do COMMIT_FORM
>to TABLE_A (but nothing to be commited) only. As a result,
>the form returns 'data not save' message even TABLE_B is
>manually committed.
>
>What should i do to this? Thanx!
>
>
>Thenard

Since the inserts to TABLE_B were done manually, none of the form items were altered so there are no changes requiring posting and committing by Forms. Hence its message.

You could:

(a) Commit (e.g. FORMS_DDL('COMMIT'); ) and issue "commit successful" message yourself

(b) Modify an item within Table A to force a "changed" item to be posted and the commit issued by Forms through the normal COMMIT_FORM processing. The modification could be as simple as assigning an item its own value like :BLOCKNAME.ITEM_NAME := BLOCKNAME.ITEM_NAME; Only the changed row is "known" to the form, so its message that mentions "n" records updated won't include the number of rows manually inserted by your code... but everything WILL be committed.

(c) I haven't done this but it seems to me that you could add a base table block to your form that is associated with TABLE_B. Instead of INSERTing the new rows into TABLE_B via DML, create them as new records within the TABLE_B base table block. These are "known" to FORMS, so they will be posted and commited by the COMMIT_FORM (which will now issue the "n" records updated message).

That's all that come to mind for me...perhaps others have additional alternatives for you.
Bob Cunningham
bcunn_at_oanet.com
bcunn_at_compuserve.com Received on Sun Oct 19 1997 - 00:00:00 CEST

Original text of this message