Search results

Glad to help I only signed up to point that out. Often what we think we are doing is not actually what we told the system to do and it always pays off to take a second to stop and examine our actual tradjectory vs intended direction.

You could opt for OnKeyPress if your dataset is lean enough. @Minty Your probably right sorry MajP... Wasn't digging at you just at the example of the length of code used for a work around to something that already exists. Plus you can't google that solution, it requires some quite in depth...

RajP 5 lines vs 1 to do the same thing. Or 18 actions the CPU has to do vs 3 for each call of that function. That's n3 vs n18 in computing... Which runs more efficiently? Saving face is nice and all but amitting when you have gone down a rabbit hole is a time saver especially if a rubber ducky...

Depends how you want to enact the Me.Recordset.Requery AfterUpdate is the usual standard for most interfaces, especially if you have multiple users querying at the same time. You can define it on keypress and everything will update as you type Press F4 to open properties and under the Events...

Random GIbberish generator I like it xD almost as much nonsense as recordset scroll bar logging instead requerying the RecordSet xD - this is the Uncle Roger reference... your solution reminded me of. "Log the scroll bar and then recall the position of the scroll bar after requerying the form...

Stop. All of you just stop the form.requery madness... The reason microsoft haven't made a "fix" is because there isn't one to make... Stop trying to Requery Forms when you only want to Requery RecordSets. Forms!frmRecordList.Form.RecordSet.Requery The reason you are struggling is because...

Wow 7 years and nobody thought to requery the recordset instead of the form... Me.RecordSet.requery. Hell you can even pick the form you want to requery the subsequent recordset on... because it turns out refreshing the data is what you need to be doing not the form because of course it is...