Close modal form without refreshing calling form (1 Viewer)

[ClaraBarton]

I have continuous form that I filter by followup date. When I click on the first followup date a detail form opens and I call the client and update various things and change the followup date. Then I'd like to return to the list and go to the next client. I have a close button that returns me to the original client after requerying. I also have a button (X Close) that is supposed to go back to the list without requerying or refreshing. However, if I change the followup date, the continuous form filters that client out. Is there a way to do this work, keep the continuous form exactly as is until I've worked through the list. I know it won't update deletions and additions but it's just a temporary thing. I know this is against all rules... but can it be done?

 

[Eugene-LS]

Try change continuous form property : RecordsetType

 

[theDBguy]

You said you use a close button that requeries the main form. What happens if you don't perform the requery? Does that eliminate the problem with filtering out the record you just changed? If so, does it then result in a different problem altogether? If so, what is the new problem?

 

[ClaraBarton]

It doesn't requery but it does seem to refresh according to the filter. Stupid idea. I'm thinking now about adding the filtered list to a listbox that doesn't change unless a new filtered list is added. He could work from that list and still jump around on the continuous form and it would always be updated. I should have thought this through more thoroughly.

 

[The_Doc_Man]

It is hard to be sure, but from your discussion, it sounds like you are getting caught in standard Access behavior. When you make a change to something that is essentially a child form that is bound, you have also changed a child table. Then you exit the child form. If there was indeed a change then the child table has to be updated due to a pending change (= dirty child) while the form is being closed. I believe in that circumstance, the parent gets re-queried automagically.

 

[ClaraBarton]

Ok... moving on. I have a new continuous form that I push a button and it fills with the filtered records from the original list. It only fills a couple fields as it is only a working list that on click pulls up the detail form for working. Now I'd like for the form to maintain the data even if closed until the button is pushed to get a new list. There is no recordsource. Only a sql statement when the button is pushed. Why does the form empty when closed? How do I maintain the data? When opened the fields are empty showing #Name?.

 

[ClaraBarton]

Perhaps I should write to a temporary table and use it for a data source?

 

[Mike Krailo]

There is no recordsource. Only a sql statement when the button is pushed. Why does the form empty when closed? How do I maintain the data? When opened the fields are empty showing #Name?.

If no record source, then of course nothing will be retained. You appeared to have answered your own question. Store that which you wish to retain in a table, then you can work through each record as you wish.

When I click on the first followup date a detail form opens and I call the client and update various things and change the followup date. Then I'd like to return to the list and go to the next client.

With every new query list, you can empty the contents of the table with a delete query and then fill it up with an append query so you have your table you work with without losing the data. Make a form based off of this table and have it do the same thing opening details for each record as you go through them.

 

[ClaraBarton]

yup. working well.

 

[MarkK]

Add a field. Obviously FollowUpDate (FUD) is a data point, but the date the FUD was updated, call it FUDUpdated, is also a data point. Then filter your FUDEditor interface by InNull(FUDUpdated)--not by FUD itself--so you are totally free to edit FUDs without impacting your filter. Then, when you close your FUDEditor, run a query that updates FUDUpdated on any and all rows that have a valid FUD, but a Null FUDUpdated.

Right? Because you actually have two important data points. FUD, and FUDUpdated.