Refreshing the form vs. requerying

[Access_Novice]

Requerying will reload the recordset. So that would show new records, and deleted records would not be shown anymore right? But refresh does not show new records right?

I have form called Parent bound to a table called tblParent. I have the table and the form open. I added a new name/record to the form. I advanced to the next record, then went back to see if my new record showed up. And it did show up.

Was this an example of requerying or refreshing the record since the new record showed up? Why?

After this, I checked the table and didn't see the new record in the table. Since the new record wasn't in the table, I didn't think it would still be visible in the form but it was. To see the new record in the table, I had to click the Refresh button.

[June7]

Never thought much about this. I just accept that form is designed to handle new record creation.

Did you test adding new record directly in the table then see if it shows up on the form right away? It shouldn't. Access does automatically refresh/requery periodically and the record should eventually show in the form.

[Access_Novice]

Never thought much about this. I just accept that form is designed to handle new record creation.

Did you test adding new record directly in the table then see if it shows up on the form right away?

Yes. I didn't show up in the table right away. However, I am fairly certain that earlier tonight, I made a change to a person's first name and with the table in view, I thought I saw the first name update in the table right after I tabbed out of the field. So I was still on the same record.

Is this possible or perhaps I'm confusing this with something else I did? I couldn't replicate this, however the MS website says that a control is in fact updated after you tab out of it.

[June7]

Sort of. Edits done on form will show in table as soon as record is committed. Record is committed when close form, move to another record, or run code.

Even edits directly in table aren't really committed until move to another record. Do some edits then without leaving record press ESC key. What happens?

[ItsMe]

Just going from memory here, a loose interpretation could be... a control updates a recordset and a form will update a record. Tab out of a control, and the form's recordset gets updated. Navigate to a new record and the table's record get's saved.

Access_Novice, what you are doing is the correct thing. You need to test the behavior. Understand what is going on behind the scenes. There will be times these nuances matter. The difficult part is remembering all of the nuances.

If you tab out of a control, it should be immediately reflected in the table. If you then navigate to a new record, it should be saved. The difference is, as I see it, you can still use the form's before update event before you navigate to another record to revert changes to the recordset.

With that I will include a link to an article on refresh. Bottom line, test the behavior. Testing your app before it goes live is a big deal and it is good you are asking these questions. I am just too tired right now to research a good descriptive and accurate answer.
http://msdn.microsoft.com/en-us/libr...ffice.11).aspx

[June7]

I tested edit on form and looked for the edit in open table. It did not show until I moved from the record on the form.

[ItsMe]

Yup, I misspoke or mistyped. I edited my post to show tabbing out of a control will not effect the value within the table.

[Access_Novice]

Do some edits then without leaving record press ESC key. What happens?

I did an edit in a firstName field, then tabbed out and didn't leave the record. The value in the underlying table did not update after I tabbed out. It updated after I advanced to the next record, which is consistent with what the MS website said. But I am certain that last night, I tabbed out of a field and saw the underlying table value update, although the evidence indicates the opposite.

I forgot to ask, when using a form, when would you use refresh? When would you use requery?

[Access_Novice]

Just going from memory here, a loose interpretation could be... a control updates a recordset and a form will update a record. Tab out of a control, and the form's recordset gets updated. Navigate to a new record and the table's record get's saved.

Access_Novice, what you are doing is the correct thing. You need to test the behavior. Understand what is going on behind the scenes. There will be times these nuances matter. The difficult part is remembering all of the nuances.

If you tab out of a control, it should be immediately reflected in the table. If you then navigate to a new record, it should be saved. The difference is, as I see it, you can still use the form's before update event before you navigate to another record to revert changes to the recordset.

With that I will include a link to an article on refresh. Bottom line, test the behavior. Testing your app before it goes live is a big deal and it is good you are asking these questions. I am just too tired right now to research a good descriptive and accurate answer.
http://msdn.microsoft.com/en-us/libr...ffice.11).aspx

Thank you. Yes, I ask these questions about nuances because I know that in programming the little things really do matter. I appreciate your feedback as well as June7. Thank you both.

[Missinglinq]

...I advanced to the next record, then went back to see if my new record showed up. And it did show up...

...Was this an example of requerying or refreshing the record since the new record showed up...

Neither! When you add a New Record, and the Record is saved, such as by moving to another Record, that New Record is there, on your copy of the Form!

Is is not, however, 'there,' on the same Form that is currently opened by another user! In a multi-user environment, Refreshing their copy of the Form won't make it display, either. It will only display for other users by their Forms being Requeried.

The Refresh Method is really intended to be used, in multi-user environments, to show UserA any edits made to existing Records by other users. And by 'existing Records, I mean Records that existed when UserA opened his copy of the Form.

Linq ;0)>