Steve: That's one of the biggest differences between 6.5 and 7.6. The fact that you can update a table behind the scenes and "fresh" it on the form.
If you remember from 6.5 days, you cannot do a SAVEROW when you're back in that first form, because it will save what is on the form itself over the changes that you have made in the background. The form has no idea what you did behind it, and will save the data it loaded into memory on top of your changes. IMO the only thing you can do is to actually close that first form before you bring up the BDNoteIns form. Assuming that the other forms are big enough to cover the first form, the user wouldn't even know it. Whenever you close BDNoteIns, just have your program bring that first form back up again. Karen > Here is the Scenario. > > I am working in 6.5++ for this application. Use 7.6 for others but this is > still 6.5++. > > 1. You enter a form (Breakdn) for the Master table and view and enter > data. > > Then using a pop up to go to another (BDNoteIns) form to enter data in the > BDnotes table and view data from other tables with popups. > > Then we are go into another form (Billing1) (via popup from BDNotesIns) > where data is entered into the Master Table that can be common to the first > form (Breakdn) entered. > > When you exit the form (Billing1) the data is saved to master and you drop > back to the (BDNotesIns) form where you might enter to data (notes) and > you drop back to the (original form entered) Breakdn, > > > Here is the issue: > > When you get back to the original form (Breakdn) from the popups the data > in the Form is still the same as when you left it to pop into the other > forms ( when leaving the form the first time there is a save row). > > Question is this: > > Is (Doing a SAVEROW going back into form Breakdn) the best way to update > the form coming back into to it or is there a better way. Remember some of > the data common to Breakdown and Billing1 forms was saved to the Master > table when entered in Billing1. > > Note:
