How to prevent unwanted saving records in dbf set-in

[draganksg]

My set consists of two dbf table.
On the form, when entering a new record, when the first table fields entering data and I cross on field of second table and enter date in any field , alpha automatically preserve all entered data into the fields of the first table, and I am not finished entering all the fields in both tables. I do not want to entering data to be finished until I clicks the appropriate button.

How do I prevent alpha saves the data from the first table fields of set automatically when I enter any data in the field of another table of the set that the form is based off..

This is a big problem. What if after entering data in second table fields (data from the first table alpha already saved in the first table), the user withdraws from all entries and close the form. I'll have data 'orphans' in the first table with no corresponding data in second table of the set.

As can be seen in the photos, set consists of two tables with a mutual relationship one to many. And the fields on the form, the first two tabs are from first table of the set and fields on other tabs are from second table of the set.

[Ted Giles]

Re: How to prevent unwanted saveing records in dbf set-in

On the Set Design, choose Referential Integrity/Cascade Changes Deletes.
When the parent is deleted, the children go as well.
You will need to ensure that if a user cancels the data entry, then the parent record needs to be deleted also.
The reason that the Child record entry can be cancelled, is because the Parent might contain many Children as the name suggests and you might need to preserve the Parent.
If you put a button on the Form and an Action Script "Delete Record" which is shown with a message "Cancel all Data Entry?" when the data entry is abandoned, then the Parent will go as well.

[Tom Cone Jr]

Re: How to prevent unwanted save records in dbf set

I do not want to entering data to be finished until I clicks the appropriate button.

Dragon, Alpha Five saves data to tables, not sets of tables. When the field objects are bound to table fields and you choose to do data entry through a set based form, the behavior you're seeing is necessary. Consider this. If the "Parent" table record in your set were NOT saved, how would Alpha know what link field value to supply to the child table records?

If this is not what you need, then you may have to create your own data entry sequences from scratch. This could be done by binding your form objects to variables, not table fields, and then writing scripts that pass link field values from parent to child, and writing other scripts that create new records in the parent and child tables, populate fields from the variables, and then save them. A lot of work. Often required on other development platforms, but made unnecessary here by Alpha's default set based behaviors.

[Tom Cone Jr]

Re: How to prevent unwanted saveing records in dbf set-in

Ted,

Referential integrity is sometimes not the best choice. There are complications when the app is run over a local network and users on different workstations want to work with the tables in the set. They can't. Those tables are locked by RI. Also, there's a numeric limit on the number of linked child table records that RI can handle. I think it's pretty big, like 512 or something, but in some apps, this would be a deal breaker.

I'd prefer an approach that uses a script in the "Delete All" button that deletes all the children, and then deletes the Parent. I don't use RI.

Related material on this is available at Dr. Wayne's site: learn alpha.com

[Ted Giles]

Re: How to prevent unwanted saveing records in dbf set-in

Thank's Tom, I look at Peters site quite a bit but didn't go into RI as I've not experienced any issues (so far).
I'll read up on it.